61229 - Mozilla waits indefinitely when Content-length: 0

Status: VERIFIED FIXED

(Core :: Networking: HTTP, defect, P3)

Description

[Cyril Elkaim]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.14-5.0 i686; en-US; m18) Gecko/20001121
BuildID:    2000112108

When a document has its Content-length: 0 Mozilla waits forever. Netscape 4.X
doesn't exhibit this behavior. I think the browser should simply stop waiting
and give the control back to the user like Netscape.

Reproducible: Always
Steps to Reproduce:
Simply point to an URL that's a CGI script for example that does some stuff but
doesn't return anything back to the browser. Or any document having none content
and a Content-length: 0.

Actual Results:  Mosilla waits indefinitly. You must stop the browser yourself.
Not very clean I think.

Expected Results:  Browser should simply do nothing, waiting the user to give
him another command.

Simply press the stop button to get the control back

Comment 1

[Jason Eager]

Cyril: Can you give us a test case?

Comment 2

[Richard Brodie]

Confirming. Win98/Gecko 20001212.

I was able to reproduce the hang on a test server with a trivial CGI script. 
Unfortunately, I can't host it permanently as a testcase. 

Comment 3

[Keyser Sose]

Marking NEW as per comments.

Comment 4

[Colin Blake]

I see this problem a lot with older servers where there is no Content-length
header. With newer servers and CGI scripts and where a Content-length is not
generated, Mozilla DOES successfully stop loading. Why is this? I think its
because the newer servers use chunked Transfer-Encoding, and this is
effectively the same as passing Content-length.

Unfortunately my old FastTrack 3.01 server where I can reproduce this problem
is behind a firewall, but anyone with access to a FastTrack 3.01 server should
be able to reproduce this with a simple CGI such as:

echo "Content-type: text/plain"
echo ""
echo "Content"

Newer servers such as Apache 1.3.6 wrap the content up in a chunk.

Comment 5

[Gagan]

I am a little confused about this last comment. To me not having the 
"content-length" header is a different problem than having one with a value of 
zero. I believe this bug deals with the latter, if thats not a correct 
understanding than please explain. thanks.

Comment 6

[Colin Blake]

Gagan, you are right. I didn't read the original text well enough. I am talking 
about something different. I will enter a new bug.

Comment 7

[Olav Vitters]

Testcase URL: http://www.tecform.nl/cgi-bin/61229.cgi

Comment 8

[Darin Fisher]

over to networking:http

Comment 9

[timeless]

*** Bug 70906 has been marked as a duplicate of this bug. ***

Comment 10

[Boris Zbarsky [:bzbarsky]]

Possible dup of bug 70170?  jst?

Comment 11

[Johnny Stenback (:jst)]

Nope, not a dup of bug 70170, I think this could be a HTML parser problem tho,
i.e. if it doesn't get any data it probably doesn't do anything, thus the
"hang". Cc:ing [e-mail]

Comment 12

[harishd]

does this still happen? I'm not seeing the problem. 

Comment 13

[Olav Vitters]

Using Build ID 2001031321. Testcases from (duplicate) bug 70906 work. Also
Mozilla does NOT hang anymore with testcase
http://www.tecform.nl/cgi-bin/61229.cgi (although Mozilla still waits +/- 15
seconds before noticing the empty file).

Comment 14

[Colin Blake]

The 15 second pause is, I believe, because that's how long it is before the 
remote server disconnects the network link.

Comment 15

[Darin Fisher]

my changes for bug 76866 will fix this bug as well.

Comment 16

[Darin Fisher]

fixed with http branch landing

Comment 17

[Tom Everingham]

verified:
Linux rh6 2001061308

Comment 18

[Cyril Elkaim]

Tried with the Linux 2001062021 build and working.

Thanks guys for the good work