DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39727>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=39727
Summary: Incorrect ETag on gzip:ed content
Product: Apache httpd-2
Version: 2.2.2
Platform: Other
OS/Version: other
Status: NEW
Severity: normal
Priority: P2
Component: mod_deflate
AssignedTo: bugs@httpd.apache.org
ReportedBy: hno@squid-cache.org
Entities gzip:ed by mod_deflate still carries the same ETag as the plain entiy,
causing inconsistency in ETag aware proxy caches.
It is very important each unique entity carries unique ETag:s as these identify
the specific entity variant of the URL. Each negotiated variant (where
Accept-Encoding is just one negotioantio parameter) needs to have unique ETag:s.
For mod_deflate it's as simple as adding the encoding to the already computed ETag.
This has implications on at least the following HTTP directives:
If-None-Match used in Vary negotiation from ETag aware caches
If-Range ranges in gzip:ed entity obviously not the same as ranges in
the plain entity
If-Match mainly conditional PUT requests
Example HTTP responses from an Apache-2.2.2 mod_deflate enabled server
(irrelevant headers pruned):
Plain request
Server: Apache/2.2.2 (Fedora)
ETag: "76e23-1835-4156af5e53ac0"
Content-Length: 6197
Vary: Accept-Encoding,User-Agent
Same request with "Accept-Encoding: gzip":
Server: Apache/2.2.2 (Fedora)
ETag: "76e23-1835-4156af5e53ac0"
Vary: Accept-Encoding,User-Agent
Content-Encoding: gzip
Content-Length: 1829
Implications of this:
* Clients may be given the incorrect response. In effect the first cached
response is given to all clients as If-None-Match indicates the entitiy is OK
for all clients.. (same ETag used in both responses -> Same If-None-Match
request so mod_deflate can not tell if the If-None-Match condition is on a
compressed or plain entity..)
* Clients doing range requests with If-Range may end up with corrupted objects
containing part compressed part plain content.
Squid-2.6 and later is ETag aware and will make this problem quite visible.
Release date for Squid-2.6 is 1/7 (i.e. in less than a month).
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
|