bugzilla at apache
Apr 29, 2012, 5:43 AM
Post #1 of 1
(53 views)
Permalink
|
|
[Bug 53160] New: Reverse Proxy mod_deflate doesn't zip back content in outgoing traffic
|
|
https://issues.apache.org/bugzilla/show_bug.cgi?id=53160
Priority: P2
Bug ID: 53160
Assignee: bugs [at] httpd
Summary: Reverse Proxy mod_deflate doesn't zip back content in
outgoing traffic
Severity: normal
Classification: Unclassified
OS: Linux
Reporter: alevy [at] salesforce
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.
|
