[whatwg] Gears caching at identical URIs (was: Gears design goals)
sayrer at gmail.com
Mon Jul 2 17:36:04 PDT 2007
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:
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. :/
"I would have written a shorter letter, but I did not have the time."
More information about the whatwg