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

[Robert Sayre]

On 7/2/07, Robert O'Callahan <robert at ocallahan.org> wrote:
> 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.

Seems to me that if you are worried about users seeing content
intended for other users, it isn't a private cache.

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

It helps quite a bit when you're close to the source, but see below:

Here are some examples:
http://www.djangobook.com/en/beta/chapter14/#cn125
http://webmaster.info.aol.com/vary.html
http://oregonstate.edu/~hopsonro/2006/10/01/internet-explorer-fails-to-explore-internet/
http://www.somebits.com/weblog/tech/modgzipMSIECache.html

So, there you have it. mod_rewrite, mod_gzip, django, and AOL are
pretty popular. And IE is kinda broken.

> >
> > Etag and Content-Location could be used.
>
> I think they're unnecessary given the above proposal.

They're unnecessary if you restrict the proposal to read-only content.
And I suppose that makes sense for negotiated resources. So I agree
that we need to invent a new header to compensate for the fact
authentication is brokenly included in with the cookies in almost all
HTTP apps, and route around a certain browser.

Par for the course in HTTP conformance, I guess. :/

-- 

Robert Sayre

"I would have written a shorter letter, but I did not have the time."