[Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

[chris.dent at gmail.com]

On Mon, 4 Jan 2016, Cory Benfield wrote:

> **TL;DR: What do you believe WSGI 2.0 should and should not do? Should we do it at all?**

TL;DR: WSGI itself should have have some light cleanups and bug
fixes and have de-facto behaviors formalized and then be blessed as
the treasure that it is. A new something-else-that-is-not-WSGI
should be prepared that addresses modern protocols and programming
paradigms.

----

I should disclaim myself by saying that I entered enter web
programming prior to the existence of Perl's CGI.pm, so I have a biased
mental model about how the web™ ought to work that is not well aligned
with current practices. The experience greatly informs my thinking
on this stuff, not necessarily in a good way.

To me the best thing about WSGI, at least in the early days, was how
it created an accessible environment for doing web stuff. It was so
successful that many other languages felt left out and made their
own similar interfaces. Like most successful technologies what made
it a success was not the capabilities it provided but the
constraints it imposed. To the application developer WSGI is relatively
simple.

For old school web stuff this works great: get some headers, get
some request body, do some work, send some headers, send a response
body. That's nice. If you're really feeling fancy you can nest
another app in the "do some work" part. That's nice too.

There's a temptation with the advent of new technologies and
practices to forget the value of constraints and want to provide
knobs for all the cool stuff. While I think we need to address the
new use cases, we need to be careful to keep it tidy.

Keeping things tidy is going to be hard. The request-then-response
handling in most of WSGI is tidy because it models itself as a
_gateway_; there's a clear boundary. To get benefits from HTTP/2,
WebSockets and async programming models the gateway model isn't
going to apply.

So what to do? I think we need to do two separate things. One is to
fix WSGI in some lightweight fashion. The other is to create
something new that supports the new stuff but learns from what WSGI
has done well (perhaps more in terms of constraints and social
context than specific techniques).

As someone who writes their WSGI applications as functions that take
`start_response` and `environ` and doesn't bother with much
framework the things I would like to see in a minor revision to WSGI
are:

* A consistent way to access the raw un-decoded request URI. This is
   so I can reconstruct a realistic `PATH_INFO` that has not been
   subjected to destructive handling by the server (e.g. apache
   messing with `%2F`) before continuing on to a route dispatcher.

* More consistent guidelines on string handling in headers. I'm
   aware of the discussion around ISO-8859-1 and I think it is just
   wrong. At the level of my simple application the header values
   should either be strings (unicode) or UTF-8 encoded bytes. Nothing
   else. If somebody sends the wrong thing it is their fault, not
   mine, they should get the pain not me. I realize that this is not
   entirely a WSGI issue, but it is something I'd like WSGI to help
   me with.

For WSGI, that's probably enough (for me). It has been and will
continue to be a very useful tool for many years to come. For
"simple" web apps it is _great_ and we're still going to want and
need those for a long time.

For applications that want to take advantage of asynchrony, we
should make something new, probably coroutine-based. I'm
insufficiently up on the state of the art these days to go into too
much detail but some things I think worth considering are:

* Corey gave a presentation at PyconUK about layering tools like
   an onion. Requests is the canonical example: requests over urllib3
   over http libraries over socket libraries. I suspect a modern web
   services interface is going to need to provide ways to escape down
   to lower layers to satisfy all use cases but will need to have a
   fairly simple top layer to have any adoption. This is something
   that will need to built into the specification otherwise each
   implementation will come up with its own way and portability and
   server independence that was key to WSGI's success will not be
   there.

* Avoid complexity with regard to byte and string handling by being
   Python 3 only. This also avoids complexity with regards to
   asycnio. It's basically a statement of "if you want to do the new
   stuff, you got to use the new stuff". I think that's a fair
   requirement.

* I like, very much, that the interface to WSGI is a callable with a
   very simple signature and response. I'd be disappointed if the
   signature of the new thing was something other than primitives.

Thanks for getting this ball rolling, again. It can be challenging
when it has been visited so many times. I think making a clean break
to create something new, while still acknowledging the continued
usefulness of the old, is the way to go.
-- 
Chris Dent                                   http://burningchrome.com/
                                 [...]