[whatwg] AppCache can't serve different contents for different users at the same URL

I agree it would be interesting to have the browser being
able to distinguish between different variants of a page
based on who is "logged in", whether it be through cookies
or other mechanisms. But cookies should be included as 
they are one official way to store state.

Storing several variants of a page in a cache, using some
algorithm to select the suitable variant, draws many
parallels with HTTP caching. A good way of working with 
AppCache features might be to first get them working with
traditional caching.

For traditional caching there is the HTTP 1.1 Vary header,
that tells the browser what headers' values identify a
unique page variant. F ex
  Vary: Cookie
together with suitable Cache-Control headers would tell 
the browser to cache individual page variants for each 
value of the Cookie header.

A problem with this is that it will treat all cookies for
the page in one lump. In 1997 there was a proposal for 
identifying individual cookies, f ex:
  Vary: Cookie.USERID
or
  Vary-Cookie: USERID
but it seems it was dropped. Anyway, maybe it is 
interesting to reread the discussion to find correlations
to current AppCache topics:
http://lists.w3.org/Archives/Public/ietf-http-wg-old/1997MayAug/0334.html

As Ian says, client-centric webapps are probably the most 
straight-forward solution for offline apps. But given that 
the majority of today's webapps are probably server-centric, 
it would be interesting to see what can be done to easily 
support offline for them. It would be good to hear someone 
flesh out a (non-trivial) complete server-centric example, 
as there may be need for more features than just multi-
variant pages to get it working well.

Best regards
Mike Wilson

Ian Hickson wrote:
>
[...]
> On Wed, 22 Jul 2009, Aaron Whyte wrote:
> >
> > Imagine two users of fancyapp.com, with their own logins 
> > and data and custom skins and whatnot.  The contents of 
> > the main page are uncacheable and are totally different 
> > depending on the cookies in the request, which tell the 
> > server who is logged in.  This is the way nearly every 
> > web app works today, and this is also the way a lot of 
> > people share a single computer.
> > 
> > Without any offline support, they can share one browser, 
> > if one logs out of fancyapp, and the other logs in.
> > 
> > If fancyapp supports offline use with Gears, then one of 
> > the users can install an offline client, without 
> > affecting the other user, because of requiredCookie.
> > 
> > But if fancyapp supports offline use with HTML5's app 
> > cache, then if one user installs an offline client, 
> > fancyapp will keep working for that user, but not for 
> > the other user, who will have to go get their own 
> > computer, browser, profile, or whatever they need to 
> > avoid hitting the other user's app cache.
> > 
> > The engineers at fancyapp could rewrite their mail page 
> > so it's just a little router that looks at cookies and 
> > makes subsequent requests to user-specific URLs to really 
> > load the app.  But that's an inferior user experience, 
> > because it introduces an extra round trip to get the
> > initial page properly rendered.  So they'll probably have 
> > to support both.
> >
> > If the application code (HTML, JS, CSS) is all the same 
> > for two users, then appcache works for multiple users by 
> > just having the data for the users separate from the 
> > logic.
[...]

Received on Monday, 3 August 2009 01:20:05 UTC