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

[Graham Dumpleton]

> On 20 Jan 2016, at 8:56 AM, Robert Collins <robertc at robertcollins.net> wrote:
> 
>> 
>> Chunked Transfer Encoding
>> ~~~~~~~~~~~~~~~~~~~~~~~~~
>> 
>> It would be nice to formalise chunked transfer encoding in WSGI. Currently there is no way to signal to applications that chunked transfer encoding is in use by the client, or for the application to request it from the server.
>> 
>> This seemed to be a low priority work item, but if we can make this enhancement easily then it's worth considering.
> 
> I'm very much against this. I think its an abstraction violation. It
> makes as much sense as exposing the guts of HTTP/2 framing to an
> application. A way of doing Trailers would make sense.

I would agree in as much that what is stated here is confusing.

There are two concerns. Chunked request content, and use of chunking on response content.

For chunked request content it can’t currently be done by PEP 3333. This is what the separate issue about reading more than CONTENT_LENGTH is about. For chunked request content, a WSGI application would never see raw chunked stream as it would be de-chunked by the web server.

For response content, if a WSGI application currently doesn’t set a Content-Length on response, A HTTP/1.1 web server is at liberty to chunk the response.

So I am not sure what is missing.

BTW, this reminds me of another area of the WSGI PEP which is broken which I have talked about before in:

   http://blog.dscpl.com.au/2009/10/wsgi-issues-with-http-head-requests.html <http://blog.dscpl.com.au/2009/10/wsgi-issues-with-http-head-requests.html>

There might be another post about it.

Basically the PEP is wrong is saying a WSGI server is allowed to construct a Content-Length header where it identifies the response as a list containing one string. Doing so can break the supposed equivalence in headers between GET and HEAD.

So another issue that would be cleaned up in any 1.1 final version of the specification.

Graham
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20160120/1fe17832/attachment-0001.html>