httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Wang <>
Subject [users@httpd] Chunked transfer delay with httpd 2.4 on Windows.
Date Mon, 19 Oct 2015 21:44:14 GMT
Hi all,
I'm seeing a weird problem that I'm running out of ideas on.  I'm going 
to send this email to both the apache httpd users list and the tomcat 
users list (separate messages) but hoping for any ideas at all.

The issue is currently reproduced using Apache httpd 2.4.16, mod_jk 
1.2.41 and tomcat 8.0.28.

I've created a very very simple JSP page that does nothing but print a 
small string, but I've tried changing the jsp page to print a very very 
large string (10000+ characters) and no difference.

If I POST to this JSP page, and something like mod_deflate is in place 
to force a chunked transfer the TCP packet capture looks like this:

No.     Time           Source  Destination   Protocol Length Info
    1850 4827.762721000 client  server        TCP      66     54131→2280 
[SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
    1851 4827.764976000 server  client        TCP      66     2280→54131 
[SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
    1852 4827.765053000 client  server        TCP      54     54131→2280 
[ACK] Seq=1 Ack=1 Win=131328 Len=0
    1853 4827.765315000 client  server        HTTP     791    POST 
/JSPtoPostTo HTTP/1.1
    1854 4827.777981000 server  client        TCP      466    [TCP 
segment of a reassembled PDU]
    1855 4827.982961000 client  server        TCP      54     54131→2280 
[ACK] Seq=738 Ack=413 Win=130816 Len=0
    1856 4832.770458000 server  client        HTTP     74     HTTP/1.1 
200 OK  (text/html)
    1857 4832.770459000 server  client        TCP      60     2280→54131 
[FIN, ACK] Seq=433 Ack=738 Win=65536 Len=0
    1858 4832.770555000 client  server        TCP      54     54131→2280 
[ACK] Seq=738 Ack=434 Win=130816 Len=0
    1859 4832.770904000 client  server        TCP      54     54131→2280 
[FIN, ACK] Seq=738 Ack=434 Win=130816 Len=0
    1860 4832.774200000 server  client        TCP      60     2280→54131 
[ACK] Seq=434 Ack=739 Win=65536 Len=0

Spdficially, note the 5 second delay between the first segment (No. 
1854) and the second data segment (1856).
The first segment contains the headers, the second segment contains the 
mod_deflate compressed contents.

Here's where it gets sort of interesting.
I can only reproduce this with one client.  We have a custom NPAPI 
plugin that this problem occurs on with all versions of firefox.  I 
cannot reproduce it with any other client.  I've used HttpRequester 
extension on firefox to construct an arbitrary POST.  I've copied the 
raw HTTP request from the wireshark capture:


Host: host:2280
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Cookie: JSESSIONID=F3B0524C87BD94396CCDE40FF837D2F8.tomcat1
Authorization: Basic d2NhZG1pbjp3Y2FkbWlu
Connection: keep-alive
Content-length: 0
Content-Type: text/plain

and used ncat and curl to attempt to simulate the request and no luck 
reproducing it.

This does not occur with Apache httpd 2.2.31 and mod_jk 1.2.41.  And so 
far, it only occurs when the server is on Windows.

I can't come up with any scenario where I can explain how the client 
could possibly be the factor.

I've enabled mod_jk's trace logging and according to mod_jk the ajp 
request was handled and processed in less than a second.

The timing really seems to imply that this is all somwhere in 
mod_deflate.  But I've tried something similar by creating an html file 
and request it via a POST instead of a GET and the problem doesn't occur 

Hoping for any ideas on where to go with this.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message