[Web-SIG] wsgiref.validate allows wsgi.input.read() with no argument
Graham Dumpleton
argument to read() on wsgi.input is optional, wsgiref.validate allows
calling read() with no argument.
>From wsgiref.validate:
"""
* That wsgi.input is used properly:
- .read() is called with zero or one argument
class InputWrapper:
def read(self, *args):
assert_(len(args) <= 1)
v = self.input.read(*args)
assert_(type(v) is type(""))
return v
"""
Of course, the issue is still that WSGI PEP says:
"""The server is not required to read past the client's specified
Content-Length, and ***is allowed to simulate an end-of-file condition
if the application attempts to read past that point***."""
Thus, simulating end-of-file condition is not mandatory, and so if
something does call read() with no argument, not guaranteed it will
actually return. The problem case here being where HTTP/1.1 request
pipelining is being used and WSGI adapter is using raw socket as
wsgi.input. The socket isn't going to be closed in this case as
potentially another request to yet be sent over same socket. Thus
application call of read() with no arguments will hang until client
decides to close socket connection.
Anyway, I thought it was interesting that wsgiref.validate accepts
that argument read() can be optional. Supports further that this part
of WSGI PEP needs to be clarified and end-of-file condition perhaps
made mandatory.
Graham
_______________________________________________
Web-SIG mailing list
Web...@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/python-web-sig-garchive-9074%40googlegroups.com
Manlio Perillo
> Just noticed that although WSGI PEP doesn't specifically mention that
> argument to read() on wsgi.input is optional, wsgiref.validate allows
> calling read() with no argument.
>
wsgiref.validate makes also other assumptions about a WSGI application
that are not required by the WSGI PEP.
As an example it reports as an error the presence in the environ
dictionary of HTTP_CONTENT_TYPE and HTTP_CONTENT_LENGTH, but the PEP
says nothing about this, and CGI [1] says:
""""The server may exclude any headers which it has already processed,
such as Authorization, Content-type, and Content-length. If necessary,
the server may choose to exclude any or all of these headers if
including them would exceed any system environment limits."""
[1] http://hoohoo.ncsa.uiuc.edu/cgi/env.html
P.S.:
the link "http://cgi-spec.golux.com/draft-coar-cgi-v11-03.txt" is broken.
> [...]
Regards Manlio Perillo
Ian Bicking
> Just noticed that although WSGI PEP doesn't specifically mention that
> argument to read() on wsgi.input is optional, wsgiref.validate allows
> calling read() with no argument.
>
>>From wsgiref.validate:
>
> """
> * That wsgi.input is used properly:
>
> - .read() is called with zero or one argument
>
> class InputWrapper:
>
> def read(self, *args):
> assert_(len(args) <= 1)
> v = self.input.read(*args)
> assert_(type(v) is type(""))
> return v
> """
>
> Of course, the issue is still that WSGI PEP says:
>
> """The server is not required to read past the client's specified
> Content-Length, and ***is allowed to simulate an end-of-file condition
> if the application attempts to read past that point***."""
An application that relies on the server to simulate end-of-file will be
a broken application on some servers. This is not an uncommon problem.
Therefore the validator tests for this case; if you want an
application that actually works consistently, you shouldn't do
environ['wsgi.input'].read().
--
Ian Bicking : ia...@colorstudy.com : http://blog.ianbicking.org
Graham Dumpleton
> Graham Dumpleton wrote:
>>
>> Just noticed that although WSGI PEP doesn't specifically mention that
>> argument to read() on wsgi.input is optional, wsgiref.validate allows
>> calling read() with no argument.
>>
>>> From wsgiref.validate:
>>
>> """
>> * That wsgi.input is used properly:
>>
>> - .read() is called with zero or one argument
>>
>> class InputWrapper:
>>
>> def read(self, *args):
>> assert_(len(args) <= 1)
>> v = self.input.read(*args)
>> assert_(type(v) is type(""))
>> return v
>> """
>>
>> Of course, the issue is still that WSGI PEP says:
>>
>> """The server is not required to read past the client's specified
>> Content-Length, and ***is allowed to simulate an end-of-file condition
>> if the application attempts to read past that point***."""
>
> An application that relies on the server to simulate end-of-file will be a
> broken application on some servers. This is not an uncommon problem.
> Therefore the validator tests for this case; if you want an application
> that actually works consistently, you shouldn't do
> environ['wsgi.input'].read().
The validator does not test for that case, that is what I am pointing
out. The validator allows read() to be called with no argument.
Graham
Ian Bicking
>> An application that relies on the server to simulate end-of-file will be a
>> broken application on some servers. This is not an uncommon problem.
>> Therefore the validator tests for this case; if you want an application
>> that actually works consistently, you shouldn't do
>> environ['wsgi.input'].read().
>
> The validator does not test for that case, that is what I am pointing
> out. The validator allows read() to be called with no argument.
Ah, sorry, I wasn't paying attention... okay, then yes, I agree -- the
validator should be more restrictive.
--
Ian Bicking : ia...@colorstudy.com : http://blog.ianbicking.org