Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 593715

Summary: mod_deflate does not flush output stream if handler performs flush.
Product: Red Hat Enterprise Linux 5 Reporter: Martin Poole <mpoole>
Component: httpdAssignee: Joe Orton <jorton>
Status: CLOSED ERRATA QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: high Docs Contact:
Priority: high    
Version: 5.5CC: cww, jwest, tao
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-01-13 23:50:52 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
modperl routine to demonstrate flush bug. none

Description Martin Poole 2010-05-19 14:56:32 UTC 
Created attachment 415149 [details]
modperl routine to demonstrate flush bug.

Description of problem:

mod_deflate does not handle the case where a layered handler performs a flush as part of a long response.

Version-Release number of selected component (if applicable):

httpd-2.2.3-43.el5

How reproducible:

Always.

Steps to Reproduce:

1. add the following to /etc/httpd/conf/httpd.conf


PerlRequire /var/www/modperl/startup.pl
# contains
#
# use lib qw(/var/www/modperl);
# 1;

<Location /blob>
    SetHandler perl-script
    PerlResponseHandler  Rolls
</Location>
<Location /blobz>
    SetOutputFilter DEFLATE
    SetEnv      force-gzip 1
    SetHandler perl-script
    PerlResponseHandler  Rolls
</Location>


2. put attached Rolls.pm file in /var/www/modperl/


3. monitor timestamps of output with

   tcpdump -n -p -i lo -ttt port 80

4. perform

   lwp-request http://localhost/blob

5. perform

   lwp-request http://localhost/blobz | gunzip


Actual results:

for blob (uncompressed, normal case, works as expected)

000000 IP 127.0.0.1.43872 > 127.0.0.1.http: S 2958257335:2958257335(0) win 32792 <mss 16396,sackOK,timestamp 167903379 0,nop,wscale 7>
000435 IP 127.0.0.1.http > 127.0.0.1.43872: S 2957199257:2957199257(0) ack 2958257336 win 32768 <mss 16396,sackOK,timestamp 167903379 167903379,nop,wscale 7>
000354 IP 127.0.0.1.43872 > 127.0.0.1.http: . ack 1 win 257 <nop,nop,timestamp 167903379 167903379>
000295 IP 127.0.0.1.43872 > 127.0.0.1.http: P 1:117(116) ack 1 win 257 <nop,nop,timestamp 167903386 167903379>
000225 IP 127.0.0.1.http > 127.0.0.1.43872: . ack 117 win 256 <nop,nop,timestamp 167903386 167903386>
000125 IP 127.0.0.1.http > 127.0.0.1.43872: P 1:2203(2202) ack 117 win 256 <nop,nop,timestamp 167903411 167903386>
000377 IP 127.0.0.1.43872 > 127.0.0.1.http: . ack 2203 win 291 <nop,nop,timestamp 167903411 167903411>
9. 999887 IP 127.0.0.1.http > 127.0.0.1.43872: P 2203:3006(803) ack 117 win 256 <nop,nop,timestamp 167913413 167903411>
000034 IP 127.0.0.1.43872 > 127.0.0.1.http: . ack 3006 win 325 <nop,nop,timestamp 167913414 167913413>
000290 IP 127.0.0.1.http > 127.0.0.1.43872: P 3006:3011(5) ack 117 win 256 <nop,nop,timestamp 167913414 167913414>
000006 IP 127.0.0.1.43872 > 127.0.0.1.http: . ack 3011 win 325 <nop,nop,timestamp 167913414 167913414>
000157 IP 127.0.0.1.http > 127.0.0.1.43872: F 3011:3011(0) ack 117 win 256 <nop,nop,timestamp 167913414 167913414>
000515 IP 127.0.0.1.43872 > 127.0.0.1.http: F 117:117(0) ack 3012 win 325 <nop,nop,timestamp 167913415 167913414>
000010 IP 127.0.0.1.http > 127.0.0.1.43872: . ack 118 win 256 <nop,nop,timestamp 167913415 167913415>

6th packet is first file, then 10 second delay, then 8th packet is file two.


compressed fetch

