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 HenrikReceived on Friday, 20 October 2006 14:55:19 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 4 October 2011 12:13:56 GMT