bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

Extra null HTTP transaction(s) are being sent from Firefox for GET/POST




Networking: HTTP
4 years ago
4 years ago


(Reporter: Tim, Unassigned)


33 Branch
Windows 7

Firefox Tracking Flags

(Not tracked)



(1 attachment)

676.33 KB, application/pdf


4 years ago
Created attachment 8487420 [details]
iSafari Log.pdf

User Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; IPH; .NET4.0C; .NET4.0E)

Steps to reproduce:

Every GET or POST transaction the Firefox browser issues results in at least one, usually more null HTTP transactions that are tying up our webservers resources trying to connect to this null transaction. I have 6 children that have a timeout of 4 secs, they spend that time trying to read, but are getting no data. I tried using Fiddler on the browser and the transactions stopped sending. When I end Fiddler, then issue a POST from the browser (click submit) the null transaction(s) appear again.

Expected results:

No null transactions.
Component: HTML: Form Submission → Networking: HTTP
Flags: needinfo?(mcmanus)
Sometimes we generate speculative connections that don't end up being used, or at least not right away.. Sometimes they aren't so much speculative as "un-necessary" because the transaction that was scheduled for them was rescheduled onto a different idle connection before the connection was established.. the timeout on them is usually 5-10 seconds. We've done this for several years now.

Such is the nature of the modern web. The server side needs to deal with incoming requests on a non blocking event basis if it expects to scale.
Last Resolved: 4 years ago
Flags: needinfo?(mcmanus)
Resolution: --- → WONTFIX

Comment 2

4 years ago
If you read the comment, I am using non-blocking, otherwise the server would set there forever, dah. I will admit the beta version 33 is better than ver 32 because the null transactions were taking an additional 6 seconds over whatever timeout value I specified. You'all have answered my question, it is the server's responsibility to handle what the browser sends, just deal with it, and I will.
You need to log in before you can comment on or make changes to this bug.