[Web-SIG] Collating follow-up on the future of WSGI

[Graham Dumpleton]

> On 20 Jan 2016, at 2:55 AM, Cory Benfield <cory at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20160120/08c47f27/attachment.html>