648710 - Delay before sending zero-length chunked body causes display corruption

Status: RESOLVED INVALID

(Core :: Networking: HTTP, defect)

Description

[Stephen Hurd]

User-Agent:       Opera/9.80 (X11; FreeBSD 8.2-RELEASE i386; U; en) Presto/2.7.62 Version/11.01
Build Identifier: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.18) Gecko/20110406 SeaMonkey/2.0.13

When there is a delay between sending the HTTP headers and a zero-length chunked HTTP body, and keep-alives are enabled, the zero-length token and the headers from the next request are displayed as plaintext instead of the web page.

Reproducible: Sometimes

Steps to Reproduce:
1. Browse around the Synchronet CVS web pages when remote system is under heavy load
Actual Results:  
Plaintext protocol level displayed in browser

Expected Results:  
Web page displayed in browser

I have a screenshot and corresponding wireshark capture available at http://nix.synchro.net/SeamonkeyGlitch/

I will attached these when I see a place to do so.

Comment 1

[Stephen Hurd]

Attachment: Wireshark capture of problem

The delay which appears to be causing the issue is between packets 6 and 10.

Comment 2

[Stephen Hurd]

Attachment: Screenshot when problem occurs

Comment 3

[Boris Zbarsky [:bzbarsky]]

Patrick, want to take a look?

Comment 4

[Patrick McManus [:mcmanus]]

The http response is invalid - 304 responses by definition do not have a response message body. This one has a zero lengthed chunked encoding. Stephen, wikipedia associates you with synchronet (I was looking for someone to cc: ;)) - can you just fix the server?


HTTP/1.1  304 Not Modified
Date: Sat, 09 Apr 2011 05:41:34 GMT
Connection: Keep-Alive
Server: Synchronet BBS for Linux  Version 3.15
Allow: GET, HEAD, POST, OPTIONS
Accept-Ranges: none
Transfer-Encoding: Chunked
Content-Type: text/html; charset=UTF-8
Expires: Sat, 09 Apr 2011 05:51:34 GMT
Cache-Control: max-age=600

0

Comment 5

[Stephen Hurd]

Yep, can and will.  Thanks.

It's a bit odd then that the delay is required to trigger the behaviour... also that it seems to be falling back to HTTP/0.9 for the rest of the session, but I guess stuff like that in undefined land is fine.  :-)

Sorry for the churn.