On 20 April 2010 16:51, Graham Dumpleton <[email protected]> wrote: > 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.
Another reason this cant work on standard WSGI is that the request content will not have a content length. WSGI cant even handle chunked request content by definition, although in mod_wsgi there is an optional feature for getting around that WSGI limitation. Graham > 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.
