[whatwg] Gears caching at identical URIs (was: Gears design goals)
sayrer at gmail.com
Mon Jul 2 06:42:24 PDT 2007
On 7/2/07, Robert O'Callahan <robert at ocallahan.org> wrote:
> On 7/2/07, Robert Sayre <sayrer at gmail.com> wrote:
> > Basically, I think offline caches should respect the Vary: HTTP
> > header, and maybe more. Applications will need to do this right
> > anyway, if they want to function correctly in the presence of ISP HTTP
> > proxies (AOL, TMobile, etc), corporate firewalls, and server-side
> > stuff like Citrix Netscalers.
> No they don't. For example, they can just use Cache-Control:private to
> bypass those caches. That's what GMail does.
Yes, I should have mentioned that I don't think an Offline API will be
able to handle Cache-Control:private stuff better than other proxies
unless it reinvents other HTTP caching mechanisms.
> > To me, it looks like the caching mechanisms in HTTP 1.1 can satisfy
> > this requirement. I think Rob is correct that it adds substantial
> > complexity, but it is already required.
> In what way is it already required? Browsers are not required to store
> multiple resources for the same URI. We don't; we just use Vary to help
> (in)validate the resource we've got.
I mean that it is required for web application authors that want to
scale cheaply and have personalized pages. I don't think you agree
> So how would you use Vary here, anyway? Serve pages with "Vary: Cookie"? I
> guess that could work, but app authors would have to pass no cookies except
> for the session cookie. That could be difficult.
Or you could standardize the cookie value in some way.
> Using an HTTP response header to specify how a URI can map to multiple
> resources is a good idea, though. It avoids ambiguities and offers a simple
> default. If we have to have that feature, this seems like a good way to do
Etag and Content-Location could be used.
"I would have written a shorter letter, but I did not have the time."
More information about the whatwg