Re: Collating follow-up on the future of WSGI

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


Robert Brewer
[email protected]

________________________________________
From: Web-SIG [web-sig-bounces+fumanchu=3Daminus.org-+ZN9ApsXKcEdnm+yROfE0A@public.gmane.org] on behalf =
of Andr=E9 Malo [nd-qeD/[email protected]]
Sent: Wednesday, January 20, 2016 3:25 AM
To: [email protected]
Subject: Re: [Web-SIG] Collating follow-up on the future of WSGI

* Cory Benfield wrote:

> > On 20 Jan 2016, at 06:04, Graham Dumpleton <[email protected]>
> > wrote:
> >
> > For response content, if a WSGI application currently doesn=92t 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 =93at liberty to=94 and
> =93required to=94. Certain behaviours that make sense with chunked transf=
er
> encoding do not make sense without it: for example, streaming API endpoin=
ts
> 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 cou=
ld
> 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=92s =93caveat developer=94.

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
[email protected]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: https://mail.python.org/mailman/options/web-sig/fumanchu%40ami=
nus.org
_______________________________________________
Web-SIG mailing list
[email protected]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: https://mail.python.org/mailman/options/web-sig/gcpw-web-sig%4=
0m.gmane.org