WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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.
Top of Page
Format For Printing
XML
Clone This Bug