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 :doc:`python3` for details. Note that this isn't about changing the 1.0 specification drastically in any way, that is what :doc:`proposals-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 :py:class:`cgi.FieldStorage` calls readline this way, so in effect it is required. Python 3 -------- :doc:`python3` 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 :envvar:`wsgi.input` a binary (byte) stream * When running under Python 3, servers **MUST** provide a text stream for :envvar:`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 :envvar:`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.