RESOLVED INVALID 34485
xmlhttprequest does not free finished loading slots 
https://bugs.webkit.org/show_bug.cgi?id=34485
Summary xmlhttprequest does not free finished loading slots
Jurek R.
Reported 2010-02-02 09:00:33 PST
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.
Attachments
Zip containing all needed files for reproduce this bug (3.37 KB, application/zip)
2010-02-02 09:00 PST, Jurek R. 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Jurek R.
Comment 1 2010-02-02 09:04:05 PST
*** Bug 32945 has been marked as a duplicate of this bug. ***
Brady Eidson
Comment 2 2010-02-02 09:14:51 PST
I suspect this is a bug beneath WebKit. Precisely what version of Safari and OS X are you using?
Jurek R.
Comment 3 2010-02-02 09:44:43 PST
It's Safari/Webkit Version 4.0.4 (5531.21.10, r54108) and Leopard OSX 10.5.7
Jurek R.
Comment 4 2010-02-02 09:48:58 PST
Updated to recent Webkit. Still appears.
Jurek R.
Comment 5 2010-02-02 09:55:04 PST
Btw. there is a workaround: Moving all media streaming files to a another subdomain/c-name will result in a normal loading behaviour.
Brady Eidson
Comment 6 2010-02-02 10:05:18 PST
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)
Jurek R.
Comment 7 2010-02-02 10:07:36 PST
Hm, but why then Firefox OSX behaves normally?
Brady Eidson
Comment 8 2010-02-02 10:30:09 PST
WebKit uses CFNetwork for networking. Firefox does not.
Note You need to log in before you can comment on or make changes to this bug.