Re: [whatwg] AppCache can't serve different contents for different users at the same URL
On Mon, Aug 3, 2009 at 4:20 AM, Mike Wilsonmike...@hotmail.com wrote: 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 FWIW, Wikimedia uses a non-standard X-Vary-Options header for exactly this purpose, which they've patched Squid to recognize. Of course, since it's non-standard it only benefits their own reverse proxies, not any regular proxies that might be used elsewhere (unless those happen to be running the patched Squid for some reason). Varying on Accept-Encoding is very useful for cache hit rate as well. Reference: http://www.mail-archive.com/squid-...@squid-cache.org/msg07066.html
Re: [whatwg] AppCache can't serve different contents for different users at the same URL
'Named' cache groups under a single manifest url is an interesting idea. Presumably the webapp would be generating the 'name' in the manifest file based on a cookie value. Another possibility is something along the lines of what is proposed in the DataCache draft: the manifest indicates a cookie name, and the value of that cookie determines the 'name' of the subgroup. And the value of that cookie also determines which subgroup is enabled at any given time. On Tue, Jul 28, 2009 at 9:04 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 28 Jul 2009, Adam de Boor wrote: the difficulty with a named-section option is that the manifest generation for an application would have to know which users use a particular machine, which is pretty much a non-starter. I meant that each named appcache would have a separate manifest, and the manifest would just say the name of the one it was setting up. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] AppCache can't serve different contents for different users at the same URL
On Wed, 29 Jul 2009, Michael Nordman wrote: 'Named' cache groups under a single manifest url is an interesting idea. Presumably the webapp would be generating the 'name' in the manifest file based on a cookie value. Another possibility is something along the lines of what is proposed in the DataCache draft: the manifest indicates a cookie name, and the value of that cookie determines the 'name' of the subgroup. And the value of that cookie also determines which subgroup is enabled at any given time. I'm reluctant to do anything explicitly based on cookies because that would link two features in a way that might not be useful for all authors. In general I'd much rather we keep features of the Web platform orthogonal. For example, I'd want appcache to also work with HTTP auth, or with some other authentication mechanism over FTP, etc. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] AppCache can't serve different contents for different users at the same URL
On Tue, 14 Jul 2009, Aaron Whyte 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. On Tue, 14 Jul 2009, Adam de Boor wrote: 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 Wed, 22 Jul 2009, Anne van Kesteren wrote: Why not? I cannot find anything like that in the specification. It seems to me that the generic fetching algorithm is used which does not forbid sending cookies and even explicitly calls out setting them. On Wed, 22 Jul 2009, Drew Wilson wrote: Not sure what you are suggesting, Anne - it sounds like they want to tie the AppCache to a specific cookie/value combination, which I don't believe is supported by the current spec. On Wed, 22 Jul 2009, Anne van Kesteren wrote: Well, as far as I can tell cookies are part of the request to the manifest file so you could serve up a different one from the server based on cookie data. Is the problem supporting multiple users completely client-side? I can see how that might not work very well. On Wed, 22 Jul 2009, Drew Wilson wrote: That's an interesting idea (send down a different manifest), although I don't see how you'd leverage that technique to support two different users/manifests and use the appropriate app cache depending on which user is logged in. I think this boils down to the Gears 'requiredCookie' attribute was really useful. 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. This is the expected model for most apps. For example, your typical blog has just one set of CSS for all users. For systems where the user affects what HTML, JS, and CSS is served back, the spec as written pretty
Re: [whatwg] AppCache can't serve different contents for different users at the same URL
the difficulty with a named-section option is that the manifest generation for an application would have to know which users use a particular machine, which is pretty much a non-starter. a On Tue, Jul 28, 2009 at 6:08 PM, Ian Hickson i...@hixie.ch wrote: 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. This is the expected model for most apps. For example, your typical blog has just one set of CSS for all users. For systems where the user affects what HTML, JS, and CSS is served back, the spec as written pretty much requires that there be one app per user, and one generic login app that then redirects to one of those other apps -- and where each app has a different base URL, separate manifest, etc. I think conceptually that's actually not a bad idea anyway, to be honest. However, I could see that it might not be the preferred model. An alternative that we could explore in a future version is to have the manifest include a manifest name, and then have script that allows you to activate a particular manifest name for a given appcache. So each appcache group would be futher subdivided into named subgroups, and for a given manifest URL with such a group of subgroups, one subgroup would be the default one at a time. The inactive ones would just lie dormant, but and the active ones would act like now, but there'd be a scripted way to change the default (and maybe query what available variants exist for the current appcache), so that you could log back in as someone else by just making the script pick the other user's variant, and then reloading. I've noted this in the spec as a possible v2 feature.
Re: [whatwg] AppCache can't serve different contents for different users at the same URL
On Tue, 28 Jul 2009, Adam de Boor wrote: the difficulty with a named-section option is that the manifest generation for an application would have to know which users use a particular machine, which is pretty much a non-starter. I meant that each named appcache would have a separate manifest, and the manifest would just say the name of the one it was setting up. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] AppCache can't serve different contents for different users at the same URL
On Wed, 15 Jul 2009 00:30:05 +0200, Aaron Whyte awh...@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. Why not? I cannot find anything like that in the specification. It seems to me that the generic fetching algorithm is used which does not forbid sending cookies and even explicitly calls out setting them. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] AppCache can't serve different contents for different users at the same URL
Not sure what you are suggesting, Anne - it sounds like they want to tie the AppCache to a specific cookie/value combination, which I don't believe is supported by the current spec. -atw On Wed, Jul 22, 2009 at 3:32 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 15 Jul 2009 00:30:05 +0200, Aaron Whyte awh...@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. Why not? I cannot find anything like that in the specification. It seems to me that the generic fetching algorithm is used which does not forbid sending cookies and even explicitly calls out setting them. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] AppCache can't serve different contents for different users at the same URL
On Wed, 22 Jul 2009 18:10:52 +0200, Drew Wilson atwil...@google.com wrote: Not sure what you are suggesting, Anne - it sounds like they want to tie the AppCache to a specific cookie/value combination, which I don't believe is supported by the current spec. Well, as far as I can tell cookies are part of the request to the manifest file so you could serve up a different one from the server based on cookie data. Is the problem supporting multiple users completely client-side? I can see how that might not work very well. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] AppCache can't serve different contents for different users at the same URL
On Wed, Jul 22, 2009 at 9:46 AM, Anne van Kesteren ann...@opera.com wrote: On Wed, 22 Jul 2009 18:10:52 +0200, Drew Wilson atwil...@google.com wrote: Not sure what you are suggesting, Anne - it sounds like they want to tie the AppCache to a specific cookie/value combination, which I don't believe is supported by the current spec. Well, as far as I can tell cookies are part of the request to the manifest file so you could serve up a different one from the server based on cookie data. That's an interesting idea (send down a different manifest), although I don't see how you'd leverage that technique to support two different users/manifests and use the appropriate app cache depending on which user is logged in. I think this boils down to the Gears 'requiredCookie' attribute was really useful. Is the problem supporting multiple users completely client-side? I can see how that might not work very well. Yeah, I think that's the use case they are trying to support - offline access to web apps where any one of multiple users can log in. I have to say that I'm somewhat fuzzy on the precise use case, though. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] AppCache can't serve different contents for different users at the same URL
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. a On Tue, Jul 14, 2009 at 3:30 PM, Aaron Whyte awh...@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.
