WSGI 2.0

This page is intended to collect any ideas related to WSGI 2.0. In particular, any proposed changes to the specification.

NOTE: What is described here should not be considered a DRAFT for WSGI 2.0. It is only a list of ideas or issues that need to be considered if there ever is enough momentum towards producing an updated WSGI specification. It is quite possible that there may never be an updated specification which embodies the ideas described here. Thus, if you implement any web application interfaces based on the API described here, call it something else, do not call it WSGI 2.0 as no such thing exists.

start_response and write

We could remove start_response and the writer that it implies. This would lead to a signature like:

def app(environ):
    return '200 OK', [('Content-type', 'text/plain')], ['Hello world']

That is, return a three-tuple of (status, headers, app_iter).

It's relatively simple to provide adapters to and from this signature to the WSGI 1.0 signature.

Making some keys required

Several keys are optional in WSGI, but required in CGI, in particular SCRIPT_NAME, PATH_INFO and QUERY_STRING. Also REMOTE_ADDR and SERVER_SOFTWARE are supposed to exist, even if empty. All these keys could become required in WSGI.

Unknown-length wsgi.input

There's no documented way to indicate that there is content in environ['wsgi.input'], but the content length is unknown. A value of "-1" may work in many situations. A missing CONTENT_LENGTH doesn't generally work currently (it's assumed to mean 0 by much code).

This is an issue because chunked transfer encoding on request content can't be supported properly unless there is a way to indicate that there is data with unknown content length. Also an issue with a web server or WSGI middleware component that mutates the input stream (eg. decompression), where it will not know the new content length in advance of mutating the data stream.

Any change in this area also needs to take into consideration the current link between CGI and WSGI specifications and whether the CGI requirement to not read more input data than defined by CONTENT_LENGTH and that returning an EOF indicator is optional is really appropriate for WSGI.

For more information see thread: http://mail.python.org/pipermail/web-sig/2007-March/002630.html

readline(size)

Currently the specification does not require servers to provide environ['wsgi.input'].readline(size) (the size argument in particular). But cgi.FieldStorage calls readline this way, so in effect it is required.

app_iter and threads

It's not clear if the app_iter must be used in the same thread as the application. Since the application is blocking, presumably it must be run all in one thread. This should be more explicitly documented.

long response headers

Noted here: http://mail.python.org/pipermail/web-sig/2006-September/002244.html

request trailers and chunked transfer encoding

When using chunked transfer encoding on request content, the RFCs allow there to be request trailers. These are like request headers but come after the final null data chunk. These trailers are only available when the chunked data stream is finite length and when it has all been read in, thus not available at time that start application is called.

Decoding SCRIPT_NAME/PATH_INFO

Because SCRIPT_NAME and PATH_INFO are decoded in WSGI, there's no way to distinguish %2F from /