> On 20 Jan 2016, at 8:56 AM, Robert Collins <robe...@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
_______________________________________________
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
