W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2006

Re: ETags vs Variants, was: Revising RFC2616 - what's happening

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 20 Oct 2006 17:05:09 +0200
Message-ID: <4538E5A5.5080601@gmx.de>
To: Henrik Nordstrom <hno@squid-cache.org>
CC: HTTP Working Group <ietf-http-wg@w3.org>

Henrik Nordstrom schrieb:
> fre 2006-10-20 klockan 14:28 +0200 skrev Julian Reschke:
>>> What isn't very clear to me was what change in Vary means on a URI.
>> Sorry?
> When one cached variant has one Vary header, and then another variant is
> received with a different Vary header. Lets say the first has
> Vary: Accept-Language
> and the second
> Vary: Accept-Encoding


I would say that if the value for "Vary" changes between to HTTP 
requests, the sever implementation/configuration has somehow changed, 
and a proxy should invalidate all cached entries for that URI.

>>> But many shared proxy caches still don't cache Vary responses at all.
>> Well, those aren't HTTP/1.1 compliant, so there's nothing we can do 
>> about those.
> It's fully compliant not to cache a response. Caching is entirely
> optional.
> The reason why many do not cache Vary responses is
> a) It wasn't very common some years ago
> b) Caching of Vary quickly becomes very complex, in large due to the RFC
> not being very easy to understand what Vary really means, its relations
> to ETag, If-None-Match etc.
> c) Many broken servers out there.
> In fear of doing a non-compliant implementation or causing too much
> trouble due to others malfunctions most select the safe path and doesn't
> cache it at all.

Yep. Maybe we can improve proxy support by improving the spec text.

>> One of the reasons may be broken handling of Vary headers in user 
>> agents, mainly IE 
>> (<http://support.microsoft.com/default.aspx?scid=kb;en-us;824847>), but 
> It's still HTTP compliant, just that it doesn't work when sending the
> file to external applications.. If I understand the bug description

"just"? The user follows a link and gets a completely misleading error 
message, although the server works just fine.

> correct you should also get the same issue with their user-agent on
> other "uncacheable" content.


>> also Firefox (<https://bugzilla.mozilla.org/show_bug.cgi?id=269303#c30>).
> The most interesting there is the reasoning about if the bug should be
> considered a bug.. But it's clearly not HTTP compliant today.

Best regards, Julian
Received on Friday, 20 October 2006 15:05:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:40 UTC