User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11 When programmatically making two synchronous xml-http requests in a row via http GET, where the url for the requests is identical, the requests are made synchronously. Reproducible: Always Steps to Reproduce: Would need a test case; sorry I do not have one available at this time. 1. Make async xml-http request 1 with a url. 2. Make async xml-http request 2 with the same url. 3. Wait for results to come in. Actual Results: The JavaScript (i.e., in the debugger) shows the requests going out right away. But server-side logging and actual results indicate that the browser is not actually making the second request until the first one has finished executing. Expected Results: Both requests should load in about the same time. If working with Java Servlets, one can use a 'sleep' method in 'execute' to create a noticeable lag time in the response (say, five seconds). Workaround is to add a unique query string to each request. Also, it seems rare that this would be a problem in actual Web usage. However, it could cause performance problems -- say for a client that pings its server for a timely and regular update.

Note: The tip about using 'sleep' would be for setting up a test to reproduce the bug.

Yet another note: This only occurs when the page has not been loaded via a forced-refresh (a forced refresh is where, for example, the 'shift' key is depressed while the reload button is clicked). Having the 'browser.cache.check_doc_frequency' variable set to either '3' or '1' (no quotes) seems to make no difference. So, by doing a manually-forced refresh, the problem is not seen.

They aren't synchronous from the point of view of the script (which is what the synchronous part is about). They _are_ serialized, which you will always get on a single non-pipelined HTTP connection, and more importantly they are serialized because of the exclusive write access to the same cache entry that they both need. The query string thing makes me suspect the latter is the case here. You can get the same effect by just loading the relevant URL in two windows, without any XMLHttpRequest involved.

Correction: When programmatically making two synchronous xml-http requests should read: When programmatically making two asynchronous xml-http requests That is in keeping with what I wrote in the step-by-step (1 and 2) in the first entry to this bug report. If the requests are asynchronous, why is it correct to wait to send the second request until a response is received for the first one, just because their urls are the same? Sorry if I am missing something obvious here; it is fine with me to mark it wontfix.

I already covered that in comment 3. This is a fundamental limitation of the HTTP cache architecture in Necko, and not specific to XMLHttpRequest.

Okay, thank you. As a 'sleep' test on the server-side of one of the requests shows that the requests are not only serialized but synchronous, it seems that this is not ideal behavior. I don't see any issue filed on Necko for this ( https://bugzilla.mozilla.org/buglist.cgi?quicksearch=necko ). How about an enhancement request on this for Necko?

You and I seem to have very different definitions of "synchronous".... The requests are completely async from the HTML page's point of view, no? Necko is the networking library. This bug _is_ filed on Necko.

Glad to hear it's filed -- looking more closely reveals this pedagogic title: https://bugzilla.mozilla.org/show_bug.cgi?id=326337 Failing memory, I refer to my original report (Description section, above). It does not indicate that the JavaScript on the page was blocked waiting for the requests to complete. On the contrary, the js debugger shows the requests going out right away. So from the HTML page's point of view, the requests would not be synchronous as would be an xml-http requests made in explicitly synchronous mode. But I do recall that the 'sleep' test I did showed that they are synchronous within Necko, at least as far as one waiting for the other before going out. I've referenced this bug on the other one as a resource, at least because it describes the bug eight months earlier.

Meant this pedagogic title instead, above in Comment #8: https://bugzilla.mozilla.org/show_bug.cgi?id=446876