iOS and WebSockets: 0 bytes read/no close frame received/code 1006?

[WORMSTweaker]

iOS and WebSockets: 0 bytes read/no close frame received/code 1006?

[aaugustin]

I don't know enough about iOS development to document what you explained in the FAQ (and it's a bit out of scope of what I'm willing to document.) Hopefully other users hitting the same problem with websockets will find this issue and it will put them on the right track.

[aaugustin]

Your don't need to send a Connection: upgrade header — websockets does that.

    header = {
        'Connection' : 'upgrade',
        'Access-Control-Allow-Origin' : '*'
        }

Maybe iOS dislikes the duplicate header?

[WORMSTweaker]

Ah indeed, I didn't notice that was the case, so I added it myself to try and see if it helped. So removing the duplicate header seems to have changed something, on the Python side, the server indicates a DEBUG = connection is CONNECTING, on the JS side though onerror is triggered followed by the onclose event, no message received, no message sent:

So some progress? At least python-websockets isn't exploding anymore, but now why is iOS closing the connection prematurely?

[WORMSTweaker]

Update, and really I'm baffled by how to fix this, and if somebody has an explanation of why this is how things are done on iOS, please enlighten us all.

So, turns out, iOS HATES when your websockets are not opened in an asynchronous manner, so, the simple fix for websockets not opening is to define an async function, and await for the websocket to open, which on paper sounds logical, but I haven't found a single ounce of documentation about this.

I tested this on my previous simple echo example, works perfectly, tested on my bigger project, works too, so I suppose the case is closed. I don't know if you want to add more to this since it's not a python-websockets related issue at this point.

[aaugustin]

Apple doesn't really want to you keep long-lived TCP connection. They'd rather you use APNS.