000000 IP 127.0.0.1.32945 > 127.0.0.1.http: S 3186852014:3186852014(0) win 32792 <mss 16396,sackOK,timestamp 168110795 0,nop,wscale 7>
000170 IP 127.0.0.1.http > 127.0.0.1.32945: S 3192208817:3192208817(0) ack 3186852015 win 32768 <mss 16396,sackOK,timestamp 168110795 168110795,nop,wscale 7>
-1. 999860 IP 127.0.0.1.32945 > 127.0.0.1.http: . ack 1 win 257 <nop,nop,timestamp 168110795 168110795>
007636 IP 127.0.0.1.32945 > 127.0.0.1.http: P 1:118(117) ack 1 win 257 <nop,nop,timestamp 168110803 168110795>
000019 IP 127.0.0.1.http > 127.0.0.1.32945: . ack 118 win 256 <nop,nop,timestamp 168110803 168110803>
023503 IP 127.0.0.1.http > 127.0.0.1.32945: P 1:239(238) ack 118 win 256 <nop,nop,timestamp 168110826 168110803>
000018 IP 127.0.0.1.32945 > 127.0.0.1.http: . ack 239 win 265 <nop,nop,timestamp 168110826 168110826>
10. 003617 IP 127.0.0.1.http > 127.0.0.1.32945: P 239:1289(1050) ack 118 win 256 <nop,nop,timestamp 168120827 168110826>
000025 IP 127.0.0.1.32945 > 127.0.0.1.http: . ack 1289 win 281 <nop,nop,timestamp 168120827 168120827>
000560 IP 127.0.0.1.32945 > 127.0.0.1.http: F 118:118(0) ack 1289 win 281 <nop,nop,timestamp 168120828 168120827>
003550 IP 127.0.0.1.http > 127.0.0.1.32945: F 1289:1289(0) ack 119 win 256 <nop,nop,timestamp 168120831 168120828>
000011 IP 127.0.0.1.32945 > 127.0.0.1.http: . ack 1290 win 281 <nop,nop,timestamp 168120831 168120831>

packet 6 is only response prior to compression starting.
then 10 seconds delay,
packet 8 is first file, followed immediately by file two in packet 10.


Expected results:

compressed fetch

000000 IP 127.0.0.1.43873 > 127.0.0.1.http: S 3012643382:3012643382(0) win 32792 <mss 16396,sackOK,timestamp 167958161 0,nop,wscale 7>
000167 IP 127.0.0.1.http > 127.0.0.1.43873: S 3022677064:3022677064(0) ack 3012643383 win 32768 <mss 16396,sackOK,timestamp 167958161 167958161,nop,wscale 7>
000045 IP 127.0.0.1.43873 > 127.0.0.1.http: . ack 1 win 257 <nop,nop,timestamp 167958161 167958161>
007830 IP 127.0.0.1.43873 > 127.0.0.1.http: P 1:118(117) ack 1 win 257 <nop,nop,timestamp 167958169 167958161>
000018 IP 127.0.0.1.http > 127.0.0.1.43873: . ack 118 win 256 <nop,nop,timestamp 167958169 167958169>
024949 IP 127.0.0.1.http > 127.0.0.1.43873: P 1:1016(1015) ack 118 win 256 <nop,nop,timestamp 167958194 167958169>
000018 IP 127.0.0.1.43873 > 127.0.0.1.http: . ack 1016 win 273 <nop,nop,timestamp 167958194 167958194>
10. 003098 IP 127.0.0.1.http > 127.0.0.1.43873: P 1016:1298(282) ack 118 win 256 <nop,nop,timestamp 167968191 167958194>
000023 IP 127.0.0.1.43873 > 127.0.0.1.http: . ack 1298 win 288 <nop,nop,timestamp 167968191 167968191>
001873 IP 127.0.0.1.http > 127.0.0.1.43873: P 1298:1318(20) ack 118 win 256 <nop,nop,timestamp 167968193 167968191>
000077 IP 127.0.0.1.43873 > 127.0.0.1.http: . ack 1318 win 288 <nop,nop,timestamp 167968193 167968193>
000368 IP 127.0.0.1.43873 > 127.0.0.1.http: F 118:118(0) ack 1318 win 288 <nop,nop,timestamp 167968194 167968193>
003482 IP 127.0.0.1.http > 127.0.0.1.43873: F 1318:1318(0) ack 119 win 256 <nop,nop,timestamp 167968197 167968194>
000011 IP 127.0.0.1.43873 > 127.0.0.1.http: . ack 1319 win 288 <nop,nop,timestamp 167968197 167968197>

compressed file one as part of packet 6,
compressed file two as packet 8


Additional info:

Upstream adopted a fix for this in

  https://issues.apache.org/bugzilla/show_bug.cgi?id=39854

but this is a wrap-up bug containing a large number of fixes to the module.

The individual fix for the specific flush problem is in

  http://svn.apache.org/viewvc?view=revision&revision=422731

which I used in the above tests.
Comment 1 Joe Orton 2010-05-19 15:28:49 UTC 
Thanks a lot for narrowing it down.  This will be fine for backport.
Comment 4 RHEL Program Management 2010-08-09 19:52:14 UTC 
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 11 errata-xmlrpc 2011-01-13 23:50:52 UTC 
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0130.html