https://issues.apache.org/bugzilla/show_bug.cgi?id=53160

          Priority: P2
            Bug ID: 53160
          Assignee: [email protected]
           Summary: Reverse Proxy mod_deflate doesn't zip back content in
                    outgoing traffic
          Severity: normal
    Classification: Unclassified
                OS: Linux
          Reporter: [email protected]
          Hardware: PC
            Status: NEW
           Version: 2.2.3
         Component: mod_deflate
           Product: Apache httpd-2

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.

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

Reply via email to