- From: Robert Sayre <sayrer@gmail.com>
- Date: Mon, 2 Jul 2007 20:36:04 -0400
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."
Received on Monday, 2 July 2007 17:36:04 UTC