> 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. Cory
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ 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
