Inflation fails for certain websites. Appears to be caused by lack of validaton bytes where they are expected. Commenting out validation bytes checking in mod_deflate.c does not fix the problem. Size of compressed data is reported as 1 byte in ctx->stream.total_in, uncompressed is 0. Condition can be provoked by requesting: www.cnn.com www.ebay.com Probably others as well
Can you please provide the changes that made it work for you as a patch. Even if this is not the solution is would be helpful for analysis of the problem.
I just tested both www.cnn.com and www.ebay.com (using my apache as forward proxy and commandline telnet to request uncompressed output), and got the correctly-uncompressed output. You've been confusing yourself and scaring the rest of us on IRC for rather a long time. Perhaps it would be a good idea to revert to a clean 2.2.6 install, and work from there.
Nick, In order to duplicate this bug, you need to be using Apache with mod_proxy enabled and mod_deflate in the filter chain set to INFLATE gzip-ed content. I'll be attached an httpd.conf for Apache 2.2.6 that provokes the buggy behavior.
Created attachment 20897 [details] httpd config for provoking mod_deflate bug
Also, forgot to mention two things: 1. Setting VALIDATON_SIZE to 0 fixes the problem when it pops up 2. Both cnn.com and ebay.com do occasionally send all 8 validation bytes. Please try making the request a few times before you conclude that there's nothing broken
Please set up a testcase for the alleged bug, so I can reproduce it. You can use mod_asis to set exact headers, as well as the gzipped data.
I'm working on a test case for you, but the bug is really not at all hard to reproduce. It shows up both with 2.2.6 and TRUNK. Both cnn.com and ebay.com routinely fail more than 50% of the time with both Firefox 1.5 and 2.0.
I have been so far unable to reproduce this bug by copying the responses geneated by by perl IO::Socket to .asis files. In such cases, the files are rendered perfectly through INFLATE. I will continue my attempts at creating a better test case but I'm quite exhausted at this point. Please note that this really is a bug and not a configuration issue. I would be glad to give someone access to my server if it allows him/her to more expediently identify that this is indeed a bug and not a figment of my imagination. Hopefully someone can take a look at this thing in earnest; I have not been having a pleasant time trying to fix it myself.
Another bit of information: The log output in error_log is Zlib: Validation bytes not present
I was able to reproduce this intermittently (2 requests fail w/ 0 length body, then a success) with: LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_http_module modules/mod_proxy_http.so LoadModule deflate_module modules/mod_deflate.so ProxyPass /proxy/ http://www.cnn.com/ LoadModule ext_filter_module modules/mod_ext_filter.so ExtFilterDefine foo mode=output cmd="/usr/bin/perl -p -e 's/^/|/g'" ftype=21 <location /proxy/> ExtFilterOptions debuglevel=999 Setoutputfilter INFLATE;foo;DEFLATE </location> I sent a request with wget and --header="Accept-Encoding: gzip"
Fixed in trunk - r580598. I expect you'll report back whether this fixes it for you. Comments: (1) Easy once I could reproduce the problem. (2) This is a problem that has affected many filters that worked fine in 2.0 when moving to 2.2. (3) Sorry about my initial scepticism!
Looking good ! I'll do some more testing and try to wrap my head around what you did later (seems like a two line fix, but I didn't immediately understand why it works...) Good night for now; hope to close out the ticket later. Thanks again.
2.2 r580916 http://svn.apache.org/viewvc?view=rev&revision=580916