Re: [Web-SIG] WSGI for HTTP/2.0 ?
On 22 September 2014 00:08, Robert Collins robe...@robertcollins.net wrote:
On 21 September 2014 16:43, Roberto De Ioris robe...@unbit.it wrote:
I've proposed using github issues instead of documents; we can
synthesis the issues into prose in the draft docs and reference code
itself. I think this will be easier to manage than having a dozen
different comment-documents in the repo.
-Rob
I completely agree and i have already opened two 'issues'. If we change
idea on how to work on it feel free to delete them :)
Cool, thank you!
I've put my thoughts up in them, and pulled out what I think are
clearly sane requirements from them into a nascent requirements.rst
file.
I haven't closed the issues, since the actual spec covering those
requirements doesn't exist. And that leads to what is I think a fairly
key question.
Do we:
- incorporate PEP- by reference [e.g. by saying 'any HTTP/1.{0,1}
request will be processed as per PEP-']
or
- do we want to alter how HTTP/1.{0,1} requests are presented (e.g.
tackling encoding of headers etc)
Timing the question out: I'm going with the latter case: a clean new
spec with consistent handling of feature that are common to all the
supported protocols, and folk that want existing things to keep
running wrap them with an adapter we'll provide.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
___
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
Re: [Web-SIG] WSGI for HTTP/2.0 ?
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- 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
Re: [Web-SIG] WSGI for HTTP/2.0 ?
On 20/09/2014, at 3:49 PM, Roberto De Ioris robe...@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@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] WSGI for HTTP/2.0 ?
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 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.dumple...@gmail.com wrote: On 20/09/2014, at 3:49 PM, Roberto De Ioris robe...@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@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/bchesneau%40gmail.com ___ 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
Re: [Web-SIG] WSGI for HTTP/2.0 ?
On 20 September 2014 18:31, Graham Dumpleton graham.dumple...@gmail.com wrote: On 20/09/2014, at 3:49 PM, Roberto De Ioris robe...@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. I don't particular care what we call it - extending/overhauling/replacing. Lets call the new API WSGI2 as a shorthand for 'WSGI extended or overhauled to support things that are way overdue'. I think the key thiings we need are: - support HTTP/2 - still support HTTP/1.x - This is reasonable because many environments will want a single server accepting both HTTP/1.x and 2 at once with graceful degradation - support websockets - be backportable to Python2.7+ - be adoptable by uWSGI/mod_wsgi/weurkzeug/gunicorn/Twisted's thread-pool adapter etc - be approximately as easy to write middleware and glue for as WSGI has been - have a sane migration path for servers, middleware and apps: a big-bang approach isn't going to fly with the huge install base of WSGI - be able to write both forward and backwards compatibilty shims: that is, a) be able to write an adapter that exposes WSGI2 on the top and pure, compatible WSGI on the bottom b) be able to write an adapter that exposes WSGI on the top and a restricted WSGI2 on the bottom. (Where graceful degradation means behaving the same as if an HTTP/1.x connection was being handled). 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. The Apache module interface is a lot wider than WSGI today, so I'm glad to hear you believe it won't need changing! WSGI has no equivalent for the CONNECTION filter, for instance (and arguably shouldn't because thats very much a server responsibility) - but we need something to hack websockets and push responses on. So, overhaul WSGI as the primary aim, but within that factor in things to allow for HTTP 2.0 functionality. I consider HTTP/2 one of potentially several primary aims: I'm delighted to collaborate on overhauling WSGI, but if we overhaul it and don't *deliver* HTTP/2, then I think thats going to be bad - there is every opportunity for us to miss a fine detail and end up having to rev our spec as soon as implementors find issues. 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. Well, thats certainly a challenge :). Whats the governance model here? Is a PEP appropriate, and if so - that gives us a BFDL or BFDL PEP-delegate to decide between bikeshed issues; and if its not a bikeshed issue then resolving it is actually necessary. 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. :-) I will happily discuss stuff with you off-list, but I'm not particularly interested in having the primary effort be cabal style - HTTP/2 has managed to go through a much harder rev with very strong personalities and much the same sort of death possible as you're concerned about here with great transparency. I don' t think thats incompatible with your needs though - for instance, if you want to stay offlist and debate privately to avoid 1000-cut-pain : thats fine, but I reserve the right to summarise and discuss things here (and equally to ignore kibbitzing here that isn't being productive). As far as qualifications, I've a long history with HTTP (about 14 years now - I joined the Squid project circa 2000), applications that will benefit from it
Re: [Web-SIG] WSGI for HTTP/2.0 ?
On 20 September 2014 19:14, Benoit Chesneau bchesn...@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 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 ___ 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
Re: [Web-SIG] WSGI for HTTP/2.0 ?
On 20 September 2014 08:23, Robert Collins robe...@robertcollins.net wrote: I will happily discuss stuff with you off-list, but I'm not particularly interested in having the primary effort be cabal style - HTTP/2 has managed to go through a much harder rev with very strong personalities and much the same sort of death possible as you're concerned about here with great transparency. That's true...but it has been extremely painful for all concerned. There is minimal appetite left in the WG to continue with the work, and a number of people quite want to put a pin in things to just give themselves a break. I suspect this is what Graham is worried about, and as I recall he is speaking from bitter experience. I don' t think thats incompatible with your needs though - for instance, if you want to stay offlist and debate privately to avoid 1000-cut-pain : thats fine, but I reserve the right to summarise and discuss things here (and equally to ignore kibbitzing here that isn't being productive). I'd like to propose instead something of a third way, inspired by the HTTPBis. A small cabal, off-list, come up with an initial proposal that is essentially complete (a la SPDY). That proposal should ideally have running code behind it so that it can be played with (also like SPDY). That proposal is then brought to the list for further refinement. This allows Graham to input early, and ensures open review of the proposal while those who don't want to participate in the fully-open forum can absent themselves from the discussion. Of course, I'd like to help regardless of the actual procedure we use. Cory ___ 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
Re: [Web-SIG] WSGI for HTTP/2.0 ?
On Sat, Sep 20, 2014 at 9:23 AM, Robert Collins robe...@robertcollins.net wrote: Well, thats certainly a challenge :). Whats the governance model here? Is a PEP appropriate, and if so - that gives us a BFDL or BFDL PEP-delegate to decide between bikeshed issues; and if its not a bikeshed issue then resolving it is actually necessary. Yes, I think a good way forward would be to have a small cabal write a PEP and then announce it here for further feedback and then pronouncement by a BDFL or -delegate. If you want to be lead/editor, that sounds great. It also seems like you should definitely involve Graham and give credence to his thoughts. I'd be excited about this and happy to give feedback a little later once you've got some initial draft, as someone who likes to implement his applications directly on top of WSGI for now (but I've also implemented a couple of WebSocket servers). Cheers, Dirkjan ___ 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
Re: [Web-SIG] WSGI for HTTP/2.0 ?
On Sat, Sep 20, 2014 at 3:22 PM, Dirkjan Ochtman dirk...@ochtman.nl wrote: On Sat, Sep 20, 2014 at 9:23 AM, Robert Collins robe...@robertcollins.net wrote: Well, thats certainly a challenge :). Whats the governance model here? Is a PEP appropriate, and if so - that gives us a BFDL or BFDL PEP-delegate to decide between bikeshed issues; and if its not a bikeshed issue then resolving it is actually necessary. Yes, I think a good way forward would be to have a small cabal write a PEP and then announce it here for further feedback and then pronouncement by a BDFL or -delegate. If you want to be lead/editor, that sounds great. It also seems like you should definitely involve Graham and give credence to his thoughts. I'd be excited about this and happy to give feedback a little later once you've got some initial draft, as someone who likes to implement his applications directly on top of WSGI for now (but I've also implemented a couple of WebSocket servers). Cheers, Dirkjan Last time was more about everyone wanted to discuss about the changes with its own requirement list. Which is already conflicting. Discussing if it should be done outside the media designed for it is already out of topic imo. So I won't discuss about it further. Instead I wonder what is the appropriate medium to collect requirements and others stuffs about it. Wiki ? Anything else? For a start I see these different topics 1) HTTP 1.1 vs HTTP 2: - HTTP 1.1 and HTTP2 have quite the same high level syntax (methods, uri, headers, ...) but the way the data is transported differs. (data are sent by frames in HTTP 2). - in HTTP 2, data can be encrypted and compressed. - in HTTP2 data can pushed from the server to the clients. More data can be sent to the client - in HTTP2 streams are multiplexed We have the concept of data channels and these are more like message passings. Multiplexing existed in HTTP 1.1 with pipelines but is barely supported right now by WSGI servers. The concept of data channels and the PUSH features will requires more concurrency at the server level. At the application, things doesn't change that much. Everything can appear like before. The only change is the PUSH feature. 2) Websockets, SSE and other similar protocoles are completely asynchronous. All this part is not really handled by WSGI. The way it is generally implemented right now is awkward. The server generally extend the WSGI protocol so the application get the socket. Then a specific library handle the rest. I actually wonder if websockets or other asynchronous protocols should be handled by the new WSGI SPEC. Shouldn't we just standardize the way the socket is given to another library? Anyway I think we should collect all requirements at application and server level and then start to confront the current WSGI spec to them. And iterate. Thoughts? Any other topic? - benoit ___ 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
Re: [Web-SIG] WSGI for HTTP/2.0 ?
got an idea. What about having a page collecting feedback from anyone in the python community about this topic. So we can have true data from different perspectives: developer, library/framework author, server author. I'm OK to collect the data from it and make a summary of it once it's done. The form it could take should be discussed first but imo that a good way to engage the community. What do you think? On Sat, Sep 20, 2014 at 4:17 PM, Benoit Chesneau bchesn...@gmail.com wrote: On Sat, Sep 20, 2014 at 3:22 PM, Dirkjan Ochtman dirk...@ochtman.nl wrote: On Sat, Sep 20, 2014 at 9:23 AM, Robert Collins robe...@robertcollins.net wrote: Well, thats certainly a challenge :). Whats the governance model here? Is a PEP appropriate, and if so - that gives us a BFDL or BFDL PEP-delegate to decide between bikeshed issues; and if its not a bikeshed issue then resolving it is actually necessary. Yes, I think a good way forward would be to have a small cabal write a PEP and then announce it here for further feedback and then pronouncement by a BDFL or -delegate. If you want to be lead/editor, that sounds great. It also seems like you should definitely involve Graham and give credence to his thoughts. I'd be excited about this and happy to give feedback a little later once you've got some initial draft, as someone who likes to implement his applications directly on top of WSGI for now (but I've also implemented a couple of WebSocket servers). Cheers, Dirkjan Last time was more about everyone wanted to discuss about the changes with its own requirement list. Which is already conflicting. Discussing if it should be done outside the media designed for it is already out of topic imo. So I won't discuss about it further. Instead I wonder what is the appropriate medium to collect requirements and others stuffs about it. Wiki ? Anything else? For a start I see these different topics 1) HTTP 1.1 vs HTTP 2: - HTTP 1.1 and HTTP2 have quite the same high level syntax (methods, uri, headers, ...) but the way the data is transported differs. (data are sent by frames in HTTP 2). - in HTTP 2, data can be encrypted and compressed. - in HTTP2 data can pushed from the server to the clients. More data can be sent to the client - in HTTP2 streams are multiplexed We have the concept of data channels and these are more like message passings. Multiplexing existed in HTTP 1.1 with pipelines but is barely supported right now by WSGI servers. The concept of data channels and the PUSH features will requires more concurrency at the server level. At the application, things doesn't change that much. Everything can appear like before. The only change is the PUSH feature. 2) Websockets, SSE and other similar protocoles are completely asynchronous. All this part is not really handled by WSGI. The way it is generally implemented right now is awkward. The server generally extend the WSGI protocol so the application get the socket. Then a specific library handle the rest. I actually wonder if websockets or other asynchronous protocols should be handled by the new WSGI SPEC. Shouldn't we just standardize the way the socket is given to another library? Anyway I think we should collect all requirements at application and server level and then start to confront the current WSGI spec to them. And iterate. Thoughts? Any other topic? - benoit ___ 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
Re: [Web-SIG] WSGI for HTTP/2.0 ?
On 20 September 2014 15:17, Benoit Chesneau bchesn...@gmail.com wrote: 1) HTTP 1.1 vs HTTP 2: - HTTP 1.1 and HTTP2 have quite the same high level syntax (methods, uri, headers, ...) but the way the data is transported differs. (data are sent by frames in HTTP 2). Yes, this is correct. *In principle*, much of the way WSGI transmits information can remain exactly the same, at least from the perspective of working with HTTP/2. - in HTTP 2, data can be encrypted and compressed. Not by default. HTTP/2 DATA frame compression got removed from the draft spec in draft-13. It's currently available in a draft extension, but it'll only ever be an extension to HTTP/2. HTTP/2 encryption is just the same as for HTTP/1.1: TLS. At the application, things doesn't change that much. Everything can appear like before. The only change is the PUSH feature. Server Push is important, but I think you've missed some really key points in HTTP/2 that are potentially valuable to expose at the application level. Firstly, HPACK provides special provision for marking some headers as 'never index'[0]. This is for security reasons, and is intended to signal that no-one should keep that header value in their header tables. We may well want to expose this functionality. Secondly, HTTP/2 DATA frames can be padded. Assuming padding remains in the spec (not guaranteed), this is another security feature that we may want to expose to the application. (Exposing this to application is kinda stupid, but we can't leave it to the server because it won't know what to pad and what not to pad.) Thirdly, we need to remember that HTTP/2 streams are flow controlled. This requires the design to very carefully consider how a response blocked by flow control behaves. Fourthly, the multiplexing is *prioritised*. This priority information may need to be accessible to the application in order to make decisions based on it. Fifthly, while HTTP/2 is *able* to handle the standard HTTP/1.1 request-response cycle, it needn't be *limited* to it. In particular, long-polling works a whole lot better in HTTP/2 because of fact that stream lifetime is potentially unlimited. Similarly, because streams are bidirectional it may become popular to use HTTP/2 streams as ad-hoc websocket connections. These are all suggestions that we shouldn't necessarily cleave too closely to the current WSGI paradigm. I'm sure I've missed some other things as well. What I wanted to highlight is that HTTP/2 is a subtle, complex protocol that is much more powerful than the one it replaces. We should very carefully consider how we approach a new WSGI specification, because we're going to be stuck with it for the next few years. I do think the idea of collating feedback is a good one, however. [0]: https://tools.ietf.org/html/draft-ietf-httpbis-header-compression-09#section-7.2.3 ___ 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
Re: [Web-SIG] WSGI for HTTP/2.0 ?
Hi Benoit, I actually wonder if websockets or other asynchronous protocols should be handled by the new WSGI SPEC. Shouldn't we just standardize the way the socket is given to another library? Considering the websocket connection is initiated via a HTTP request, it would be a good idea that the newer WSGI interface keeps it in mind even if it doesn't address the protocol itself. As you say, the current state is akward at best. -- - Sylvain http://www.defuze.org http://twitter.com/lawouach ___ 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
Re: [Web-SIG] WSGI for HTTP/2.0 ?
On 09/20/2014 02:31 AM, Graham Dumpleton wrote: 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. I'm no one important in the Python world, but, FWIW, I agree with you. I've followed your work over the years and believe you have a penchant for details and accuracy as evidenced by your comments here on the list and your work on modwsgi and wrapt. I'd be very interested in seeing what you could come up with. IMO, if you are up for it, you should feel free to grab a few people that you would like to work with and hammer out a PEP (or it's precursor). Then, let the PEP process work as it's intended to. Hopefully, this method results in a trend towards more concrete and specific arguments and less likely to die of a thousand cuts. I'm going to refer this group as the draft team. On 20 September 2014 19:14, Benoit Chesneau bchesn...@gmail.com wrote: I would prefer to have this work being done transparently. If we do it rationally it could work imo. I don't think anyone is arguing against transparency. But momentum matters and, in the history of changes to the WSGI spec, momentum has died pretty easily even when there were clearly changes that needed to be made. If Graham, or anyone else for that matter, has the gumption to go at this thing hard and get something written down, I think that that should be encouraged. Even if the initial phases of that processes are behind closed doors, transparency will come eventually and there will be opportunity for comment. But if you make the process too transparent too early, the energy used to keep up with everyone and all the different needs can take away from doing the actual work of defining the spec. got an idea. What about having a page collecting feedback from anyone in the python community about this topic. So we can have true data from different perspectives: developer, library/framework author, server author. I'm OK to collect the data from it and make a summary of it once it's done. This seems reasonable. That way, interested parties could get their comments on record without the draft team needing to feel like that have to satisfy or even have a discussion about every comment. The form it could take should be discussed first but imo that a good way to engage the community. What do you think? I'd suggest a wsgi comments github repo. Workflow: * Submit a document to the repo with your comments on the future version of WSGI o use any readable format you want (Markdown, RST, plain text, etc.). o include name, contact information, background. Make sure to give enough info about your background so the draft team has some context for the proposals and comments you are making. * Any desired discussion by interested parties can be had on the pull request page (or here I guess, but that might be noisy) * The author can update pull request if desired based on discussion * pull requests are automatically accepted after some time period (1 week?) of no further comments o the delay in acceptance is to give time for discussion and updates to the PR o a PR merge does not indicate that the idea will be accepted into the WSGI PEP, it's just being merged into the comments repo * an individual should only update their own document, no PRs against someone else's document. o comments/discussions should go on the PR Just my $0.02. *Randy Syring* Husband | Father | Redeemed Sinner /For what does it profit a man to gain the whole world and forfeit his soul? (Mark 8:36 ESV)/ ___ 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
Re: [Web-SIG] WSGI for HTTP/2.0 ?
On 21 September 2014 06:15, Randy Syring ra...@thesyrings.us wrote: I'd suggest a wsgi comments github repo. So in the interests of getting things done and the spirit of EAFP I've set up https://github.com/python-web-sig/wsgi-ng. Since I have no deep history in web-sig, I'll happily hand out 'organisation admin' to someone (e.g. Bill) with such history - I'm not trying to land-grab the name, just to use something sensibly named. That said I'd like to keep the direct committers to that specific repository limited to whomever manages to end up collaborating well: I have a better understanding of the burnout issue thanks to the responses in this thread. Workflow: Submit a document to the repo with your comments on the future version of WSGI use any readable format you want (Markdown, RST, plain text, etc.). include name, contact information, background. Make sure to give enough info about your background so the draft team has some context for the proposals and comments you are making. I've proposed using github issues instead of documents; we can synthesis the issues into prose in the draft docs and reference code itself. I think this will be easier to manage than having a dozen different comment-documents in the repo. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ 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
Re: [Web-SIG] WSGI for HTTP/2.0 ?
I've proposed using github issues instead of documents; we can synthesis the issues into prose in the draft docs and reference code itself. I think this will be easier to manage than having a dozen different comment-documents in the repo. -Rob I completely agree and i have already opened two 'issues'. If we change idea on how to work on it feel free to delete them :) -- 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
Re: [Web-SIG] WSGI for HTTP/2.0 ?
On 13 September 2014 19:40, Robert Collins robe...@robertcollins.net wrote: Is anyone interested in collaborating on an update to WSGI to support HTTP/2's new features? I'd be happy to help. I know extremely little about WSGI (though I'm sure I can read up on it), but I'm pretty heavily involved with HTTP/2 (as you know!) so I think I can provide some value. Cory ___ 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
Re: [Web-SIG] WSGI for HTTP/2.0 ?
I'm also up to help with this. I haven't been very involved in HTTP/2 or WSGI, but I'm happy to help with both. ___ 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
[Web-SIG] WSGI for HTTP/2.0 ?
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- 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 -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ 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
