On 20 April 2010 16:30, Graham Dumpleton <[email protected]> wrote: > On 20 April 2010 15:22, TheIvIaxx <[email protected]> wrote: >> Thanks graham. I didn't realize how unsupported websockets are right >> now. > > I don't recollect saying anything that may give that impression. I was > just saying that trying to get that particular package to work with > WSGI may be a problem. > > If you do a search for 'WSGI websocket', there is various other stuff > out there about it. > > http://blog.eventlet.net/2010/02/12/scalable-wsgi-compatible-websockets/ > http://blog.eventlet.net/2010/02/13/changes-to-wsgi-to-support-websockets/ > http://code.google.com/p/typhoonae/wiki/WebSockets > > I don't know anything about websocket though, so not sure what there > is about it that makes people think it requires the sort of hack that > were doing to make it work on mod_python or why others think it needs > eventlets or tornado to work as opposed to a standard WSGI server. > > I guess I will have to have a bit of a look about what it is all about. :-)
Okay, the fiddles in mod_python were likely in part because WebSockets use: 101 - Switching Protocols Tells the client that the server will switch protocols to that specified in the Upgrade message header field during the current connection. I am still not convinced they needed to do it the way they did, ie., access the connection directly. They possibly thought they had to do that to avoid HTTP filter stack applying chunked encoding on response given there would be no response content-length, but there are other ways around that and still have it go via the HTTP filter stack in Apache. These other ways aren't available through mod_wsgi however, so no, you could possible not do it via WSGI on top of mod_wsgi unless there are Apache directives which would achieve same result. Graham > Graham > >> I guess this will become more documented as the spec get more >> solidified >> >> On Apr 19, 5:58 pm, Graham Dumpleton <[email protected]> >> wrote: >>> On 20 April 2010 10:13, Graham Dumpleton <[email protected]> wrote: >>> >>> >>> >>> >>> >>> > On 20 April 2010 03:16, TheIvIaxx <[email protected]> wrote: >>> >> Sorry if this was already mentioned, but is there any info on using >>> >> web sockets with mod_wsgi? Google had released a pywebsockets app for >>> >> mod_pythonhttp://code.google.com/p/pywebsocket/. If this is already >>> >> possible with mod_wsgi, can someone point me in the right direction? >>> >>> > Obviously someones 20% time project in Google. >>> >>> > Really don't understand why they would want to bind it to mod_python. >>> > The way they hook it into mod_python is even questionable as they hook >>> > into the header parser phase when I cant see any good reason why this >>> > couldn't have been done in more conventional ways. >>> >>> > Anyway, it is really hard to tell as there is zero documentation in >>> > their wiki about what it is all about and how to use it. >>> >>> > I would perhaps suggest you log an enhancement request in their issue >>> > tracker to provide a WSGI compliant solution. You don't even have to >>> > mention mod_wsgi as that is just one WSGI implementation and what they >>> > provide should work on any WSGI hosting mechanism. >>> >>> Actually, looking a bit deeper, I wouldn't even bother asking them to >>> support WSGI as they are too rooted into the bowels of Apache. In one >>> part of code it says: >>> >>> """Message related utilities. >>> >>> Note: request.connection.write/read are used in this module, even though >>> mod_python document says that they should be used only in connection >>> handlers. >>> Unfortunately, we have no other options. For example, request.write/read are >>> not suitable because they don't allow direct raw bytes writing/reading. >>> """ >>> >>> So, they don't even use the standard mechanisms in Apache for reading >>> request content and writing a response. >>> >>> Their justification for this is: >>> >>> """request.write/read are not suitable because they don't allow direct >>> raw bytes writing/reading.""" >>> >>> I don't know what they are doing, but that isn't entirely accurate. >>> >>> The only aspect of raw bytes that isn't preserved is chunked transfer >>> encoding. This is a HTTP layer thing and not an application layer. >>> >>> Thus, the only reason for them operating at connection layer is if >>> they need to process chunked transfer encoding blocks directly for >>> some reason and I cant see that happening. >>> >>> Now if using normal methods for handling data, input/output filters >>> can change data as passed through, but this is the exception and those >>> filters don't need to be configured. >>> >>> So, right now I am really dubious about how they have done what they >>> have done and still cant see a valid reason for it. >>> >>> Graham >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "modwsgi" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group >>> athttp://groups.google.com/group/modwsgi?hl=en. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "modwsgi" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/modwsgi?hl=en. >> >> > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
