iOS6 breaks long polling

http://www.realsoftwareblog.com/2012/09/ios-6-mobile-safari-web-applications.html

by mmastrac • 14 years ago

152 58 14 years ago

mh-• 14 years ago

definitely a bug. most browsers, going back a decade, support 4-8+ concurrent connections to a given host (hostname, really).

jlgreco2• 14 years ago

Hell, even elinks does:

    Name: max_connections_to_host
    Type: Integer [1..8]
    Value: 8

    Description:
    Maximum number of concurrent connections to a given host.

taligent3• 14 years ago

Not necessarily.

While your desktop can handle 8 connections the 3G connection can't.

gmaslov• 14 years ago

A TCP connection costs nothing if it's merely open and waiting. OK, it costs a few bytes of space in some tables somewhere, but no actual bandwidth.

jlgreco2• 14 years ago

Odd how 3G could handle it, until a day or two ago.

saurik4• 14 years ago

Someone at Apple is going "we have had iOS 6 in beta for months now; is this really the first time anyone noticed this issue?".

dvhh• 14 years ago

Not every web developper is a iOS developper.

saurik4• 14 years ago

However, I would be highly surprised if none of them were ;P, and this is the kind of issue that seems like it should have affected almost everyone building anything; hell: I would have noticed and filed this bug had I still been working on the web project I was working on last year around this time. It is thereby highly surprising that no one noticed this.

bmeckel• 14 years ago

Seriously this is a huge oversight. The only thing that comes to mind is that the web-app developers (understandably) didn't see the need to test on iOS 6 but I can't imagine there was absolutely no overlap.

ricardobeat• 14 years ago

That's the first thing that came to my mind. WTH?

pkulak• 14 years ago

How many web apps do long polling? I doubt it's many.

Joeri• 14 years ago

Most web developers use a windows or linux machine to develop and a physical device to test (myself included). That combination prevents you from running the iOS 6 beta, because you need a mac for that. So, only a minority of web developers (those with access to a mac) actually could have tested the iOS 6 beta.

Additionally, the first iOS 6 betas had the browser in such a bad shape that it was obvious they were still working on it. I took one look at it and figured "i'll test it when they're done". They need to have some sort of clear indication of when it's actually ready for testing (and not just for testing of the native SDK's).

taligent3• 14 years ago

>Most web developers use a windows or linux machine to develop and a physical device to test.

Maybe I am living in a bubble but every single web developer I have ever met used a Mac. Why ? Because it is the only platform that has Photoshop + a UNIX shell.

saurik4• 14 years ago

I definitely agree with the latter point: if you try something and it is "in ruins" you are unlikely to respond with any feedback at all. That is one of the things that Apple needs to do a better job at during their betas: I have personally often just written them off until beta 4 or 5 as "it is so unlikely to work anyway" (although I do try to pick it up once they stop doing rapid cycles).

However, for your ability to test in the future: the only thing I believe the iOS beta requires related to owning a Mac is that the downloads from Apple's website for the IPSW files are stored inside of disk image files; you only need access to a Mac long enough to restore your device, but I am not certain why you would need a Mac to work with it later. (I would love to be told I was wrong there, however, so I could add that to the list of endemic issues leading to this.)

jasomill2• 14 years ago

Why do you need a Mac to run iOS betas? Does iTunes for Windows no longer support loading firmware updates from a file? You can register device UDIDs on the developer program Web site, and extract the first firmware file from .dmg with any one of several utilities on Linux and Windows, so I'm not sure why you'd need a Mac, unless Windows can no longer flash iOS devices.

mhartl• 14 years ago

I'm curious to know in which communities this is true. At least in the Ruby on Rails world, Macs are overwhelmingly the most popular choice among developers. Is this not the case for, say PHP or Python/Django devs?

buddydvd• 14 years ago

Another connection related issue is that iOS 6 cache responses of ajax POST requests. http://news.ycombinator.com/item?id=4550441

skeletonjelly• 14 years ago

Ouch. That could cause some real damage!

steve8918• 14 years ago

I submitted that post, so I have some vested interest in this. I came across this bug because I was converting one of my web apps to use the new iOS 6 feature of being able to upload photos from your Camera Roll to a web site.

However, when you upload a picture, apparently, they are all called image.jpg. Since the image name never changed, every time I uploaded a new pic, the first pic was being returned. I couldn't understand why, and as usual, stackoverflow had a good answer for me. I needed to add a timestamp option to my URL in order to work around this behavior.

username• 14 years ago

Time to break out the gifsockets.

https://github.com/videlalvaro/gifsockets

halter73• 14 years ago

Funny, but a one connection at a time restriction would break gifsockets just like long polling.

