When working with httpd in reverse proxy mode, mod_deflate doesn't zip back content in outgoing traffic. The usual configuration of mod_deflate is rather simple, but doesn't cover reverse proxy cases: SetOutputFilter INFLATE SetInputFilter DEFLATE This bug was investigated with mod_dumpio. When incoming http traffic from client contains "content-encoding" in http header: dumpio_in (data-TRANSIENT): 37 bytes dumpio_in (data-TRANSIENT): POST /services/Soap/u/24.0 HTTP/1.1\r\n dumpio_in [getline-blocking] 0 readbytes dumpio_in (data-TRANSIENT): 24 bytes dumpio_in (data-TRANSIENT): Content-Encoding: gzip\r\n dumpio_in [getline-blocking] 0 readbytes dumpio_in (data-TRANSIENT): 23 bytes dumpio_in (data-TRANSIENT): Accept-Encoding: gzip\r\n dumpio_in [getline-blocking] 0 readbytes dumpio_in (data-TRANSIENT): 16 bytes mod_deflate unzip the content properly, but as the request leaves the proxy toward the remote web server, the content remains unzipped, while header still contains the tag: Content-Encoding: gzip\r\n. This results in data inconsistency - thus remote server refuses to accept the request. the same occurs back in response: Zipped Content arriving in response from remote web server, is inflated in proxy, but then when response is going toward client (after proxy) the content is not zipped, while header still exists. Resulting client application receiving errors. I had to create a w/a for this issue, in order to overcome the bug: In PRSFixup, I'm removing the "content-encoding", and "accept-encoding" tags. So that it will not be sent to remote server, but, I have to add back the "content-encoding" tag in aprHook, in order for mod_deflate to inflate the content, so that our proprietary filter will be able to work properly. But, as a result, network traffic is enlarged dramatically. To summarize, This bug contains two different bugs: 1. mod_deflate promises to remove the "content-encoding : gzip" from HTTP header, but upon inflating content, somehow apache proxy leaves the tag in outgoing request. 2. mod_deflate doesn't contain appropriate filter to zip back outgoing request content when apache is working in reverse proxy mode.
Logs will be added according to request.
I can confirm the left-in Content-encoding header, which breaks a proxy chain in which every proxy is configured with InputFilter Deflate, for versions 2.2.18 to 2.2.22. To fix mod_deflate not recompressing outgoing requests please try SetOutputFilter INFLATE;DEFLATE or SetOutputFilter INFLATE;proxy-html;DEFLATE (according to http://www.apachetutor.org/apps/reverseproxies and/or http://www.apachetutor.org/admin/reverseproxies)
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd. As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd. If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question. If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with. Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.