749839 - Speculative HTTP connect gets wedged if server replies before request sent

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect)

Description

[Jason Duell]

Not sure if this is a bug, logically speaking, but I can imagine it breaking stuff on the Internet.

I just noticed that using 'nc -l [PORT] <http_response_stored_in_file" style debugging now requires that you also pass "-i 1" (delay writing response for 1 second), otherwise Firefox just sits there.  Looking at Wireshark shows nc sends the reply, and firefox never sends the HTTP request.  Debugging I see the request has mStatus set to NS_BINDING_ABORTED by the time OnStartRequest is called.

I'm guessing this is fallout from the new speculative connection logic we just landed (bug 729133).

Although it's logically wrong for an HTTP server to reply before receiving the request, I wouldn't be surprised if it happens in the wild.

Comment 1

[Honza Bambas (:mayhemer)]

Could this be related to bug 739522 ?

Comment 2

[Patrick McManus [:mcmanus]]

jason can you explain what you mean by wedge? I see a hard fail for the transaction, and I just want to make sure we see the same thing.

the root of this is pretty intentional - it doesn't make any sense to see response data when we haven't sent the request - the server would have to be psychic to know what request it is responding to.. and data in that state is a good sign that pconns or pipelines will fail, so we've been checking on that in between transactions to determine reuse for a while.

The twist with speculative connect is that we have a "reuse" moment between the connection and the first http transaction, which is why you see it now.

It makes sense and trivial to only do that check after having processed a http transaction.

If that's the issue honza, it won't be related to 739522 :)

Comment 3

[Patrick McManus [:mcmanus]]

Attachment: patch.0

Comment 4

[Honza Bambas (:mayhemer)]

(In reply to Patrick McManus [:mcmanus] from comment #2)
> jason can you explain what you mean by wedge? I see a hard fail for the
> transaction, and I just want to make sure we see the same thing.
> 
> the root of this is pretty intentional - it doesn't make any sense to see
> response data when we haven't sent the request - the server would have to be
> psychic to know what request it is responding to.. and data in that state is
> a good sign that pconns or pipelines will fail, so we've been checking on
> that in between transactions to determine reuse for a while.
> 
> The twist with speculative connect is that we have a "reuse" moment between
> the connection and the first http transaction, which is why you see it now.
> 
> It makes sense and trivial to only do that check after having processed a
> http transaction.
> 
> If that's the issue honza, it won't be related to 739522 :)


> nc -l [PORT] <http_response_stored_in_file

Ah, right, I didn't read carefully first :)

So, according the patch, it seems that server returns some data before we even send a request.  So it may indicate that the server mistakenly have sent some data on a wrong connection or it has sent the "timeout" response (40? or 50? - I don't remember).

It might be used for http pipeline framing errors catching or just catching on stupid servers.  But that would need some fallback/retry, not making Firefox just "sit there".  However, I would expect it not to happen even w/o this patch...  If this can happen (that we stuck), then I allow my self to believe a little bit it could be somehow related to bug 739522...

Comment 5

[Jason Duell]

Comment on attachment 619332 [details] [diff] [review]
patch.0

Review of attachment 619332 [details] [diff] [review]:
-----------------------------------------------------------------

Yes, this fixes it.

FYI: ran the code w/o the patch some more, and what I was seeing was two TCP connections:  the first had just the immediate reply by nc: firefox responded with a RST.  Then a second cxn opened and firefox made the HTTP request, but nc replied with nothing.  That's a bug in nc's -k flag, I'm guessing--it must not deal well with quick requests in succession.

I still think this is worth landing--it seems likely that there's some stupid HTTP/XHR service out there that always immediately replies with the same content (or otherwise replies w/o looking at the request first--a time server, etc).

Comment 6

[Honza Bambas (:mayhemer)]

So, it's problem with nc, not with firefox, that we get stuck.  OK, then I stopped believe it's related to 739522.

Comment 7

[Patrick McManus [:mcmanus]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/8e8299ac8830

Comment 8

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/8e8299ac8830