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

Tue Jan 5 08:13:17 EST 2016

Hi all,

Hopefully this discussion won't turn in another useless political
discussion :)

About the need of a new spec aka WSGI 2 or whatever the name you want to I
would say it's definitely needed. But contrary to the others I don't think
it has to be that new, or breaking. If you follow closely the way HTTP2 has
been designed it can be considered as an extension of HTTP 1.x, keeping the
API fixing the following the connections latency and server resource
usages. Grosso modo, the specifications can be split in 3 keys point

- binary protocol
- connections multiplexing, handling more than one 1 request / sockets
- server PUSH to somehow "pre-send" data on request to reduce the latency

Header formats which are btw US-ASCII in the HTTP spec now, could be
already solved if only the frameworks could comply with the spec instead of
trying to impose their own rules.

Websockets or async things are outside the spec.

 All the points above are server side. Behind that the application is
actually doing the same stateless request/response path. Framing/Decoding
is the responsability of the server and should be hidden to the
application. The only addition on the application side is the possibility
to push.

So for me what should be WSGI 2? WSGI 2 should add against WSGI 1 the
following:

- tell to the application it is actually an HTTP2 request (maybe populating
a wsgi.http2 true env)
- tell to the application the request id it is actually answering when
receiving the data (it will be the the responsability of the application to
handle it, asynchronously or not, using asyncio or not, greenlets, threads,
whatever). The server by itself will only process callbacks like it is now.
- expose an API to handle the PUSH api . mostly a way to buffer it on the
server so it can be sent ASAP to the remote client

Besides that I think WSGI 2 is missing the following:

- an UPGRADE api, allowing an application to actually take the client
socket control and do anything with it. In gunicorn it is handled by
providing the raw socket in the environ and tell to gunicorn it can now
ignore this socket:

https://github.com/benoitc/gunicorn/blob/master/examples/websocket/websocket.py#L115

This is useful if an app wants to handle websockets, provides a W3C PUSH
api, ...

- a clear standard to provide to the application the raw URI. Again
Gunicorn is providing it via the environnement using the `RAW_URI` setting.

- a better way to tell  the application it is actually responding (or want
to answer) with chunked encoding data or stream data. Note that actually
there is nothing stopping a WSGI server to handle them. Gunicorn is
actually streaming any data and decode chunks on the fly. Also it is
encoding for the application if the header is present. Using the
FileWrapper api it works quite well. Maybe though we could improve it by
providing a Stream object to distinct it from a File. So for example, the
server don't have to check if it can use sendfile over it or not, which
proved to be annoying across the different python version (also not
efficient). It could also be used to add on server side some stuff like
zero-copy and so on.

Also I think a new spec must make it clear that the server should not have
to be aware about the way the application is handling the request and
respond to them ie asynchronously or not, using threads or not. The
protocol/api should be stateless. And the application must maintains it own
state without any expectation on the way the server maintain it. By that I
mean that lot of people are surprised to not be able to share a pool
between all the requests in gunicorn because they don't use a thread-safe
(and process safe) pool. This should be part of the expectation given by
the spec imo.

Maybe as an extra, we should define more clearly what is a WSGI middleware.

Any feedback is welcome.

- benoît.

On Mon, Jan 4, 2016 at 1:27 PM Cory Benfield <cory at lukasa.co.uk> wrote:

> All,
>
> **TL;DR: What do you believe WSGI 2.0 should and should not do? Should we
> do it at all?**
>
> It’s a new year, and that means it’s time for another attempt to get WSGI
> 2.0 off the ground. Many of you may remember that we attempted to do this
> last year with Rob Collins leading the charge, but unfortunately personal
> commitments made it impossible for Rob to keep pushing that attempt forward.
>
> Since then, the need for a revision of WSGI has become even more apparent.
> Casual discussion on the web has indicated that application developers are
> uncomfortable with the limitations of WSGI. These limitations are providing
> an incentive for both application developers and server developers to take
> an end-run around WSGI in an attempt to get a framework that is more
> suitable for the modern web. A great example of the result of WSGI’s
> deficiencies is Andrew Godwin’s channels work[0] for Django, which
> represents a paradigm shift in application development that takes it far
> away from what WSGI is today.
>
> For this reason, I think we need to try again to get WSGI 2.0 off the
> ground. But I don’t believe we can do this without getting broad consensus
> from the developer community that a revision to WSGI is needed, and without
> understanding what developers need from a new revision of WSGI. This should
> take into account the prior discussions we’d had on this thread: however,
> I’m also going to actively solicit feedback from some of the more notable
> WSGI implementers, to ensure that whatever comes out of this SIG is
> something that they would actually use.
>
> This WG already had a list of requirements, which are as follows:
>
> - Support servers speaking HTTP/1.x, HTTP/2 and Websockets (potentially
> all on a single port).
> - Support graceful degradation for applications that can use HTTP/2 but
> still support HTTP/1.x requests.
> - Graceful incremental adoption path - no upgrade-all-components
> requirement baked into the design.
> - Support Python 2.7 and 3.x (where x is not yet discussed)
> - Support the existing ecosystem of containers (such as mod_wsgi) with the
> new API. We want a clean, fast and approachable API, and we want to ensure
> that its no less friendly to work with than WSGI, for all that it will
> expose much more functionality.
> - Apps need to be able to tell what protocol is in use, and what optional
> features are available. For instance, HTTP/2 PUSH PROMISE is an optional
> feature that can be disabled by clients. Websockets needs to expose a
> socket like object, and so on.
> - Support websockets
> - Support HTTP/2
> - Support HTTP/1.x (which may be just 'point at PEP-3333’.)
> - Continue to support lightweight shims being built on top such as
> https://github.com/Pylons/webob/blob/master/webob/request.py
>
> I believe that all of these requirements are up for grabs, and subject to
> change and consensus discussion. In this thread, then, I’d like to hear
> from people about these requirements and others. What do you believe WSGI
> 2.0 should do? Just as importantly, what do you believe it should not do?
> What prior art should we take into account? Should we bother revising WSGI
> at all, or should we let the wider application ecosystem pursue its own
> solutions à la Django's channels? Should we simply adopt Andrew Godwin’s
> ASGI draft[1] on which channels is based and call *that* WSGI 2.0?
>
> Right now I want this to be very open. I’d like people to come up with a
> broad statement listing what they believe should and should not be present
> in WSGI. This first stage of the work is very general: I just want to get a
> feeling for what the community believes is important. Once we’re done with
> that, if the consensus is that this work is worth pursuing, I’ll come up
> with an initial draft that we can start making concrete changes to.
>
> In the short term, I’m going to keep this consultation open for **at least
> two weeks**: that is, I will not start working on an initial draft PEP
> until at least the **18th of January**. If you believe there are
> application or server developers that should be involved in this
> discussion, please reach out to them and point them to this list. I
> personally have CC’d some people that I believe need to be involved in the
> discussion, but please reach out to others as well.
>
> I’d really love to come to the end of 2016 with a solid direction for the
> future of web programming in Python. I’m looking forward to working with
> you all on achieving that.
>
> Thanks,
>
> Cory
>
>
> [0]: https://channels.readthedocs.org/en/latest/
> [1]: https://channels.readthedocs.org/en/latest/asgi.html
> _______________________________________________
> Web-SIG mailing list
> Web-SIG at python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe:
> https://mail.python.org/mailman/options/web-sig/bchesneau%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20160105/f6463410/attachment.html>