The Apache folks are about to fix the problem that ETags are the same
for compressed and uncompressed versions of a resource:
https://issues.apache.org/bugzilla/show_bug.cgi?id=39727
Tomcat 6.0.18 suffers from the same problem.
The effect is that if a caching proxy holds a gzipped version of a
resource and is asked by a client for an unzipped version, it requests
one from the server with the ETag of the cached version. The server
sees that the ETag of the version it would send out is the same as that
of the version the cache already holds and tells the cache that its
version is OK (response status code 304). In the case of a Squid cache,
this results in a gzipped version to be sent to the client, and this
breaks in IE6 and IE7 when they are configured to use the HTTP 1.0 protocol.
Squid has been provided with a work-around option for this problem:
http://www.squid-cache.org/Versions/v2/2.6/cfgman/broken_vary_encoding.html
but we should not rely on caches world-wide to provide a work-around for
a Tomcat bug.
Regards,
Oliver Schoett
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
