#19 apache/mod_rewrite/mod_gzip and Expect: 100 header
If the Expect: 100-continue header is passed in a
request to the apache server
which has mod_rewrite configured to forward the
request to an IIS server the
resulting page is never zipped by mod_gzip. Removing
the Expect: 100 header
returns a zipped page. The mod_gzip log looks like this.
Successful zip
10.254.33.174 - - [16/Oct/2003:18:10:24 -
0700] "qagateway01.qa.myco.com
POST /ws/api.dll HTTP/1.1" 200 477 mod_gzip: OK
In:1258 -< Out:262 = 80 pct.
Unsuccessful zip
10.254.33.174 - - [16/Oct/2003:18:54:32 -
0700] "qagateway01.qa.myco.com
POST /ws/api.dll HTTP/1.1" 200 1480 mod_gzip:
SEND_AS_IS:NO_200 In:0 -< Out:0 =
0 pct.
The headers in the unsuccessful response look like this.
It's difficult to
tell if both headers are part of the same response.
HTTP/1.1 100 Continue
HTTP/1.1 200 OK
Date: Fri, 17 Oct 2003 01:30:18 GMT
Server: Microsoft-IIS/4.0
Content-Type: text/xml
Content-length: 1258
X-Cache: MISS from qagateway01.qa.ebay.com
Connection: close
The request is also zipped if mod_rewrite is removed
from the equation
regardless of the Expect: 100-continue header.
Unfortunately Expect: 100-continue is required in
MS .Net httpwebrequest class
but I was also able to replicate this bug with a perl
script.
Logged In: YES
user_id=211909
mod_gzip assumes that a content to be compressed can only be
present it the Apache server tagged the response with a "2x"
(successfull) status value.
According to
http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6 a
HTTP response is not assumed to contain more than one status
line, so when mod_gzip receives the "100 continue" it
doesn't expect any other status line after that and doesn't
see any reason to compress the centent of this response.