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

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

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

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

Regards
Henrik