[Web-SIG] Request for Comments on upcoming WSGI Changes

[Ian Bicking]

On Sun, Sep 20, 2009 at 8:06 AM, Armin Ronacher
<armin.ronacher at active-4.com> wrote:
> Thanks to Graham Dumpleton and Robert Brewer there is some serious
> progress on WSGI currently.  I proposed a roadmap with some PEP changes
> now that need some input.
>
> Summary:
>
>  WSGI 1.0       stays the same as PEP 0333 currently is
>  WSGI 1.1       becomes what Ian and I added to PEP 0333
>  WSGI 2.0       becomes a unicode powered version of WSGI 1.1
>  WSGI 3.0       becomes WSGI 2.0 just without start_response
>
>  WSGI 1.0 and 1.1 are byte based and nearly impossible to use on Python
>  3 because of changes in the standard library that no longer work with
>  a byte-only approach.

1.1 I think of as an errata on 1.0, so... simple enough.

I was skeptical about a unicode version of WSGI, but I think I'm okay
with it now.  For people who use UTF-8-only it should be fairly simple
and easy; for people who want to deal with other encodings, backward
compatible URLs, or other weirdness I think surrogateescape can
resolve the small handful of problems.  Maybe an option to use latin1
(at the server level) would do the same for Python 2, as a deployment
option for people who are dealing with these tricky issues.  Which is
kind of lame, but it means everything is still *possible*, and the use
cases are somewhat obscure.  Especially because QUERY_STRING and
wsgi.input remain bytes.  (Well, I guess the other case would be
someone reading a cookie set by an application they do not control,
and set in a crazy way... but anyway, there's a handful of use cases
where things get tricky, but we can kind of punt, or try to implement
the necessary transcoding routines before the spec is final.)  I'm
very much opposed to a second "raw" version of the request, as I do
not like redundancy.

With respect to 3.0/start_response, I'd rather we just do both at
once, so there's not so many versions of WSGI to worry about.  Also it
doesn't feel like a very difficult change to make.

The only other major issue is wsgi.input, which is a quite awkward
interface to the request body.  But I think resolving that is harder
than start_response, in particular because there's no clear solution.
Maybe at least switching to a file interface would be better.

-- 
Ian Bicking  |  http://blog.ianbicking.org  |  http://topplabs.org/civichacker