[Web-SIG] WSGI for HTTP/2.0 ?

Benoit Chesneau bchesneau at gmail.com
Sat Sep 20 09:14:13 CEST 2014


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?

- benoit



On Sat, Sep 20, 2014 at 8:31 AM, Graham Dumpleton <
graham.dumpleton at gmail.com> wrote:

>
> On 20/09/2014, at 3:49 PM, Roberto De Ioris <roberto at unbit.it> wrote:
>
> > 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.
>
> I agree.
>
> Overhauling WSGI has more relevance because an underlying web server
> updating itself to support HTTP 2.0 will in the main have little relevance
> at the application layer as the web server is more than likely to have an
> adapter layer which makes things look the same to existing modules/protocol
> adapters.
>
> In other words, Apache adding support for HTTP 2.0 isn't going to result
> in some sort of wholesale change of the Apache module interface, it would
> stay the same say whether HTTP 2.0 is used, especially just as an alternate
> way of doing the same thing as HTTP 1.1. In that respect, since no HTTP 2.0
> specific functionality is going to be made visible through exist
> interfaces, then Apache modules or adapters for FASTCGI/SCGI etc or even
> mod_wsgi are simply not going to change.
>
> So, overhaul WSGI as the primary aim, but within that factor in things to
> allow for HTTP 2.0 functionality.
>
> The problem with trying to overhaul WSGI is that if it is done in an open
> forum like the Web-SIG it will die of a thousand cuts, as past efforts to
> update it in even minor ways have suffered.
>
> The only way that WSGI itself will ever see an overhaul is through the
> strong willed determination of a few people off list, out of sight, to
> allow it it to be fully fleshed out, with input coming from direct
> consultation with and review by other related parties who have a vested
> interested or significant experience in the area.
>
> I may be up for such an off list effort, but be warned I may want to run
> roughshod over it and exert quite a lot of influence over the process and
> outcome. :-)
>
> Graham
> _______________________________________________
> 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/20140920/4772108e/attachment.html>


More information about the Web-SIG mailing list