iOS6 breaks long polling(realsoftwareblog.com)
realsoftwareblog.com
iOS6 breaks long polling
http://www.realsoftwareblog.com/2012/09/ios-6-mobile-safari-web-applications.html
13 comments
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?".
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).
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).
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?
>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.
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.
I am a web developer, and I've never used photoshop. I rarely touch graphics at all. My sense is that this is true for most or at least many web developers in general.
Not every web developer is a designer.
Also, cygwin.
Also, cygwin.
MSYS is much more workable than Cygwin, but it's still not a panacea. More of a placebo really.
But most web designers would be slicing PSDs at some point, right ?
And Cygwin is a joke. Dealing with the page separator differences alone would make it unbearable.
And Cygwin is a joke. Dealing with the page separator differences alone would make it unbearable.
Me as well, but this too strikes me as a part of the Valley bubble.
It's not - Macs are vastly over-represented in Edinburgh, and in London too.
There's more Macs at the Edinburgh Ruby user group meeting than at the Mac user group meeting!
There's more Macs at the Edinburgh Ruby user group meeting than at the Mac user group meeting!
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.)
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.)
There are non-Mac utilities to read .dmg files. The NDA and the $99 fee are bigger obstacles to wider uninvited beta adoption, I'd assume, but intentional. This may or may not be a good thing: more testers isn't always better for bug report quality, and for a hardware company like Apple, it'd be bad business to encourage widespread adoption of beta firmware, without either support for devices running beta software (unlikely), nor support for uninstalling beta software. It's probably not even legal in all jurisdictions.
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.
That's the first thing that came to my mind. WTH?
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.
Not every web developper is a iOS developper.
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.
[deleted](1)
How many web apps do long polling? I doubt it's many.
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.
I mean, even though Chrome allows 6+ concurrent connections to a single hostname, nothing's stopping users from opening 10 tabs of your application.
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.
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.
Another connection related issue is that iOS 6 cache responses of ajax POST requests. http://news.ycombinator.com/item?id=4550441
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.
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.
Ouch. That could cause some real damage!
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.
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.
> ... 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?
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?
Time to break out the gifsockets.
https://github.com/videlalvaro/gifsockets
https://github.com/videlalvaro/gifsockets
Funny, but a one connection at a time restriction would break gifsockets just like long polling.
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
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.
Workaround is easy: make sure your long-polling connection is not keep-alive connection.
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.
definitely a bug. most browsers, going back a decade, support 4-8+ concurrent connections to a given host (hostname, really).
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.Not necessarily.
While your desktop can handle 8 connections the 3G connection can't.
While your desktop can handle 8 connections the 3G connection can't.
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.
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.
Chrome on iOS uses safari's layout engine (because Apple doesn't allow dynamic code generation) but the network stack is Chrome's.
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.
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.
iOS supports Server Sent Events, which is what should be used in this type of situation:
http://mobilehtml5.org/
http://mobilehtml5.org/
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
http://www.eventsourcehq.com/
It's fully open source and can be self hosted as well:
https://github.com/eshq/eventsource-broker
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.
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.
Since everything will be moving to websocket eventually, might as well get a head start on iOS.
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)
Surprised I haven't noticed. I'm on Tesco Mobile, which is really O2's network.
Headstart over whaat? Even ie10 has it.
I mean, you still have to support IE6-9 in the meantime.
Quality control is for the wimps
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.