According to comments in bug 21561, the Vary header is currently used to mean that a response should *always* be revalidated at the server. This is very bad, since it discourages web sites from giving correct Vary headers since those headers will make the site slower for the user in Mozilla, and put more load on the server. This essentially destroys the Vary header feature of HTTP/1.1 for use on the web, except for use as "Vary: *". When a response has a Vary header of "*", the correct thing to do is probably just not cache the response. When a response has any other Vary header, the cache should remember the Vary header and the values of the request headers listed in that Vary header (or perhaps remember some hash function of them). If the headers are the same for a later request, then it should be treated as if the Vary header were not present. Only if the headers change should the response be revalidated. That's my interpretation of HTTP/1.1, anyway. See: http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.6 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.44

>When a response has a Vary header of "*", the correct thing to do is probably just not cache the response. We can cache it and can treat it as if it has "Expires: 0". RFC 2616 allows conditional GET to revalidate.

We will be able to ignore the "Vary:" header with the values other than "accept- charset", "accept-language", and "*" since Mozilla will not change the corresponding headers. This workaround is relatively simple and will improve the performance.

I have not seen servers sending Vary in the first place. Current workaround is just fine for the current release, IMHO.

They don't send Vary because current browsers mess it up. One of the goals of a standards-compliant browser is to allow authors to use the features of standards without having to worry that user agents will do the wrong thing.

If this prevents people from doing graceful degradation it should be essential for any release. What terrible amount of damage was done by NN4 by bad support for CSS and PNG alpha?

I don't think it's prudent to undertake large changes to the cache at this point for the sake of supporting full semantic of Vary header; especially when servers don't use it and we're not doing illegal things with it either.

Apache will always send "Vary: negotiate" for all content-negotiated page even if only one varient exists. For example: http://www.w3.org/TR/REC-CSS1 We should at least ignore the "Vary: negotiate". Mozilla will never send Negotiate. It is for proxy.

marking for later.

wontfix for now. It's good as it is.

The current support is unacceptable from a standards-compliance perspective (HTTP), and will cause authors to avoid the Vary header completely. Future if you want, but please don't WONTFIX. This should be fixed sometime. Reopening.

pulling in ruslan's necko bugs ->darin

http bugs to "Networking::HTTP"

I agree that this should be fixed. However, my interpretation of section 13.6 is that we ought to try to validate the cached response instead of just throwing it away in the case that the headers specified by the Vary header do not match. Here's the section that I talking about: If the selecting request header fields for the cached entry do not match the selecting request header fields of the new request, then the cache MUST NOT use a cached entry to satisfy the request unless it first relays the new request to the origin server in a conditional request and the server responds with 304 (Not Modified), including an entity tag or Content-Location that indicates the entity to be used. Since we already do such validation in other cases, it should not be too difficult to make this work here as well.

this is "fixed" when the new cache is enabled. by "fixed" i mean that we will FORCE_VALIDATE if the Vary header contains "*", "accept-charset", or "accept-language". this is not really a complete solution, since clients of HTTP can freely modify request headers, but this makes it work in the default case. marking FIXED.

Verified per darin's comment.