* That wsgi.input is used properly:
- .read() is called with zero or one argument
def read(self, *args):
assert_(len(args) <= 1)
v = self.input.read(*args)
assert_(type(v) is type(""))
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
Web-SIG mailing list
Web SIG: http://www.python.org/sigs/web-sig
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  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."""
the link "http://cgi-spec.golux.com/draft-coar-cgi-v11-03.txt" is broken.
Regards Manlio Perillo
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
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.