Am 21.05.2012 15:47, schrieb Simon Sapin: > Le 21/05/2012 14:36, Alex Grönholm a écrit : >> This has been discussed before and it's impossible to implement since >> proxying such things does not work over a number of protocols (FCGI, >> SCGI). IIRC, the front-end web server likes to send its own 1xx response >> before the application has a chance to send its own. The original >> discussion was about implement WebDAV, but WebSocket has the same issues. > > What would be possible is a server that does HTTP + WebSocket on the > network side and WSGI + (some other API for WebSocket) on the > application side, although I don’t know a server doing this. >
gevent and the gevent-websocket does this. http://bottlepy.org/docs/dev/async.html#finally-websockets The idea: A modified gevent server detects WebSocket requests and immediately answers with handshake headers. Then it puts a socket-like object in environ['wsgi.websocket'] and calls the WSGI application with a dummy start_response() callable. In this mode, the start_response() does nothing and the body iterator is ignored. As long as the application callable blocks (or the body iterator yields something), the socket stays open. Problems with this API: The application is required to block, thus blocking the handling server thread. Traditional threading servers have limited thread-pools. Non-blocking servers (twisted/tornado) would freeze completely. I thought about a similar API a while ago, but with some important changes. The server would put a callable in environ['wsgi.detach'] that, when called, returns a socket-like object and changes the behavior of the server as follows: 1) Calling start_response() after wsgi.detach() writes the headers to the socket immediately (instead of buffering them). Calling it again is an error. Not calling it is allowed, though. 2) The socket is not closed after the body iterator is exhausted. The client has to close it explicitly. In other words: The responsibility for the connection (and socket) is passed to the application. This works well with traditional threaded servers. The application can spawn a new worker thread, put the job into a queue or whatever and then return from the application callable, allowing the server thread to continue handling new connections. Same goes for non-blocking servers. And best of all: This API would be fully optional and backwards compatible to WSGI. Thoughts? _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
