I'm waiting to hear back from the webmasters to see what changed and
when, but it seems that my users cannot load particular pages that are
compressed by the web server on the fly. Tests to other modgzip example
sites are fine. I'm having a tough time finding a site that send
responses back the same way.

The server in question wants to send the response compressed, and sends
it chunked. The data returned to the browser is not modified at all,
and the payload matches what a chunked response should look like: first
line is size of the chunk in hex, last parts are a line with a 0 and two
newlines. Everything in between is the compressed data.

However, the headers that reach the client are inappropriate. No longer
is the session identified as chunked, but the proxy has slapped on a
content-length line which is inaccurate, and the leading and trailing
lines are still present. The new content length includes the whole payload.

I'm thinking if the proxy is going to un-chunk a transfer, shouldn't it
also remove the chunk header and footer? The effect I'm seeing is that
the client browsers don't know what to do with the final payload because
it doesn't uncompress properly, and they just show a blank screen.

Interestingly, I found that Wireshark would unchunk and uncompress the
pre-proxy transmission, but it similarly did not know how to process the
packets that actually came through the proxy.


Compare what the server sends to the proxy:

| HTTP/1.1 200 OK
| Status: 200 OK
| Content-Encoding: gzip
| Vary: Accept-Encoding
| Transfer-Encoding: chunked
| Content-Type: text/html; charset=UTF-8
|
| 35c6
| [data snipped]
| 0
|


With what the proxy sends to the client:

| HTTP/1.1 200 OK
| Status: 200 OK
| Content-Encoding: gzip
| Vary: Accept-Encoding
| Content-Type: text/html; charset=UTF-8
| Content-Length: 13779
| Proxy-Connection: close
|
| 35c6
| [data snipped]
| 0
|


Test it out on yours, if you would. http://www.stltoday.com/blogs/

Note that 0x35c6 is equal to 13766, and that the content length from the
proxy is 13779. The difference is "35c6\r\n" from the top and
"\r\n0\r\n\r\n" from the bottom, 13 characters exactly.

-j