gistfile1.rst

wsgi.input_terminated Proposal

A two step proposal to fix the situation with different behaviors of input streams in WSGI.

WSGI servers have two options to providing the input stream:

1. Provide wsgi.input as socket file unchanged. This means that wsgi.input_terminated is set to False or not added to the WSGI environ at all. In that case the WSGI application is required to look at the CONTENT_LENGTH and only read up to that point.
2. Provide wsgi.input as an end-of-file terminated stream. In that case wsgi.input_terminated is set to True and an app is required to read to the end of the file and disregard CONTENT_LENGTH for reading.

Pseudocode for a WSGI implementation:

def get_input_stream(environ):
    stream = environ['wsgi.input']

    # This part is new
    if environ.get('wsgi.input_terminated'):
        return stream

    # This part was necessary before anyways to not accidentally
    # read past the length of the stream.
    return wrap_stream(environ['wsgi.input'],
                       environ['CONTENT_LENGTH'])

The only thing that needs to be changed in the WSGI server is either nothing (for instance wsgiref or any other simple WSGI server that just puts the socket through does nothing) or a server like mod_wsgi or gunicorn that terminate the input stream set the flag wsgi.input_terminated to True when making the WSGI environ.

It looks to me that mcdonc proposal, while being pretty smart, would make the contract more complex.

What's wsgi.input_terminated? Who guarantees it's a wrapper to wsgi.input and not a totally different thing? What happens if I read a bit from one and a bit from the other? This is surely an extreme example, but it means there is a chance for inconsistencies.

Having input_terminated just a bool and stating that the input is and will continue to be only wsgi.input requires to specify less constraints on the documentation of the feature imho.