[Web-SIG] WSGI for HTTP/2.0 ?

[Robert Collins]

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
PEP:

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.

-Rob