> On 20 Jan 2016, at 06:04, Graham Dumpleton <graham.dumple...@gmail.com> wrote:
> 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.

My specific concern is the distinction between “at liberty to” and “required 
to”. Certain behaviours that make sense with chunked transfer encoding do not 
make sense without it: for example, streaming API endpoints that return events 
as they arrive. Sending this kind of response with a HTTP/1.0-style 
content-length absent response (framed by connection termination) is utterly 
confusing, especially as some APIs consider the chunk framing to be semantic.

This can and does bite people, because while all major production WSGI servers 
use chunked transfer encoding in this situation, not all WSGI implementations 
do: in fact, wsgiref does not. This means that if an application has a 
production design requirement to use chunked transfer encoding in its responses 
it cannot rely on the server actually providing it.

I see two solutions to this problem: we could mandate that HTTP/1.1 responses 
that have no content length must be chunked, rather than falling back to 
HTTP/1.0 style connection-termination-framed responses, or we could have 
servers stuff something in the environ dictionary that can be checked by 
applications. Or, I suppose, we can conclude that this problem is not large 
enough, and that it’s “caveat developer”.

That, however, was my concern regard chunked responses.


Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Web-SIG mailing list
Web SIG: http://www.python.org/sigs/web-sig

Reply via email to