gevent-socketio

gevent-socketio copied to clipboard

Hi, guys!

We've got a strange issue with IE 9: nothing is working.

First request /socket.io/1/?t=timestamp works good and responses with

652756875834:15:10:websocket,xhr-multipart,htmlfile,jsonp-polling,flashsocket,xhr-polling

And second one (/socket.io/1/123456789...) fails with KeyError in gevent-socketio/socketio/__init__.py:67:in socketio_manage. It's unable to get "socketio" key from WSGI environ.

It's reproduced with

• server: FreeBSD 9.0, gevent-socketio from git master (updated a few minutes ago), latest stable gevent and Python 2.7.
• client: Internet Explorer 9.0 on 64-bit windows, Trident 5.0, which seems to try to use WebSocketMain.swf.

Any ideas?

What is your server setup?

It's gunicorn (0.14.5).

Looks like It's related to #79 (socketio does not exist in request.environ dictionary).

By the way, If you will restart your server instance with the connected websocket client, you'll come with the same exception (KeyError: 'socket.io').

@eoranged Is this still happening for you with master?

@sontek yes, still does.

@eoranged You'll have to show some more code of your setup because IE9 works fine when I test our examples

@eoranged Can you let me know how to reproduce this?

Yes. I'm kind of busy right now, but I'll prepare minimalist example in a couple of days.

24.11.2012, 19:37, "John Anderson" [email protected]:

@eoranged Can you let me know how to reproduce this?

— Reply to this email directly or view it on GitHub.

Best regards, Vladimir Protasov.

My input might be unrelated (if so please tell me so I can create a new issue):

