Speculative HTTP connect gets wedged if server replies before request sent

RESOLVED FIXED in mozilla15

Status

()

Core
Networking: HTTP
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: jduell, Assigned: mcmanus)

Tracking

15 Branch
mozilla15
x86_64
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [http-conn])

Attachments

(1 attachment)

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.
Could this be related to bug 739522 ?
(Assignee)

Comment 2

5 years ago
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 :)
(Assignee)

Comment 3

5 years ago
Created attachment 619332 [details] [diff] [review]
patch.0
Assignee: nobody → mcmanus
Status: NEW → ASSIGNED
Attachment #619332 - Flags: review?(jduell.mcbugs)
(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...
(Reporter)

Comment 5

5 years ago
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).
Attachment #619332 - Flags: review?(jduell.mcbugs) → review+
So, it's problem with nc, not with firefox, that we get stuck.  OK, then I stopped believe it's related to 739522.
(Assignee)

Comment 7

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/8e8299ac8830
Target Milestone: --- → mozilla15
Version: unspecified → 15 Branch
https://hg.mozilla.org/mozilla-central/rev/8e8299ac8830
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Whiteboard: [http-conn]
You need to log in before you can comment on or make changes to this bug.