[Web-SIG] websocket support in WSGI

[Roberto De Ioris]

> On Tue, May 22, 2012 at 3:39 PM, Alex Grönholm
> <alex.gronholm at nextday.fi>wrote:
>
>>  22.05.2012 10:38, Sylvain Hellegouarch kirjoitti:
>>
>>
>>> 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.
>>>
>>>
>>  This is exactly how ws4py was implemented when using CherryPy for the
>> HTTP server performing the handshake [1]. There's also a WSGI middleware
>> [2] but it's heavily geared towards gevent and may not be reusable
>> easily
>> elsewhere I'm afraid.
>>
>> It's also a hack that violates the WSGI spec. It's also not usable
>> through
>> reverse proxying or FCGI/SCGI.
>>
>
>
> Yeap that's very true and it'll stay a hack until WSGI is updated to
> support it or explicitely reject protocols such as WebSocket. In the
> meanwhile, I'm personally fine having projects like ws4py to play with and
> decide what could work and what couldn't.
>

Can't we simply define something like environ['wsgi.raw_socket'] (or
whatever name you want) mapping to the client (or webserver in case of
proxied) socket ?

At the very beginning, uWSGI used to map wsgi.input to the webserver
socket, and implementing WebSocket (and all of the 'HTTP Upgrade' fatures
you can think of, included the ultra-non-standard icecast protocol) was
easy for non-buffering webservers (like Apache or Cherokee)

http://projects.unbit.it/uwsgi/browser/websockets.py

Obviously reading from both wsgi.input and wsgi.raw_socket should be
"discouraged" (or directly forbidden)

My point is in not referring explicitely to WebSockets, but have a way to
simply let the application having access to the communication socket (with
some strict rule, like getting only the http body part and so on, to make
things easier for middleware developers)

I tend to consider mod_wsgi as the "standard de-facto" implementation of
WSGI, and adding support for wsgi.raw_socket in it would be really easy
(Graham i offer myself for a patch ;), as well as in uWSGI.

The problem will rise for nginx (when used as a proxy), but it is
generated by its "buffering" policy, so we cannot (for now) make something
about that.

-- 
Roberto De Ioris
http://unbit.it