[users@httpd] mod_fastcgi versus gzip headers issue

[Robin Becker <ro...@reportlab.com>]

I'm using a fastcgi script based on python+flup. I am having an issue with the 
fastcgi script  gzip encoding and the Content-Length header.

When I run the cgi version of the script in Firefox I get a fast response. The 
headers that are being sent with the response look like this

HTTP/1.1 200 OK
Date: Tue, 31 Jul 2012 15:40:39 GMT
Server: Apache/2.2.14 (Ubuntu)
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 3430
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/plain; charset=utf-8


when I run the fastcgi version I'm seeing

HTTP/1.1 200 OK
Date: Tue, 31 Jul 2012 15:41:16 GMT
Server: Apache/2.2.14 (Ubuntu)
Content-Length: 18310
Vary: Accept-Encoding
Content-Encoding: gzip
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/plain

and the firefox browser hangs waiting for more content.

A bit of debugging reveals that the actual document size is 18310 in fact the 
fastcgi script returns headers like this

fcgiwsgi.write final headers='Status: 200 OK\r\nContent-type: 
text/plain\r\nContent-Length: 18310\r\n\r\n'

which looks right. Wget returns a document of that length.

My problem is that it appears that the apache2 server (Apache/2.2.14 (Ubuntu) 
mod_fastcgi/2.4.6) is returning the length of the gzipped document with the 
original length 18310. Presumably the correct gzipped length is as in the cgi 
case ie 3430.

Is there some trick to fix apache / mod_fastcgi to return the correct content 
length.

I found that I can work around this problem by not returning a content length 
from the fastcgi script; the server then appears to use a chunked return and the 
browsers seem to be fine with that.
-- 
Robin Becker

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org