Something similar happens when you run the gunicorn server with multiple workers. Sockets is stored in the thread memory and the following requests only has a chance of hitting the "correct" worker when using xhr-polling. This is an extremly annoying, well, bug that present itself as soon as you decide to scale up your upplication over different workers (and even different servers if you're not using stickiness to direct traffic).

Some kind of shared memory for both the sessid and socket itself would be the optimal solution. I've not been able to fix this in the application tier as the following requests is handled earlier in the webserver-tier.

Question related to my problems on stackoverflow: http://stackoverflow.com/questions/13011477/multiple-workers-with-gevent-socketio-fails-with-xhr-polling-transport-because-o and in gevent-socketio google groups: https://groups.google.com/forum/#!topic/gevent-socketio/bVpAtS3hwS4

Seems like the original socket.io-library fixed this problem awhile ago: https://groups.google.com/forum/?fromgroups=#!topic/socket_io/OmjNdtBnzRQ

@moodh This has nothing to do with this ticket, lets move the discussion to its own

Alright, feel free to remove my post (and this one), I'll write a more detailed ticket tomorrow! :)

Sorry for delay and thanks for your patience.

I only have access to IE9 on Windows Server 2008, so some restrictions for IE may apply. But the Issue was reproduced on Windows 7 too (IE9 with default settings).

I don't see an exception with gevent-socketio master and gunicorn 0.16.1, but It still doesn't work for my application.

The way I reproduced It:

I've started the flask-chat example (which uses pretty similar logic as our application) with

cd examples/flask_chat
gunicorn --bind=0.0.0.0:8080 --worker-class="socketio.sgunicorn.GeventSocketIOWorker" chat:app

It works fine with Firefox, but with IE 9 (without Flash Player) on the same machine I was unable to join the room. That's captured traffic exported from Internet Explorer: http://eor.gd/s/gevent-socketio.ie9.xml

As I can see, It receives heartbeat messages only.

On the server I see only

2012-11-28 02:53:55 [3332] [INFO] Starting gunicorn 0.16.1
2012-11-28 02:53:55 [3332] [INFO] Listening at: http://0.0.0.0:8080 (3332)
2012-11-28 02:53:55 [3332] [INFO] Using worker: socketio.sgunicorn.GeventSocketIOWorker
2012-11-28 02:53:55 [3335] [INFO] Booting worker with pid: 3335

when using IE.

Best regards, Vladimir.

Sorry, any updates on this?

Are you experiencing the same problem ?

Alexandre On 2012-12-03 11:28 PM, "battleship-potemkin" [email protected] wrote:

Sorry, any updates on this?

— Reply to this email directly or view it on GitHubhttps://github.com/abourget/gevent-socketio/issues/103#issuecomment-10983891.

Hi Alexandre,

yep, with the same setup. Any estimations on the fix available? Anything I can do to help?

I'm sorry - no one else impacted? Or IE9 support is not a priority?

@battleship-potemkin I can't reproduce the problem, IE9 works perfectly for me with our example applications.

The example provided by eoranged doesn't work for me on Linux server neither. Probably, it's some extra debug level logs or some other environment variables required?

@sontek do you use gunicorn to reproduce the issue?

Ok, retested again:

Flask-chat example doesn't work for me in IE9 with gevent-socketio from master (fetched a few hours ago):

• when running with python run.py
• when running with gunicorn --bind=0.0.0.0:8080 --worker-class="socketio.sgunicorn.GeventSocketIOWorker" chat:app

But works fine with Firefox 17.

Server Environment:

• OS: Ubuntu 12.04 x32, fully updated (same with x64 version)
• Python 2.7.3
• gevent 0.13.8
• gunicorn 0.16.1
• Flask 0.9
• gevent-websocket 0.3.6

Client environment:

• Windows 7
• IE 9.0.8112.16421

By the way, We can provide you with any logs you need, just let us know.

I have an IE9 machine setup, I will debug this tonight to see if I can get it reproduced and let you know

On Wed, Dec 19, 2012 at 5:13 PM, Vladimir Protasov <[email protected]

wrote:

By the way, We can provide you with any logs you need, just let us know.

— Reply to this email directly or view it on GitHubhttps://github.com/abourget/gevent-socketio/issues/103#issuecomment-11546291.

If have also an issue regarding IE9 on my windows 7 machine. Only the first request to server responded with a 200 when entering the chat box (flask chat example). The following requests gave 504 responses in fiddler. Chrome and Firefox are working correctly.

The difference with Firefox an IE9 is that with FF cookie information was included in the request. IE did not sent cookie data. Deinstalled and resinstalled IE9 did not resolve the issue. Reseting to default advanced security options did not help. Also adding the local host to save websites was not helping.

Installed IE10 preview version for Windows 7 and the problems we solved and the flask chat app was working like a charm. By using F12 and using the IE 7 through 9 engines the connection problem still exists.

I do not no what the difference are between the IE9 and IE10 engine but this may contribute to a solution.

@sontek could you, please, share your setup? probably this would help to troubleshoot the issue...

Anyone, who have this working under IE9 - could you, please, share your setup / environment? This would help to match and find the issue.

Thanks.

I think I am having the same or at least similar issue with IE9 and my own app. I have also tested the simple chat example and get the same result. Running Ubuntu 12, Python 2.7, gevent 0.13.8, gevent-websocket 0.3.6.

It looks like IE9 doesn't receive a "connect" packet.

Everything runs OK in Chrome 26.0.1410.64 & FF.13.0.1 though.

I also encountered many issues while running my gevent-socketio application on IE 9 essentially because IE does NOT implement websockets and thus triggers some "broken" gevent-socketio code that is not executed when running with Firefox or Chrome! Here is what I discovered while digging into the problem: 1/ you MUST set the WEB_SOCKET_SWF_LOCATION in the .html file to prevent socket.io.js from accessing the flashsocket .swf file at /socket.io/static/flashsocket/WebSocketMain.swf. Otherwise, you get a bunch of problems! 2/ You cannot disable the flash server with IE9 if you use the latest gevent 1.0rc or 1.0

---

If you don't honor rule 1/:

1/ You must be careful to serve/deal with the static file inside the /socket.io/ url in your app! You'll get the KeyError: 'socketio' if you pass a static url starting with /socket.io/ to the socketio_manage function. And that's the case when running an app under IE9 because socket.io.js tries to find the flashsocket .swf file in /socket.io/static/flashsocket/WebSocketMain.swf by default. Same problem if you blindly copy-paste the socket.io examples where they use this markup : .

2/ Even if you do, it still fail to load /socket.io/static/flashsocket/WebSocketMain.swf because this url matches SocketIOHandler.RE_REQUEST_URL. So you actually get a KeyError: 'wsgi.websocket'! That's something that should be fixed in gevent-socketio. The request_tokens variable is initialized to {'protocol_version': 'static', 'sessid': 'WebSocketMain.swf', 'resource': 'socket.io', 'transport_id': 'flashsocket'}: too bad, transport_id gets "flashsocket" which is a valid transport id! But protocol_version and sessid are clearly invalid: we need a better check than just matching the RE_REQUEST_URL regexp or maybe matching numbers for protocol_version and sessid (not sure, haven't looked at the socket.io/websocket protocol yet). Then there is the "if issubclass(transport, (transports.WebsocketTransport, transports.FlashSocketTransport))" and the class change: I don't really understand what it does and it looks very wrong to me, but I'm not sure if it triggers another bug.

But after this error, my application seems to work in IE, but maybe because IE cached the .swf file from a previous attempt, I'm not sure...

If 2/ is fixed, I think it would be a good idea to trap the error described in 1/ in gevent-socketio and issue an informative error message instead of the KeyError to help the developers fix their app.

Another problem: if you decide to serve the socket.io.js at the root url (i.e. /socket.io.js), it pass through the first "kick" rule of SocketIOHandler.handle_one_response. I guess you should match the resource name by replacing: if not path.lstrip('/').startswith(self.server.resource): by: if not path.lstrip('/').startswith(self.server.resource + '/'): or something like this

---

If you don't honor rule 2/:

You get this error for all the other transports (htmlfile, xhr-polling, jsonp-polling): File "D:\Dev\sandboxes\arduinograph\lib\site-packages\gevent_socketio-0.3.5_rc2-py2.7.egg\socketio\transports.py", line 22, in write if 'Content-Length' not in self.handler.response_headers_list: AttributeError: 'SocketIOHandler' object has no attribute 'response_headers_list'

Probably solved here but needs to be merged into the code base: https://github.com/abourget/gevent-socketio/pull/59

Hope this report will help solving the problems

I fixed the problem 1/ described above : https://github.com/abourget/gevent-socketio/pull/170