Navigation

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.

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.

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.