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

Adam de Boor adeboor at google.com
Tue Jul 14 21:58:44 PDT 2009

I guess in the double-AppCache model, where there's a generic cached
redirect page, one could make it so all user-specific accesses use a URL
with a user-specific prefix, so it can prefix-match against an entry in the
NETWORK section of the generic cached app manifest.
still, given how many apps on the web identify the user using an ID in a
cookie, it'd be nice if apps wanting to use AppCache didn't have to go
through these gyrations.


On Tue, Jul 14, 2009 at 3:30 PM, Aaron Whyte <awhyte at google.com> wrote:

> Most apps provide different contents for the same uncacheable main-page
> URL, depending on the identity of the user, which is typically stored in a
> cookie and read by the server.
> However, the HTML5 AppCache spec doesn't allow cookies to influence the
> choice of AppCaches or the contents of a response returned by the cache.
> This makes it a lot harder, but not impossible, for developers of existing
> apps to start using AppCache, while still supporting multiple users per
> browser or browser profile.
> Without changing the user-visible URL structure of an app, developers might
> support multiple users, by replacing their server-generated user-specific
> main page, with a generic cacheable JS app that does this:
> 1) Establish the user's identity using a cookie, or a database record, or a
> session key-value store.
> 2) If the user can be identified, load the user-specific resources (JS,
> CSS, data, etc.) from the network and/or local storage, possibly including a
> separate AppCache with user-specific or fingerprint-specific URLs.
>  Otherwise, load the unknown-user version or a login page.
> That'd be a complete restructuring of the main page, but it's possible.  I
> suspect that this is the model the AppCache was designed to support.
> A more radical change to existing apps, and app design in general, would be
> to include account-identifying information in the user-visible URL.  The
> main page could redirect users to their user-specific page or the
> unknown-user page.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090714/00e27d85/attachment-0002.htm>

More information about the whatwg mailing list