Amendments to WSGI 1.0¶
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. See Python 3 for details.
Note that this isn’t about changing the 1.0 specification drastically in any way, that is what Proposals related to WSGI 2.0 specification will be about. You should though not construe anything in here as an indication that said change will be made. This is especially the case with Python 3 support as there is a measure of disagreement as to how WSGI should work for Python 3. In other words, you would be unwise to implement any WSGI application or WSGI adapter with information in here as a basis as it could change or simply never be adopted.
The page has been created in response to a discussion on the Python WEB-SIG.
In addition, Graham Dumpleton gives details and clarifications on WSGI 1.0 amendments on his blog.
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¶
Python 3 default string type is now unicode and existing python2 strings correspond to bytes. This changes how terms need to be interpreted. From WSGI, Python 3 and Unicode, the following suggested amendments were proposed for Python 3.
When running under Python 3, applications SHOULD produce bytes output, status line and headers
When running under Python 3, servers and gateways MUST accept strings as application output, status line 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 and 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) streamWhen 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.
Note that current thinking is that the WSGI adaptor should not worry about RFC 2047.
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.
I don’t really think that this is a good assumption to make. I could see how some implementations could allow for this, but strictly speaking, I wouldn’t assume that most implementations would do that. Besides that, what purpose does yielding an empty string serve? For those reasons, I think this is better of left as an undefined behavior. –JasonBaker July 1, 2008
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 calls 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
Specify the type of SERVER_PORT
¶
Some implementations currently expect it to be an integer, some a string. Can we please specify one or the other or either? The “URL reconstruction” code snippet in PEP 333 presumes it’s a string, the reference to the (defunct) CGI spec would seem to imply it should be a string, but it should be explicit.