[Web-SIG] WSGI Open Space @ PyCon.

[Robert Brewer]

Alan Kennedy wrote:
> For those of you at PyCon, there is a WSGI Open Space @ 5pm today
> (Friday).
> 
> The sub-title of the open space is "Does WSGI need revision"?

Hi all,

We had a good meeting but it was too short. We plan on having another
Open Space meeting at 5pm today (Saturday) to continue the discussion.

Those present at the first meeting:

 * Mark Ramm (TG)
 * Frank Wierzbicki (Jython)
 * Mike Orr (Pylons)
 * Bob Brewer (CherryPy)
 * Ian Bicking (Paste, etc)
 * Eric Larson (CherryPy, WSGI advocate)
 * Alan Kennedy (WSGI gateway servlets/Jython)
 * Michael Twomey (WSGI user + HTTP servers + Twisted)
 * Jorge Vargas (TG)
 * Ian Charnas (TG CMS)
 * Phil Jenvey (Pylons + Jython)
 * 8+ others, mostly lurking

Topic: Unicode values in the WSGI environ
-----------------------------------------

Request:

We discussed any blockers to this. Request headers are pretty easy since
the spec requires falling back to ISO-8859-1. HOST might be
IDNA-encoded, but that can be consistent, too. What to do with
SCRIPT_NAME and PATH_INFO is more difficult, since there is no consensus
on encoding--there's percent encoding, of course, but that doesn't cover
multi-byte character encodings. The request body (wsgi.input) would not
be decoded.

The general consensus was that we could specify the decoding of the
request metadata (request line and headers) to be the responsibility of
WSGI servers, and leave it at that--different servers may offer
different means of configuring the decoding. There are pitfalls to this
approach, which the spec should address; in particular, some decoding
strategies may not be reversible. In addition, apps should at least know
which encoding the server chose via a new WSGI environ entry. Name
suggestions welcome.

There was some discussion, but no agreement, on including both unicode
and str (str and bytes in Python 3.x) versions of these values in the
environ.


Response:

I *think* the general consensus was that applications could return
unicode status and headers. But we also noted that servers should be
able to encode any bytes using IDNA/ISO-8859-1/RFC-2047/utf-8 where
appropriate. Not sure where this ended up.


Topic: Return a tuple of (status, headers, body)
------------------------------------------------

That is, get rid of the start_response callable. The general consensus
was that this is a simple, but powerful improvement, which Rack/Jack
have demonstrated already. The "simplest possible application object"
would change from this:

  def simple_app(environ, start_response):
      """Simplest possible application object"""
      status = '200 OK'
      response_headers = [('Content-type','text/plain')]
      start_response(status, response_headers)
      return ['Hello world!\n']

...to this:

  def simple_app(environ):
      """Simplest possible application object"""
      status = '200 OK'
      response_headers = [('Content-type','text/plain')]
      body = ['Hello world!\n']
      return (status, response_headers, body)


Topic: wsgi.input
-----------------

Some authors have found problems with the file-like design of
wsgi.input, specifically, that the rfile is not rewindable/seekable; if
a middleware component reads part of the stream, things could get ugly
if a later app tries to read the full stream.

Discussion centered around replacing the current file-like wsgi.input
with an iterable. Origin servers would be responsible for chunking the
request body, and each consumer would be required to re-stream each
chunk.

This topic didn't seem to have the strong consensus that the previous
ones did. My personal feeling was that we need more time to tease out
the new problems this approach would raise (perhaps with an
implementation or two).

Making this change would, however, solve a related issue: how apps can
safely read the full wsgi.input when the client did not supply a
Content-Length (i.e. the servers would handle all that).


Other topics raised but deferred
--------------------------------

 * Standard Request/Response objects. There was one call for, and many
against, this.
 * Lots of little changes: the server's supported HTTP version,
file_wrapper edge cases, etc.
 * Python 3, and the scheduling of WSGI improvements
 * Asynchronous WSGI support. Mostly non-existent. Fix it? Fork it? Drop
it?
 * Lifecycle methods (start/stop/etc event API driven by the container)
 * Remove app_iter.close?


Robert Brewer
fumanchu at aminus.org