> 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 _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com