[whatwg] Gears caching at identical URIs (was: Gears design goals)

On 7/3/07, Robert Sayre <sayrer at gmail.com> wrote:
>
> 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.


I don't know what you mean. Offline storage is a private cache and can
ignore Cache-Control:private.

> > 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
> with me.


The first app I checked (GMail) doesn't use Vary. If people aren't using it,
it can hardly be a requirement. Actually I'm skeptical that Vary helps much
with scalability, even if it works interoperably across browsers and caches:
presumably most content is going to have one global instance
(Cache-Control:public), or one instance per user (Cache-Control:private).
"Vary" only helps you cache content that falls in between. Do you know of
any examples of such content in existing apps?

> 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.


I thought about just specifying a standard session cookie name which always
becomes part of the cache key along with the URI ("HTML5-Session" or
something). But that doesn't work well, e.g. if you want some content to be
indexed by user and some content to be indexed by language.

A simple alternative would be a new server response header, say
X-Vary-Cookie: <cookiename>, which essentially means "Vary" for that
particular cookie (and offline storage uses it as a cue to cache one
resource per cookie value).

> 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
> > it.
>
> Etag and Content-Location could be used.


I think they're unnecessary given the above proposal.

Rob
-- 
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20070703/803a401b/attachment.htm>

Received on Monday, 2 July 2007 16:05:24 UTC