It seems that Webkit only allows 4 connections at once. Can you add a javascript command to set the maximum allowed connections? Is there any way to change it? Why you added this limitation? Here is a webpage that shows this problem. Please disable cache, open activity window and visit this webpage: http://virtualcreations.de/web_design (flash player 10 required) Music streaming will start. Now quickly press on for example "company", while the mp3 is still loading (watch the activity window). The content will be only loaded _AFTER_ the mp3-download was finished. The content loads 4 ajax areas by using xmlhttprequests. The next page only starts if all ajax areas are loaded. Bt the loading will never finish until the whole mp3 was loaded. The webpage loads normal on IE, Firefox etc. I worked around this a bit by starting the xmlhttprequests with 150*nr ms timeouts. But it doesnt work every time. Can you give me a hint to work around it in a decent way? Moving the mp3s to another CNAME-domain would be a way, but the problem is that flash player's Security is buggy and does not allow to crossdomain mp3s... Thanks for infos, Jurek
Other browsers also have a limit for concurrently open HTTP connections - it is necessary for security reasons, making it more difficult to run distributed denial of service attacks. In some browsers it's higher than 4 (usually 6 or 8). As of Mac OS X 10.6, the limit of concurrent connections in Safari is 6. The limit is built into OS networking code which is not part of WebKit, so we can't raise it in earlier OS releases. Since it's a security issue, there shouldn't be any workaround (if there is one, I'd like to know about it to close the loophole).
I find this quite interesting. In my opinion Websites will have more and more simultaneous Ajax connections. My cms loads all content areas with Ajax Calls. I can Change it to maximal 4 parallel calls and the following to Serial. The only Problem is that if you have Interactive Elements Like Flash in the page also, it can result in à total loading Block As it was in my Case. I Managed to fix this by moving Streaming contents to another cname/subdomain. I think what happened on my page is this: - mp3 was streaming and taking 1 Download slot - 4 xmlhttprequests were started and Never finished before the mp3 Download completed. 3 calls started, the fourth was blocked by Safari. Now this seems to me somehow buggy. The 3 xml requests finished loading,so in fact there were now 3 free download slots again. Why Safari didn't start then with the fourth xml request? It seems to me that Safari doesn't recognise freed xml slots within a loading xml Slot. One First "workaround" was to Start all xml requests with a timeout by using setTimeout(Connection.send(),Connection_Num x 150) this fixed the Problem only sometimes, but it changed the loading behaviour of Safari. maybe because Safari only Checks free slots for xml requests at the beginning of the Request? I didn't find any useful Information about These Limits. So i think it Needs to Be better documented. Best regards
> Now this seems to me somehow buggy. The 3 xml requests finished loading,so in > fact there were now 3 free download slots again. Why Safari didn't start then > with the fourth xml request? This actually sounds like a bug. Were you using the latest released Safari version (4.0.4)? Does this also happen with recent WebKit nightly builds? We have fixed some similar bugs recently (CC'ing Brady, who did the work), but it's possible that requests initiated by plug-ins are still an issue. Please feel free to file a new bug - ideally, with a reduced test case, and maybe a detailed description of how the data load from plug-in is initiated (e.g. bits of relevant ActionScript code).
Well, could you just reopen this bug then, and I will contribute a .zip archive that simulates this test situation with a swf, html and css-file...? The problem appeared in Safari 4 recent release and Webkit nightly. No difference here.
> could you just reopen this bug then You can do it if you want to (using the same account you originally opened the bug with), but it would be better to have a new bug for this issue. That way, others wouldn't have to read our initial discussion that isn't directly related to the problem at hand, so time and some confusion would be saved.
This bug is reopened now here: https://bugs.webkit.org/show_bug.cgi?id=34485 *** This bug has been marked as a duplicate of bug 34485 ***