https://issues.apache.org/bugzilla/show_bug.cgi?id=39727
Roy T. Fielding <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |ASSIGNED --- Comment #31 from Roy T. Fielding <[email protected]> 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: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
