Long polling in iOS6 Mobile Safari

I have the same problem. Is there anyone with more information on how solve this? I've found these links:

• http://www.devthought.com/2012/09/22/understanding-the-ios6-ajax-bugs/
• http://news.ycombinator.com/item?id=4552072

According to the link you posted, it isn't true.

That is true, but I beg to differ.

Here is an example to show that the problem is actually there: http://dev.negotica.net/iOSTest

Try to open that link in both iOS 5 and iOS 6 safari to see the difference. Or just open it in your desktop browser and iOS6+ browser.

Ideally, you don't want to load images while the page is running if you can help it. It is better to preload them somewhere out of the way and just shift or fade them into place when you are ready.

However, if you did want to load data like this, it seems that all you really need to to is change your AJAX call to be synchronous instead. Then it seems to work. I don't have a real iOS6 device. I was able to reproduce and fix the problem in the simulator. Give it a try.

Long polling cannot be done synchronously because it would result in all webapp exectution waiting for the AJAX request to complete. The whole essence of long polling is that you do it asynchronously. For example: synchronously polling a service that takes 20 seconds to complete would result in the browser freezing for 20 seconds.

etresoft is right that preloading all images before the polling starts would ideally be the solution. Unfortunately, the result of the service we are polling will determine which images will be loaded. So this is not really an option for us.

markdegroot wrote:

Long polling cannot be done synchronously because it would result in all webapp exectution waiting for the AJAX request to complete. The whole essence of long polling is that you do it asynchronously. For example: synchronously polling a service that takes 20 seconds to complete would result in the browser freezing for 20 seconds.

I will take that to mean that you haven't tried it yet. 🙂

etresoft wrote:

markdegroot wrote:

Long polling cannot be done synchronously because it would result in all webapp exectution waiting for the AJAX request to complete. The whole essence of long polling is that you do it asynchronously. For example: synchronously polling a service that takes 20 seconds to complete would result in the browser freezing for 20 seconds.

I will take that to mean that you haven't tried it yet. 🙂

I have now. And as I expected, synchronously polling causes the browser to hang. Also the XHR response never returns on the iPad but is cancelled after 10 seconds or so and then the second image is added. You can try it here: http://dev.negotica.net/iOSTest/index-sync.html .

Ah. I see the problem. The image request interrupts the synchronous call.

I guess you will have to avoid assuming multiple connections are possible. The only reason I have ever used long polling is to get immediate updates. I make a request that will time out in 20 seconds or so but will return sooner if something notable happens. That notable event should be your queue that other resources need to be loaded. I typically return HTML to be inserted into the DOM and that will load any image resources it needs.

That should be "cue"

There's some uncertainty to this, but it seems that the "only one request" limitation only covers requests with HTTP keepalive - a new request to the same server will typically not be initiated if there's already another keepalive request going on. It also seems that this only affect some kind of requests - XHR requests or stylessheets seem to be OK whereas image requests seem to be blocked.

The workaround is however just to ensure that a "Connection: close" header is added for the long polling response (and that the headers are actually sent immediately instead of only the first time some actual data is returned over the long polling channel).

Hi,

I had the same issue with long polling on Safari, so I used your test page http://dev.negotica.net/iOSTest to find a workaround. I finally found one using WebWorkers. It seems that if you use html5 webworkers the limitation is not applied when there are multiple threads on the same hostname.