> 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 
suggesting.

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 
CONTENT_LENGTH.

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.

Graham
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: 
https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com

Reply via email to