Browser stuck if no "Content-length:" in 302 http response header




Networking: HTTP
12 years ago
2 years ago


(Reporter: peterk, Unassigned)


1.8 Branch

Firefox Tracking Flags

(Not tracked)



(3 attachments, 1 obsolete attachment)



12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060710 Firefox/2.0b1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060710 Firefox/2.0b1

Browser stuck if no "Content-lenght:" in 302 http response header with no content data. 

Reproducible: Always

Steps to Reproduce:
1.Create 302 http response header without "Content-lenght:" in it.
2.Use sample server ot netcat to dump it as GET response

Actual Results:  
Browser stuck

Expected Results:  
Would expect it to behave more like IE (those bastards) and know to ignore it and proceed with redirection.

I know it is not really standard, but it would be nice to have it fixed especially 
now, when every piece of equipment has its own internal web server.
Component: General → Networking: HTTP
Product: Firefox → Core
QA Contact: general → networking.http
Version: unspecified → 1.8 Branch
hm... this is odd... could you attach a file suitable for use with netcat?
Summary: Browser stuck if no "Content-lenght:" in 302 http response header → Browser stuck if no "Content-length:" in 302 http response header

Comment 2

12 years ago
Created attachment 232524 [details]
input for netcat - with Content length - works fine

run it: nc -l -p1234 < 301.txt

Comment 3

12 years ago
Created attachment 232525 [details]
without Content lenght - browser stucked

run it: nc -l -p1234 < 301_no_cl.txt
I'm seeing this behaviour when attempting to use Firefox to access the web administration interface of a D-Link DSL-302G (running firmware R2.01M.B40.AU(021206a/T93.3.44)).

In this case, Firefox sends a 'GET /', and the HTTP server in the DSL-302G responds with an HTTP 302 with a Location header of '/hag/pages/home.ssi' and no Content-Length header or message body.  Firefox appears to hang at this point, but if you wait 100 seconds, it will send a 'GET /hag/pages/home.ssi' and continue to load the admin interface.

Unfortunately, the admin interface ends up being almost unusable in Firefox because many of the pages used in the admin interface's frames are subject to the same problem where the initial GET receives an HTTP 302 and Firefox waits for 100 seconds before sending a GET for the new location.
Created attachment 258936 [details]
TCP/HTTP trace

Here's a TCP/HTTP level trace of the described problem.  Note the times on frame #2 and frame #3.
Matthew, can you attach a trace containing all packets? (If nothing else, this one lacks ACKs, and of course some SYN ones)
Created attachment 258963 [details]
A more complete TCP trace

Sorry, I was a bit heavy handed in filtering the previous trace.  Here's another, this time including the TCP handshakes, etc.
Attachment #258936 - Attachment is obsolete: true
So, Mozilla only follows the redirect once the server closes the connection. That makes sense - Mozilla waits for the body of the redirect request. But we should probably follow the redirect earlier.

Hm, I think I've seen such a bug report before.

Comment 9

9 years ago
Same is for 501 response too. (At least for V3.0.11). This example response:

HTTP/1.1 501 Not Implemented<CR><LF>
Server: Raptor/0.1<CR><LF>

Should be OK, but Firefox shows still the processing sign, as it is waiting for data.
5xx is a different case, as for those Mozilla shows the server response. They really do need a content-length (or one of the other ways to indicate EOF)
The response is not complete.
Last Resolved: 2 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.