Bug 56569 - Null CRC in gzip footer with mod_cgid and ErrorDocument
Summary: Null CRC in gzip footer with mod_cgid and ErrorDocument
Status: RESOLVED FIXED
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_deflate (show other bugs)
Version: 2.4.9
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: FixedInTrunk
Depends on:
Blocks:
 
Reported: 2014-05-27 21:53 UTC by Brad Newman
Modified: 2018-03-27 17:39 UTC (History)
0 users



Attachments
Simple CGI script to reproduce (325 bytes, text/plain)
2014-05-27 21:53 UTC, Brad Newman
Details
Simple httpd configuration to reproduce (698 bytes, text/plain)
2014-05-27 21:54 UTC, Brad Newman
Details
Simple client script to reproduce (590 bytes, text/plain)
2014-05-27 21:54 UTC, Brad Newman
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Brad Newman 2014-05-27 21:53:09 UTC
When using a CGI as an ErrorDocument, together with mod_deflate to compress the response body, the CRC32 in the gzip footer may be null when the request also contained a request body.

I'll attach a simple httpd.conf and Bash CGI script that I've reproduced the issue with.  The issue is not unique to curl or Bash; it was originally encountered with a Perl CGI and Java client code.

A hex dump of the response bodies shows that the second to last 32-bit word - the CRC32 in the gzip footer - is null.  The responses are otherwise identical.

# Not working as expected - CRC is null
$ curl -s -HAccept-Encoding:gzip -XPOST -dbody http://localhost/cgi-bin/404 | xxd
0000000: 1f8b 0800 0000 0000 0003 3dcb 310e 8020  ..........=.1..
0000010: 1044 d1de 538c 950d f134 5e40 7102 24c2  .D..S....4^@q.$.
0000020: 1a76 8972 7b8d 85c9 2fdf 5f62 52bc a964  .v.r{.../._bR..d
0000030: a224 4f18 6f83 09bc e4b3 52d5 a1af 7d04  .$O.o.....R...}.
0000040: 96c8 4ae4 a686 8d60 9116 e287 1d78 2891  ..J....`.....x(.
0000050: 0c97 94c9 1068 ffcc 7d1e 1e00 0000 0063  .....h..}......c
0000060: 0000 00                                  ...

# Working as expected
$ curl -s -HAccept-Encoding:gzip -XPOST -dbody http://localhost/cgi-bin/test.cgi | xxd
0000000: 1f8b 0800 0000 0000 0003 3dcb 310e 8020  ..........=.1..
0000010: 1044 d1de 538c 950d f134 5e40 7102 24c2  .D..S....4^@q.$.
0000020: 1a76 8972 7b8d 85c9 2fdf 5f62 52bc a964  .v.r{.../._bR..d
0000030: a224 4f18 6f83 09bc e4b3 52d5 a1af 7d04  .$O.o.....R...}.
0000040: 96c8 4ae4 a686 8d60 9116 e287 1d78 2891  ..J....`.....x(.
0000050: 0c97 94c9 1068 ffcc 7d1e 1ee6 6eff 6b63  .....h..}...n.kc
0000060: 0000 00                                  ...


Oddly, in addition to the other conditions, the CRC is only null if the 404 occurs within the the cgi-bin directory (make-requests.sh will also be attached):

$ bash ~/make-requests.sh
direct to CGI, with request body:
via 404 in cgi-bin, with request body:

gzip: stdin: invalid compressed data--crc error
via 404 outside cgi-bin, with request body:
via 404 in cgi-bin, without request body:
Comment 1 Brad Newman 2014-05-27 21:53:40 UTC
Created attachment 31668 [details]
Simple CGI script to reproduce
Comment 2 Brad Newman 2014-05-27 21:54:31 UTC
Created attachment 31669 [details]
Simple httpd configuration to reproduce
Comment 3 Brad Newman 2014-05-27 21:54:56 UTC
Created attachment 31670 [details]
Simple client script to reproduce
Comment 4 Yann Ylavic 2014-06-06 16:44:57 UTC
Thanks Brad for reporting.

This is already fixed in trunk as part of bug 46146, and proposed for backport in 2.4.x.

Patch http://svn.apache.org/r1572671 works for 2.4.x if you can't wait.
Comment 5 Christophe JAILLET 2018-03-27 17:39:31 UTC
r1572671 has been backported in 2.4.x in r1604458.