Created attachment 47939 [details] Zip containing all needed files for reproduce this bug If you start 4 xmlhttprequests with javascript in Safari, finished requests will not free up a connection slot for the next xmlrequest. In the example .zip you will find a "index.html" containing a javascript that loads X times a xmlhttprequest targeting the file "ajax_response.php". There will be also a flash movie "loader.swf" started that starts to stream a large .mp3 file. The .mp3 file has to be named "large_testfile.mp3" and placed to the bug dir. 20mb size for the mp3 worked great for me. You can change the timeout until the xmlhttprequests start, to ensure that the flash streaming starts before. Also the number of xmlhttprequests can be 1-12. You have to calibrate these settings. If you call index.html, the following will happen in Safari: - the flash movie starts to stream the large mp3 and takes one (or more??) download slots - after 3 seconds the xmlrequests start. In my tests sometimes none, sometimes 2 xmlrequests start and finish. - The finished request do not cause a newly free download slot. So the rest of the xmlhttprequests have to wait until the flash movie has finished streaming. Expected behaviour: - flash movie starts stream - some xmlhttprequest start and finish - now again some xmlhttprequests start and finish until all are loaded, because finished requests should free up a download slot on readystate==4... If you try it in another browser, none of these will wait until flash streaming has finished. Here is a 20mb mp3 file: http://www.archive.org/download/FredrikAndersson-NetlabelSession001/FredrikAndersson-NetlabelSession001_64kb.mp3 All sources are included.
*** Bug 32945 has been marked as a duplicate of this bug. ***
I suspect this is a bug beneath WebKit. Precisely what version of Safari and OS X are you using?
It's Safari/Webkit Version 4.0.4 (5531.21.10, r54108) and Leopard OSX 10.5.7
Updated to recent Webkit. Still appears.
Btw. there is a workaround: Moving all media streaming files to a another subdomain/c-name will result in a normal loading behaviour.
You're absolutely right about that work around. This is a problem in a system component underneath WebKit, so unfortunately we can't do anything about it here. (<rdar://problem/7069233> for more info)
Hm, but why then Firefox OSX behaves normally?
WebKit uses CFNetwork for networking. Firefox does not.