Last Comment Bug 749839 - Speculative HTTP connect gets wedged if server replies before request sent
: Speculative HTTP connect gets wedged if server replies before request sent
Status: RESOLVED FIXED
[http-conn]
:
Product: Core
Classification: Components
Component: Networking: HTTP (show other bugs)
: 15 Branch
: x86_64 Linux
: -- normal (vote)
: mozilla15
Assigned To: Patrick McManus [:mcmanus]
:
Mentors:
Depends on: 729133
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-27 16:30 PDT by Jason Duell [:jduell] (needinfo? me)
Modified: 2012-06-21 06:41 PDT (History)
3 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch.0 (1.23 KB, patch)
2012-04-28 12:53 PDT, Patrick McManus [:mcmanus]
jduell.mcbugs: review+
Details | Diff | Review

Description Jason Duell [:jduell] (needinfo? me) 2012-04-27 16:30:32 PDT
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) 2012-04-28 02:57:56 PDT
Could this be related to bug 739522 ?
Comment 2 Patrick McManus [:mcmanus] 2012-04-28 12:46:53 PDT
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] 2012-04-28 12:53:35 PDT
Created attachment 619332 [details] [diff] [review]
patch.0
Comment 4 Honza Bambas (:mayhemer) 2012-05-01 10:05:26 PDT
(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 [:jduell] (needinfo? me) 2012-05-01 10:13:34 PDT
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) 2012-05-01 10:18:30 PDT
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] 2012-05-03 06:11:20 PDT
https://hg.mozilla.org/integration/mozilla-inbound/rev/8e8299ac8830
Comment 8 Ed Morley [:emorley] 2012-05-04 04:02:12 PDT
https://hg.mozilla.org/mozilla-central/rev/8e8299ac8830

Note You need to log in before you can comment on or make changes to this bug.