WSGI 1.0 Amendments

This page is intended to collect any ideas related to amendments to the original WSGI 1.0 so that it can be marked as 'Final'.

The purpose of the amendments is to address any mistakes or ambiguities in the 1.0 specification or to change any requirements that in practice could not be implemented for one reason or another. The amendments would also address any differences in how the 1.0 specification should be interpreted for Python 3.0.

Note that this isn't about changing the 1.0 specification drastically in any way, that is what WSGI 2.0 specification will be about.

The page has been created in response to discussion on the Python WEB-SIG.

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.

Python 3.0

Python 3.0 default string type is now Unicode aware and existing strings are now more look byte strings. This changes how terms need to be interpreted. From dicussion on Python WEB-SIG, the following suggested amendments were proposed for Python 3.0.

When running under Python 3, applications SHOULD produce bytes output and headers
When running under Python 3, servers and gateways MUST accept strings as application output or headers, under the existing rules (i.e., s.encode('latin-1') must convert the string to bytes without an exception)
When running under Python 3, servers MUST provide CGI HTTP variables as strings, decoded from the headers using HTTP standard encodings (i.e. latin-1 + RFC 2047) (Open question: are there any CGI or WSGI variables that should NOT be strings?)
When running under Python 3, servers MUST make wsgi.input a binary (byte) stream
When running under Python 3, servers MUST provide a text stream for wsgi.errors

See the mailing list archive for the full discussion of issues.

Note that this doesn't address any clarifications that may be required around wsgi.file_wrapper optional extension.

Errata 1

In the "Specification Details" chapter there is this note:

(Note: the application must invoke the start_response() callable before the iterable yields its first body string, so that the server can send the headers before any body content. However, this invocation may be performed by the iterable's first iteration, so servers must not assume that start_response() has been called before they begin iterating over the iterable.)

What's wrong is that the invocation of start_response may be performed at any iteration of the iterable, as long as the application yields empty strings.

See http://mail.python.org/pipermail/web-sig/2007-December/003064.html for more info.

When HTTP response headers can be sent

The WSGI spec explicitly states that HTTP response headers must be sent when the application yields the first non empty strings.

However if a WSGI implementation is allowed to send headers early (not when start_response is called, but when the first string is yielded by the WSGI application, even if empty), then in case of an HEAD request no content generation is required (assuming, of course, that the WSGI application returns a generator).

See http://mail.python.org/pipermail/web-sig/2007-October/002881.html, http://mail.python.org/pipermail/web-sig/2007-October/002799.html, http://mail.python.org/pipermail/web-sig/2007-October/002803.html and http://mail.python.org/pipermail/web-sig/2007-October/002879.html

That thread is a bit confused.

start_response and error checks

The WSGI spec says that start_response callable must not actually transmit the response headers. Instead, it must store them.

The problem is that it says nothing about errors checking.

See http://mail.python.org/pipermail/web-sig/2007-September/002771.html

Clarification about start_response

What happens if an application call start_response with an incorrect status line or headers?

Should an implementation consider the function called, so that an application can call it a second time, *without* the exc_info parameter?

See http://mail.python.org/pipermail/web-sig/2007-October/002887.html