1029493 - Firefox not properly responding to the closure of the server connection per RFC (408 response)

Status: UNCONFIRMED

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

Description

[Benedikt Hug]

Attachment: tcpdump.pcap

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:30.0) Gecko/20100101 Firefox/30.0 (Beta/Release)
Build ID: 20140605174243

Steps to reproduce:

-Visit http://www.godmode-trader.de/
-Open the network analysis tool in firefox to see when 408 responses show up
-Press F5 until the upper part of the advertisment is not visible anymore (the area is marked red on attached Screenshot_1) and the network analysis shows a 408 response (marked green).
-It can take up to 20 reloads until the error occurs


Actual results:

Firefox does not properly respond to the closure of the server connection per RFC if the closure also contains an HTTP response, and does not properly handle re-sending the request through a working connection, instead incorrectly assuming that the error response is the response to a newly sent request.
Attached is a tcpdump in which the behaviour described has been recored.


Expected results:

Realize that the connection has been closed by the server and don't give the user the 408 error as the apparent result of their request.

Chrome had exactly the same bug ( http://code.google.com/p/chromium/issues/detail?id=377581 ) which has been resolved in the mean time.

Comment 1

[Benedikt Hug]

Attachment: Screenshot_1.jpg

Comment 2

[Patrick McManus [:mcmanus]]

fwiw that 408 violates the basic HTTP BNF which doesn't have a concept of a response without a request. (It says that a server responds after receiving and interpreting a request message)

nonetheless there is code that tries to deal with it - so your testcase is appreciated. Its no doubt because of the TCP RST that is generated as part of it.

Comment 3

[Birger Brunswiek]

According to http://tools.ietf.org/html/rfc7230#section-3.4 the server may respond to an incomplete request (and not sending anything is an incomplete request) with an error message prior to closing the connection. This is exactly what the server does. So I do not think the server violates the protocol.

Comment 4

[Patrick McManus [:mcmanus]]

(In reply to Birger Brunswiek from comment #3)
>(and not sending anything is an incomplete
> request)

no :)

Comment 5

[Birger Brunswiek]

(In reply to Patrick McManus [:mcmanus] from comment #4)
> (In reply to Birger Brunswiek from comment #3)
> >(and not sending anything is an incomplete
> > request)
> 
> no :)

Well then you have a different interpretation of what incomplete is. I stick with mine unless there's a specific place in the RFC that says otherwise.

Comment 6

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 7

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 8

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, untouched DOM/Storage bug's priority.

If you have reason to believe, this is wrong, please write a comment and ni :jstutte.