[Web-SIG] WSGI for HTTP/2.0 ?

[Roberto De Ioris]

> So HTTP/2.0 (http://http2.github.io/http2-spec/index.html) is far
> advanced, and my puny google-fu cannot find any upstream work on
> making a) updating and or replacing WSGI to support HTTP/2's new
> capabilities or b) an HTTP/2 capable SimplerServer or similar
> reference server in the standard library . Huge apologies if I'm wrong
> and pointers accepted!
>
> I did find things like
> https://evonove.it/blog/2012/django-jetty-spdy-blazing-fast/ which
> uses Jython and the Jetty web server to do SPDY (the Google experiment
> that has formed much of the basis of HTTP/2) or
> https://github.com/tatsuhiro-t/nghttp2/blob/master/python/wsgi.py
> which doesn't expose any of the new HTTP/2 features.
>
> So, I'd like to kick of such work, I think the spec is sufficiently
> stable now that we can design APIs in Python for it with confidence,
> even though we may need to tweak things it won't be disruptive.
>
> Specific things that I think we need to cater for:
>  - the streaming and multiplexing facilities
> (http://http2.github.io/http2-spec/index.html#rfc.section.5 and
> http://http2.github.io/http2-spec/index.html#FrameTypes) - this is a
> fairly fundamental departure from HTTP/1.x's strict 'request-response'
> model and exposing it should offer very nice capabilities to site
> authors. HTTP1.x requests look like a half-closed stream on an HTTP/2
> connection, but its entirely possible via the extension mechanism to
> run bidirectional data on a stream initiated by either end (whiile the
> client has a single open stream the server can push a new associated
> stream at any point)
>  - flow control
> (http://http2.github.io/http2-spec/index.html#fc-principles) - for
> file uploads for instance, we can now rate limit single clients
> directly within the protocol
>  - the resource tree
> (http://http2.github.io/http2-spec/index.html#pri-depend) - if we have
> concurrent requests being handled for one client it is now possible to
> explicitly model which ones should be processed and put on the wire
> first, and this should flow up into the application to a degree
>  - GOAWAY
> (http://http2.github.io/http2-spec/index.html#ConnectionErrorHandler)
>  - backwards compat - making sure that straight PEP-3333 apps still
> work well when the server connection is HTTP/2
>
> Is anyone interested in collaborating on an update to WSGI to support
> HTTP/2's new features?
>
> -Rob
>
>

I can help a bit (i am the uWSGI lead developer and a nginx and Cherokee
contributor, and i have already implemented a spdy3 server last year)

I honestly think that WSGI by itself needs a complete rewrite/rethink to
be adapted to modern (ok someone could say 'fashioned') patterns (that are
somewhat more 'urgent' than HTTP/2), but i agree that starting thinking
about HTTP/2 could be a good thing.

-- 
Roberto De Ioris
http://unbit.it