old_sound2• 14 years ago

Dude, the gifsockets example "uses one connection at a time" because I'm too lazy to implement a server using Netty or Aleph in Clojure. The only important part from the gifsockets concept is writing gif frames on demand. The rest is up to you

Mythbusters• 14 years ago

Quality control is for the wimps

dudus• 14 years ago

He claims that it doesn't happen on Chrome for iOS.

But isn't chrome for iOS just a "skin" with new features on top of the same safari browser?

One issue like I would expect to affect Chrome as well.

tdrd• 14 years ago

Chrome on iOS uses safari's layout engine (because Apple doesn't allow dynamic code generation) but the network stack is Chrome's.

mintplant• 14 years ago

Well, it's known that UIWebView and Safari have their own differences between them; for example, the slower JavaScript engine in the former. I would guess that this would be one of them.

codeka2• 14 years ago

This is very strange...

If the browser only opens one connection to a domain at once, it should have made so many sites much slower to load and it's hard to believe Apple don't have automated tests to check for performance regressions like that.

bathat• 14 years ago

> ... it's hard to believe Apple don't have automated tests to check for performance regressions like that.

Well, I mean, this is the same company that has received "some press" recently regarding the latest version of its mapping application.

Edit: That was a low blow, wasn't it?

garindra• 14 years ago

I might be wrong here, but if you're using long polling in your webapp, shouldn't you be using a randomized wildcard subdomain anyways? For example, Quora uses #.tch.quora.com as their long polling hostname, with the #-part randomized for each of the browser tab, which effectively allows for an unlimited number of concurrent connections to a single IP address.

I mean, even though Chrome allows 6+ concurrent connections to a single hostname, nothing's stopping users from opening 10 tabs of your application.

dwj2• 14 years ago

I think you might be wrong here :)

I've no idea why Quora does that, but I'm pretty sure it's not a standard thing. You really should only being doing one long poll at a time, so it should never be an issue.

pilif• 14 years ago

I'm using long polling in our application and I don't see that one connection per server restriction here.

I did however see that safari was not leaving the loading state (and thus not firing any of the loaded events, nor hiding the URL bar) if I started the long polling connection before the page was fully loaded.

Once I moved opening the connection to a setTimeout callback inside the onLoad handler (so not DOM ready, but actual load), this went away and the page works normally.

codeka2• 14 years ago

Now this makes sense. As I said below, it seems really strange that this would go unnoticed, especially since one-connection-per-domain affects all sites and not just ones doing long polling.

Still a pretty bad bug, though.

atotic• 14 years ago

I believe the restriction is "only single keep-alive connection". This makes sense to me, no need for multiple overhead if one connection will saturate your bandwidth. It will open multiple if the server does not support keep-alive.

Workaround is easy: make sure your long-polling connection is not keep-alive connection.

dwj2• 14 years ago

That doesn't seem like a sensible solution. You're basically hurting performance on all other platforms just to work around one of Apple's bugs.

TazeTSchnitzel4• 14 years ago

Well, iOS 6 has websocket. Visit http://ajf.me/websocket and see for yourself.

Since everything will be moving to websocket eventually, might as well get a head start on iOS.

kybernetikos• 14 years ago

Headstart over whaat? Even ie10 has it.

TazeTSchnitzel4• 14 years ago

I mean, you still have to support IE6-9 in the meantime.

pornel• 14 years ago

Unfortunately, it won't solve the problem for all iOS users. For example the WebSocket protocol is blocked on most UK 3G networks (e.g. O2's censorship proxy only handles real HTTP traffic)

TazeTSchnitzel4• 14 years ago

Surprised I haven't noticed. I'm on Tesco Mobile, which is really O2's network.

the_mitsuhiko• 14 years ago

Just encrypt the traffic.

laacz• 14 years ago

I'm not sure, why should someone rely on long polling alone. Default fallback mechanism is websockets (supported on iOS), long polling (not supported anymore, obviously) and then follows separate ajax calls. It is not uncommon that something in this sequence would break by design, unsupportedness or bad data connection, so fallback should be used.

MatthewPhillips• 14 years ago

iOS supports Server Sent Events, which is what should be used in this type of situation:

http://mobilehtml5.org/

bobfunk• 14 years ago

I have a small hosted service in beta, making it dead easy to push events via Server Sent Events (with fallbacks).

http://www.eventsourcehq.com/

It's fully open source and can be self hosted as well:

https://github.com/eshq/eventsource-broker

jevinskie• 14 years ago

Thank you for linking to that very informative page. The support matrix is interesting enough but even more interesting is that I didn't know about most of those APIs.

iOS6 breaks long polling

Related Stories