This page is intended to collect any ideas related to WSGI 2.0. In particular, any proposed changes to the specification.
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.
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.
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.
There’s no documented way to indicate that there is content in 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
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.
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.
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.
Analysis see there: http://email@example.com/msg02483.html
Can we have that horror removed for wsgi2 apps, please?
A quite easy approach would be to have a set of RAW_* env vars (e.g. RAW_PATH_INFO) that has /Foo%XXBar%YY content (is not decoded, plain ascii like in the http protocol).
That also would solve issues with ? and / (see section above) that are encoded as %XX (and NOT meant as query / path component separator).
Any wsgi1 app can continue to use the wsgi1 env vars, any wsgi2 app can check whether the wsgi2 RAW_* env vars are there and use them (or fall back to using the wsgi1 env vars).
Enter search terms or a module, class or function name.