[Web-SIG] WSGI for HTTP/2.0 ?

Robert Collins robertc at robertcollins.net
Sat Sep 20 09:53:25 CEST 2014

On 20 September 2014 19:14, Benoit Chesneau <bchesneau at gmail.com> wrote:
> Hi,
> I would prefer to have this work being done transparently. If we do it
> rationally  it could work imo.
> Anyway before thinking to change the protocol or criticizing it maybe we
> could first collect the requirements in HTTP 2 (stream and such) so we can
> think about possible implementations. And see what it misses in WSGI.
> I am thinking we could adopt the same path used to decided to go for HTTP
> 1.x or HTTP 2  on the client part. Ie keeping WSGI and PEP 3333 for HTTP 1.1
> applications  and go for a new interface in HTTP2. But such decision should
> be done once we have a clear view of what requires HTTP 2 and how it can be
> handled on the python side.
> Thoughts?

+1 on transparency. Agree that before we consider what we need to
change we need to set our goals up - thats basically the charter for a

Here is a straw man in prose form:
We want to create a clean common API for applications and middleware
written in a post HTTP/2 world - where single servers may accept up to
all three of HTTP/1.x, HTTP/2 and Websocket connections, and
applications and middleware want to be able to take advantage of
HTTP/2 and websockets when available, but also degrade gracefully. We
also want to ensure that there is a graceful incremental path to
adoption of the new API, including Python 2.7 support, and shims to
enable existing WSGI apps/middleware/servers to respectively be
contained, contain-or-be-contained and contain, things written to this
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.


More information about the Web-SIG mailing list