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

[Robert Brewer]

CherryPy's wsgiserver chunks the write if the application returns no Content-Length header at all (and certain other conditions don't intrude). See https://bitbucket.org/cherrypy/cherrypy/src/tip/cherrypy/wsgiserver/wsgiserver2.py?#wsgiserver2.py-928


Robert Brewer
fumanchu at aminus.org

________________________________________
From: Web-SIG [web-sig-bounces+fumanchu=aminus.org at python.org] on behalf of André Malo [nd at perlig.de]
Sent: Wednesday, January 20, 2016 3:25 AM
To: web-sig at python.org
Subject: Re: [Web-SIG] Collating follow-up on the future of WSGI

* Cory Benfield wrote:

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

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 file.read(size)). Something like this would be my
suggestion for a future WSGI spec.

Cheers,
nd

[1] https://tools.ietf.org/html/rfc7230#section-3.3.1
--
If God intended people to be naked, they would be born that way.
  -- Oscar Wilde
_______________________________________________
Web-SIG mailing list
Web-SIG at python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: https://mail.python.org/mailman/options/web-sig/fumanchu%40aminus.org