> On 20 Jan 2016, at 10:57 AM, Robert Collins <robe...@robertcollins.net> wrote:
> On 20 January 2016 at 12:04, Benoit Chesneau <bchesn...@gmail.com> wrote:
>> not at all. But I made the assumption that the wsgi server maintained a
>> thread directly or not where the python application is running .
>> In any case there is some sort of wrapping done in the same thread/process
>> where the python application is running. And then nothing stop to give the
>> socket away to the application and tell to the server to stop to communicate
>> with it.
> What socket?
> Data could be being passed by shm, for instance.

Exactly. You aren’t guaranteed that from the HTTP client to the WSGI server 
consists only of use of socket connections with HTTP running over it.

Intermediary hops to could use non socket communication mechanisms, or instead 
of using HTTP on a proxy connection, use an alternate protocol such as CGI, 
SCGI, FASTCGI or some internal WSGI server specific protocol.

There are enough of these already that a requirement in the WSGI specification 
to provide a socket which had the original unmodified HTTP request coming over 
it is not possible. It has to be optional and being optional it doesn’t really 
even need to be in the WSGI specification PEP but can be a separate WSGI 
extension specification.

Web-SIG mailing list
Web SIG: http://www.python.org/sigs/web-sig

Reply via email to