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

[André Malo]

* 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