[Web-SIG] WSGI Open Space @ PyCon.

[Eric Larson]

Hi,

On Sat, Mar 28, 2009 at 10:04 AM, Robert Brewer <fumanchu at aminus.org> wrote:
> 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)
>
>

Seeing as this tuple idea is low hanging fruit, I went ahead and
created a small bit of middleware for making the conversion.

http://bitbucket.org/elarson/pack/wiki/Home

Hope it helps!

Eric Larson

> 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
>
> _______________________________________________
> Web-SIG mailing list
> Web-SIG at python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe: http://mail.python.org/mailman/options/web-sig/ionrock%40gmail.com
>