Tomos at Wikipedia wrote:
Brion-
I use several different combinations of IE and Windows, but Win 98 2nd
ed. and IE 6, Win XP and IE 6 seem to cause the problem. XP & Netscape 7
does not. I will send you further details via email.
After some time spent with a Win98 box and a packet sniffer, I think
I've found the problem.
The presence of this line in our HTTP response headers:
Vary: Accept-Encoding
causes IE6 to avoid caching the page. I've disabled it on
ja.wikipedia.org, please confirm if the behavior is changed for you.
The intent of this line is to keep proxy servers from re-serving
gzip-compressed cached pages to clients that don't advertise gzip
support. It shouldn't really matter, though, as we also tell proxies to
only re-serve pages to the original requesters as a protection against
leaking logged-in users' pages to other people (who would then see the
wrong user name, etc). (Further, compressed output is not yet supported
except through the anonymous user page cache, and is not enabled on the
server that ja.wiki is running on.)
I don't _think_ it will be problematic to remove it.
I'm pretty sure our usage is in accordance with specs, though. Extract
from RFC 2616, which defines HTTP 1.1:
------------------------------------
13.6 Caching Negotiated Responses
Use of server-driven content negotiation (section 12.1), as indicated
by the presence of a Vary header field in a response, alters the
conditions and procedure by which a cache can use the response for
subsequent requests. See section 14.44 for use of the Vary header
field by servers.
A server SHOULD use the Vary header field to inform a cache of what
request-header fields were used to select among multiple
representations of a cacheable response subject to server-driven
negotiation. The set of header fields named by the Vary field value
is known as the "selecting" request-headers.
When the cache receives a subsequent request whose Request-URI
specifies one or more cache entries including a Vary header field,
the cache MUST NOT use such a cache entry to construct a response to
the new request unless all of the selecting request-headers present
in the new request match the corresponding stored request-headers in
the original request.
------------------------------------
IE is technically not out of specs as far as I can tell; it seems to err
on the side of caution of that "MUST NOT" by just not caching anything
instead of doing the checks to determine matching. :P
-- brion vibber (brion @
pobox.com)