CherryPy's wsgiserver chunks the write if the application returns no 
Content-Length header at all (and certain other conditions don't intrude). See

Robert Brewer

From: Web-SIG [] on behalf of 
André Malo []
Sent: Wednesday, January 20, 2016 3:25 AM
Subject: Re: [Web-SIG] Collating follow-up on the future of WSGI

* Cory Benfield wrote:

> > On 20 Jan 2016, at 06:04, Graham Dumpleton <>
> > 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.

Those APIs are just broken then. The HTTP RFCs state very clearly [1], that
any hop may modify the transfer encoding. In other words: the transfer
encoding is transparent to the representation layer.

> 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”.

WSGI is a gateway working with the representation layer. I think, it should
not concern itself with underlying transport issues that much.

Regarding chunked requests - in my own WSGI implementation I went the most
pragmatic way and simply provided a CONTENT_LENGTH of -1 for unknown request
sizes (it maps very well to Something like this would be my
suggestion for a future WSGI spec.


If God intended people to be naked, they would be born that way.
  -- Oscar Wilde
Web-SIG mailing list
Web SIG:
Web-SIG mailing list
Web SIG:

Reply via email to