> On 20 Jan 2016, at 2:55 AM, Cory Benfield <c...@lukasa.co.uk> wrote:
> Content Lengths
> We should clarify in the new specification that an application that reads
> beyond the logical length of the request as given by CONTENT_LENGTH will have
> its reads return immediately with the empty string. Servers are required to
> police that logic. This is codifying existing practice, and would also make
> CONTENT_LENGTH purely advisory.
Clarification on this point as maybe I didn’t explain well enough what I was
It isn’t that want an empty string to be returned immediately if an attempt is
made to read more than CONTENT_LENGTH, but that it is permissible that a WSGI
server CAN actually return more than what CONTENT_LENGTH states.
This would occur for example with chunked request content where CONTENT_LENGTH
would actually be 0 (not present). Or, with compressed request content which is
decompressed by the underlying web server. Thus the actual amount of data
available to read would be greater in length than the original non zero
A WSGI application wishing to support these situations would, instead of
reading up to CONTENT_LENGTH, would read in data until it is returned an empty
string, indicating end of input.
The complication comes in that PEP 333 simply said you can’t read more than
CONTENT_LENGTH. It didn’t really provide a guarantee that if you did you got an
empty string back.
In PEP 3333, a guarantee was added that when you had read all input you would
get an empty string. There was no version change for WSGI in PEP 3333, ie.,
wsgi.version, so you don’t really have a proper way of knowing for sure that a
WSGI server will work that way so WSGI applications still tend to be written to
only read up to CONTENT_LENGTH.
An updated WSGI 1.1, so wsgi.version would be updated, would provide a means of
being able to know if empty string is guaranteed, but also the additional new
change that you can read past CONTENT_LENGTH and still get data, with input
eventually terminated by empty string.
I have at least one blog post about this some where so I will try and find it.
Travelling this morning though so no more time to try and find it right now.
Web-SIG mailing list
Web SIG: http://www.python.org/sigs/web-sig