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

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

Aha.

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.

Yep.

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