iOS6: Mobile Safari does not support long polling

[Dano]

Hello,

As mentioned on hacker news (http://www.realsoftwareblog.com/2012/09/ios-6-mobile-safari-web-applications.html), it looks like mobile safari is restricting the number of simultaneous open http connections to 1 (down from the standard 2 all other browsers support).

The only guidance I have seen so far is from this post (http://stackoverflow.com/questions/12506897/is-ios6-safari-caching-ajax-results) which recommends adding a variable to the post which keeps the browser from caching the result from the first long polling call and reissue the next one.  I am not exactly sure what this translates to for Lift apps with comet actors.

Have any Lifters seen this problem and/or figured out an easy way to deal with it?

Thanks in advance.


Dan

[Tyler Weir]

It looks like Safari on iOS6[3] supports Websockets[1].

Also, check out this comment regarding caching content[2].

[1] - http://en.wikipedia.org/wiki/WebSocket

[2] - http://stackoverflow.com/a/12516555/456551

[Dano]

Tyler,

Thanks for your response.

I am a little surprised there is no alarm with respect to comet actors being out of commission on iOS6, but maybe I am just not understanding the situation.

Probably should have added some detail in the original post.  Our site (playknowsy.com) uses comet actors to support interactive game play (just like our other site innovationgames.com which is referenced on liftweb.net as an example site).  We tuned our site for the iPad form factor and touch interface.  It also works great on desktop browsers too.  

Our site playknowsy.com is currently DOA on iOS6 with respect to game play (which is the main feature of the site).  Any other site on the planet which uses long polling is also DOA on iOS6.  It may be that Apple sees the error of their ways and fixes the problem (which I expect they will but it is really hard to wait and do nothing in the meantime).

That said, I was hoping not to have to rewrite our site to use websockets as an emergency fix (much as I like the solution it provides).  As to the caching content, are you implying I should I tweek the Lift sources to change the comet actor POST to set the Cache-Control in the header to "no-cache"?

I am just trying to figure out a "plan B" should Apple fail to come thru.

Thanks again for hearing me out.


Dan

[David Pollak]

CometActors work fine on iOS 6. I just used http://demo.liftweb.net on my iPad and iPhone (both iOS 6). The comet actors stuff works perfectly.

If you're having a problem with connection starvation, please see LiftRules.maxConcurrentRequests. It will allow you to compute the maximum requests for a single session.

You can also use the comet from random hostname feature to make sure each request comes to a different hostname which means you'll never have more than 1 Comet long poll to a given host.

--
--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code
 
 
 

--

Telegram, Simply Beautiful CMS https://telegr.am

Lift, the simply functional web framework http://liftweb.net

Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im

[Dano]

Thanks David.  I am relieved that Lift comet actor support works with iOS6 - that explains the lack of alarm.  I had jumped to a conclusion.   Next time I will check the demo site first.

I will do some more digging based on your reply to see if I can pry our app loose on iOS6.


Dan

[Maarten Koopmans]

.... if you suspect others could benefit from what you find, please report here (and maybe in the wiki).

--Maarten

[parkotron]

From what I've read (I'm not currently in a dev cycle that means I'm spending time on mobile) people suggest that the problem should surface if you try an ajax call while there is polling on the page.

[Antonio Salazar Cardozo]

We don't have that problem. I suspect this has to do with the fact that we serve all of our assets from a different hostname than the one the comet and ajax requests take place on, so those can still load while the initial comet and ajax requests take place. If the browser terminates the comet request, the Lift comets should recover anyway (they'll retry after 200ms or so I believe). It probably gets a little antsy, but for us at least it doesn't *break* anything.

Net net, try creating a separate domain name, pointing it to the same IP, and serving your assets (scripts, stylesheets, images) from there if possible. That should alleviate the problem. Otherwise, maxConcurrentRequests is the way to go as David said, at least until Apple fixes this.

Thanks,

Antonio

[David Pollak]

If there were a 1 connection per host limitation, it would surface on demo.liftweb.net because there's a Comet long poll and an Ajax request.

[Dano]

Our situation is a little different that the demo on demo.liftweb.net in that we load a bunch of images from our database on the server and this is somehow interacting with the comet long poll.  There is some timing issue since when I run with the server on my laptop it works fine.  When I run from our servers in the cloud, the images stop loading once the comet long polling has kicked in.  Once the comet long poll times out, then more of the images load.  Pulling down the images from our cloud server obviously takes longer. 

I am trying David's suggestion for connection starvation which my understanding is to set LiftRules.cometServer to some subdomain (i.e. if I am running on localhost: LiftRules.cometServer = () => "http://comet.localhost").  I also make sure the subdomain comet.localhost maps to the same IP address as localhost.

When I try this, the comet request comes back immediately and repeatedly.  I am obviously missing a vital piece which will help the server to wait until the comet actor has an update for the client. 

Thanks in advance for any help.


Dan

[Dano]

Kevin,

Thanks for your post.  I think what I should do is take the Lift comet chat demo and change it to have a set of images (like our site) and see if I can reproduce the problem I am seeing.

An update for those that are interested.   I tried to redirect the comet requests to a subdomain using LiftRules.cometServer function.  When I tried this on our linux server (with nginx redirecting the subdomain to same jetty server), the response failed to make it to the waiting long poll GET request.  I did not debug this enough to know why as I am trying go fix our site any way I can.

The next thing we are trying is to tweek the javascript for cometAjax.js to defer initiating the long poll GET until all images are loaded.  Unfortunately, we are seeing image loading beyond the document.ready() callback timeframe on iOS6.  We have gotten this to work and are likely to put this into production while we look for a less tricky way to deal with the issue.

I am grateful for the response to my post and also to the many possiblities Lift provides to get developers out of a jam.


Dan

On Wednesday, September 26, 2012 4:50:45 PM UTC-7, Kevin Lau wrote:

So many things could go wrong with networking. It is very difficult to debug remotely. Perhaps, you can send a sample code that reproduces the error.