httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 39727] New: - Incorrect ETag on gzip:ed content
Date Mon, 05 Jun 2006 23:43:49 GMT
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


Mime
View raw message