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.
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.
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).
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.
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.)
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.
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.
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.
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.
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.
Your attempt at sarcasm seems to rely on me saying those people were assholes, when I did not: I would hope you would agree with me that it is highly surprising that no one would have noticed this issue in months of testing; this is indicative of a failure somewhere else, such as 1) last-minute changes, 2) internal routing of communication, 3) closed developer ecosystem, etc.; no matter what the cause, someone at Apple is having that reaction, and I'd love to have been around to see what the resulting discussion and possible outcomes of that question were.
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'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 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.
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.
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
Ups… I read the wrong thing then. I thought the guy was referring to the sample gifsockets app that now supports only one connection at a time. Cheerio!
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.
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.
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.
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)
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.