httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject DO NOT REPLY [Bug 39727] Incorrect ETag on gzip:ed content
Date Fri, 13 Feb 2009 01:08:58 GMT

Roy T. Fielding <> changed:

           What    |Removed                     |Added
             Status|REOPENED                    |ASSIGNED

--- Comment #31 from Roy T. Fielding <>  2009-02-12 17:08:56 PST
The HTTP syntax error has been fixed in trunk, but the problem
motivating this report is a no-win situation no matter how it is
"fixed".  The only good answer is "don't use mod_deflate" because
changing content-encoding on the fly in an inconsistent manner
(neither "never" nor "always) makes it impossible for later
requests regarding that content (e.g., PUT or conditional GET)
to be handled correctly.  This is, of course, why performing
on-the-fly content-encoding is a stupid idea, and why I added
Transfer-Encoding to HTTP as the proper way to do on-the-fly
encoding without changing the resource.

mod_deflate is written as a content filter that can be arbitrarily
added to the output chain after the request is processed, just
before the body goes out on the wire.  If mod_deflate modifies
ETag on the way out, then its corresponding later requests must
be reverse-modified (etags and request content) on the way back.

The problem here is that the DEFLATE filter is usually
added after the request is processed, based on the media type
of the response, so there is no clear way of selectively inflating
a corresponding PUT or conditional request before the request
processing is begun, especially if the request has been
proxied to another server.  We would have to add a corresponding
input filter whenever the output filter is configured and ensure
that it would activate under the same conditions, based on the
request header fields, as DEFLATE/INFLATE does for responses.
I am still looking at this option.

Preprocessing all incoming conditional headers to remove
a -gzip suffix before the request is processed won't work.
In a chain of Apache servers, we won't know which server
set the suffix and how many caches have stored the modified
ETag versus the unmodified ETag.  We can't add some random
unique id to the suffix, either, since we need the tag to
persist across restarts.  In any case, that solution becomes
so complex that we are better off deleting the module.

Finally, we can't just remove the ETag because then the
unfiltered content has an ETag but the filtered content
does not, which puts us back to the point of messing up
a cache that is checking the 304 response for consistency.
Likewise, removing etags for the entire configured scope
allows clients to use the last-modified timestamp for range
requests, which would be just as bad as not changing ETag.

The best solution is to implement transfer-encoding as an
http protocol filter module.

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message