[Bug 381384] [NEW] mod_deflate with mod_fastcgi gives wrong content-length header

Martin von Gagern martin.vgagern at gmx.net
Thu May 28 16:47:02 UTC 2009


Public bug reported:

Binary package hint: libapache-mod-fastcgi

When compressing the content generated by mod_fastcgi, mod_deflate will
keep any Content-Length header created by the script, instead of
adjusting the header to match the compressed length.

References:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509116
http://article.gmane.org/gmane.comp.web.fastcgi.devel/1167

It seems that in surprisingly many cases this problem will go unnoticed by end users. Using Trac via FastCGI, however, I have encountered this issue repeatedly, and could even capture one instance using wireshark.
What I did was this:
1. Log into Trac account
2. Re-visit /trac/login
3. Get surprised by a Firefox dialog asking me to save the binary file "trac".

The traffic on the wire, starting at point 2 and reduced to the relevant
parts:

> GET /trac/login/ HTTP/1.1
> Keep-Alive: 300
> Connection: keep-alive

< HTTP/1.1 302 Found
< Content-Length: 0
< Location: http://host.name/trac
< Content-Encoding: gzip
< Keep-Alive: timeout=15, max=100
< Connection: Keep-Alive
< 
< [gzipped data, 0 bytes uncompressed, 26 bytes compressed]

> GET /trac HTTP/1.1
> Keep-Alive: 300
> Connection: keep-alive

< HTTP/1.1 301 Moved Permanently
< Content-Encoding: gzip
< Content-Length: 239
< Keep-Alive: timeout=15, max=99
< Connection: Keep-Alive
<
< [gzipped data, 297 bytes uncompressed, 239 bytes compressed]

What happens is this: firefox receives the first response, reads 0 bytes
of content, and either because it didn't find any gzip header in those 0
bytes, or because it gives Content-Length preference over Content-
Encoding in at least this case of a broken HTTP response, it decides
that's it. The first 16 bytes of the gzipped empty content which were
part of the same TCP frame as the headers seem to be discarded. However,
the remaining 10 bytes are still on the wire, in their own TCP frame.

Next, FF sends a request for the next location. In this case, it matches
a Redirect directive in my Apache configuration, so the next reply is
generated by Apache itself, not through mod_fastcgi. The response is all
right, but unfortunately, when reading it, FF first receives those 10
bytes left over from the last request. Seeing binary data instead of
headers, it decides this must be a bad server sending binary content
without headers, and offers to save this assumed binary file. When
loking at the file, it's those 10 bytes, followed by the headers and
compressed content for the next reply.

I had a look at some non-empty responses generated by
trac/fast_cgi/mod_deflate, and they, too, have Content-Length headers to
match the uncompressed content. In those cases, however, it seems FF
uses the gzip end-of-data encoding instead of relying on the Content-
Length header. So the HTTP protocol is still violated, but the browser
is lenitent enough so users won't notice.

http://article.gmane.org/gmane.comp.web.fastcgi.devel/1167 gives a good
indication as to what's causing this problem. Seems that mod_fastcgi
copies all headers sent by a script to err_headers_out, with the
exception of a few well known like "Location", which it copies to
headers_out instead. There is even a patch to do the same special-case
handling for Content-Length, but the author argues that other headers
might require similar behaviour.

The Debian bug does indicate libapache2_mod_fcgid as an alternative
which doesn't exhibit this behaviour. It is not an easy drop-in
replacement, though, as it doesn't accept extra path components after
the file name in a ScriptAlias, and as the Apache configuration has to
be changed due to a different module file name for IfModule checks and
different configuration directives. So simply switching is not always a
solution.

** Affects: libapache-mod-fastcgi (Ubuntu)
     Importance: Undecided
         Status: New

** Affects: libapache-mod-fastcgi (Debian)
     Importance: Unknown
         Status: Unknown

** Bug watch added: Debian Bug tracker #509116
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509116

** Also affects: libapache-mod-fastcgi (Debian) via
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509116
   Importance: Unknown
       Status: Unknown

-- 
mod_deflate with mod_fastcgi gives wrong content-length header
https://bugs.launchpad.net/bugs/381384
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

-- 
ubuntu-bugs mailing list
ubuntu-bugs at lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs




More information about the universe-bugs mailing list