Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

> On 6 Jan 2016, at 20:06, Graham Dumpleton wrote: > > >> On 6 Jan 2016, at 10:19 PM, Cory Benfield wrote: >> >> >>> On 6 Jan 2016, at 09:48, Graham Dumpleton >>> wrote: >>> >>> If this does solve the push issue, what is there in HTTP/2 then that one >>> couldn’t do via the existing WSGI

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

> All, > > **TL;DR: What do you believe WSGI 2.0 should and should not do? Should we do > it at all?** ... > - Support HTTP/2 I've read a bit about HTTP/2 PUSH functionality, and it seems to me that it can (and probably would be) supported in web servers similar to how X-SendFile etc work, ie by

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

> On 6 Jan 2016, at 10:19 PM, Cory Benfield wrote: > > >> On 6 Jan 2016, at 09:48, Graham Dumpleton wrote: >> >> If this does solve the push issue, what is there in HTTP/2 then that one >> couldn’t do via the existing WSGI interface? > > Well, plenty, but none that we’d *want* to expose via

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

* Graham Dumpleton wrote: > > On 6 Jan 2016, at 12:13 AM, Benoit Chesneau > > wrote: > > > > So for me what should be WSGI 2? WSGI 2 should add against WSGI 1 the > > following: > > > > - tell to the application it is actually an HTTP2 request (maybe > > populating a wsgi.http2 true env) > > In C

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

> On 6 Jan 2016, at 20:34, Andrew Svetlov wrote: > > When we are talking about "async WSGI" it's not clear for me what > concrete async implementation we are discussing. > In Python world there are at least 3 major async approaches (twisted, > tornado, asyncio) and many minor libraries. Any, an

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

[Cory Benfield] > Folks, just a reminder: RFC 2616 is dead. RFC 7230 says that *newly defined* header > fields should limit their field values to US-ASCII, but older header fields are a > crapshoot (though it notes that “in practice, most” header field values use US-ASCII). > > Regardless, it seems

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

When we are talking about "async WSGI" it's not clear for me what concrete async implementation we are discussing. In Python world there are at least 3 major async approaches (twisted, tornado, asyncio) and many minor libraries. Let's assume we are talking about asyncio way -- it's standardized by

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

what do you need asynchronous? And how the current callback system can't fit the needs of an an asynchronous lib? what do you miss actually? Note that http and http2 are not asynchronous. Imo we need a new WSGI spec and a Messaging gateway spec. but these are orthogonal discussions imo. - benoit

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

> On 4 Jan 2016, at 20:27, Cory Benfield wrote: > > All, > > **TL;DR: What do you believe WSGI 2.0 should and should not do? Should we do > it at all?** > > It’s a new year, and that means it’s time for another attempt to get WSGI 2.0 > off the ground. Many of you may remember that we attemp

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

> On 6 Jan 2016, at 09:19, Aymeric Augustin > wrote: > > Hello Benoît, > > Thanks for clarifying that you also had the reverse problem in mind, headers > sent by applications. This side is less problematic in the sense that > application authors can adapt to stronger requirements. > > In ge

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

> On 6 Jan 2016, at 09:48, Graham Dumpleton wrote: > > If this does solve the push issue, what is there in HTTP/2 then that one > couldn’t do via the existing WSGI interface? Well, plenty, but none that we’d *want* to expose via WSGI with the possible exception of long-running bi-directional

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

> On 5 Jan 2016, at 10:31 PM, Graham Dumpleton > wrote: > >>> For example, mod_wsgi already supports HTTP/2 by virtue of the fact that >>> the mod_h2 module in Apache exists. The existing internal APIs of Apache >>> and how mod_wsgi uses those means that HTTP/2 bridges into the WSGI world >>

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

On Wed, Jan 6, 2016 at 10:29 AM Graham Dumpleton wrote: > > On 6 Jan 2016, at 12:13 AM, Benoit Chesneau wrote: > > So for me what should be WSGI 2? WSGI 2 should add against WSGI 1 the > following: > > - tell to the application it is actually an HTTP2 request (maybe > populating a wsgi.http2 tru

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

On Wed, Jan 6, 2016 at 10:19 AM Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > Hello Benoît, > > Thanks for clarifying that you also had the reverse problem in mind, > headers sent by applications. This side is less problematic in the sense > that application authors can adapt to

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

> On 6 Jan 2016, at 12:13 AM, Benoit Chesneau wrote: > > So for me what should be WSGI 2? WSGI 2 should add against WSGI 1 the > following: > > - tell to the application it is actually an HTTP2 request (maybe populating a > wsgi.http2 true env) In CGI implementations you would for HTTP/1.1 a

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

On Tue, Jan 5, 2016 at 3:17 PM Aymeric Augustin < aymeric.augustin.2...@polytechnique.org> wrote: > Hello Benoît, > > > Le mardi 5 janvier 2016 14:13:48 UTC+1, Benoit Chesneau a écrit : >> >> Header formats which are btw US-ASCII in the HTTP spec now, could be >> already solved if only the framewo

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

> On 6 Jan 2016, at 9:27 AM, chris.d...@gmail.com wrote: > > On Wed, 6 Jan 2016, Graham Dumpleton wrote: > >> >>> On 6 Jan 2016, at 12:09 AM, chris.d...@gmail.com wrote: >>> >>> As someone who writes their WSGI applications as functions that take >>> `start_response` and `environ` and doesn't

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

> On 6 Jan 2016, at 9:19 AM, Graham Dumpleton > wrote: > >> On 6 Jan 2016, at 12:09 AM, chris.d...@gmail.com >> wrote: >> >> As someone who writes their WSGI applications as functions that take >> `start_response` and `environ` and doesn't bother with much >> fra

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

On Wed, 6 Jan 2016, Graham Dumpleton wrote: On 6 Jan 2016, at 12:09 AM, chris.d...@gmail.com wrote: As someone who writes their WSGI applications as functions that take `start_response` and `environ` and doesn't bother with much framework the things I would like to see in a minor revision to

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

> On 6 Jan 2016, at 12:09 AM, chris.d...@gmail.com wrote: > > As someone who writes their WSGI applications as functions that take > `start_response` and `environ` and doesn't bother with much > framework the things I would like to see in a minor revision to WSGI > are: > > * A consistent way to

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

Hi all, Hopefully this discussion won't turn in another useless political discussion :) About the need of a new spec aka WSGI 2 or whatever the name you want to I would say it's definitely needed. But contrary to the others I don't think it has to be that new, or breaking. If you follow closely t

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

On Mon, 4 Jan 2016, Cory Benfield wrote: **TL;DR: What do you believe WSGI 2.0 should and should not do? Should we do it at all?** TL;DR: WSGI itself should have have some light cleanups and bug fixes and have de-facto behaviors formalized and then be blessed as the treasure that it is. A new

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

Hi, On 05/01/2016 13:09, Luke Plant wrote: Just to add my 2c - as another Django developer, I agree completely with Aymeric here. My own experience was that the HTTP handling done by WSGI (especially URL handing, HTTP header mangling, os.environ as a destination - all due to CGI compatibility -

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

Just to add my 2c - as another Django developer, I agree completely with Aymeric here. My own experience was that the HTTP handling done by WSGI (especially URL handing, HTTP header mangling, os.environ as a destination - all due to CGI compatibility - and semi-broken unicode handling) only mad

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

> On 5 Jan 2016, at 10:26 PM, Cory Benfield wrote: > > Forwarding this message from the django-developers list. > > Hi Cory, > > I’m not subscribed to web-sig but I read the discussion there. Feel free to > forward my answer to the group if you think it’s useful. > > I have roughly the same

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

> On 5 Jan 2016, at 10:57 PM, Graham Dumpleton > wrote: > > >> On 5 Jan 2016, at 10:26 PM, Cory Benfield > > wrote: >> >> Forwarding this message from the django-developers list. >> >> Hi Cory, >> >> I’m not subscribed to web-sig but I read the discussion there. Fe

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

Hi, I just want to reply to this because I think many people seem to be missing why things are done in a certain way. Especially if the appear to be odd. On 05/01/2016 12:26, Cory Benfield wrote: 1. WSGI is prone to header injection vulnerabilities issues by designdue to the conversion of H

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

> On 5 Jan 2016, at 8:40 PM, Cory Benfield wrote: > > >> On 5 Jan 2016, at 00:12, Graham Dumpleton > > wrote: >> >> >>> On 4 Jan 2016, at 11:27 PM, Cory Benfield >> > wrote: >>> >>> All, >>> >>> **TL;DR: What do you believe WSGI 2

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

Forwarding this message from the django-developers list. Hi Cory, I’m not subscribed to web-sig but I read the discussion there. Feel free to forward my answer to the group if you think it’s useful. I have roughly the same convictions as Graham Dumpleton. If you want to support HTTP/2 and WebS

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

> On 5 Jan 2016, at 00:12, Graham Dumpleton wrote: > > >> On 4 Jan 2016, at 11:27 PM, Cory Benfield > > wrote: >> >> All, >> >> **TL;DR: What do you believe WSGI 2.0 should and should not do? Should we do >> it at all?** >> >> It’s a new year, and that means it’s t

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

I should also say - thanks for picking this up. I may have been a tad on the grumpy side on my prior mail - new years paging-in-of-everything-after-a-break. -Rob On 5 January 2016 at 01:27, Cory Benfield wrote: > All, > > **TL;DR: What do you believe WSGI 2.0 should and should not do? Should we

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

On Mon, Jan 4, 2016 at 6:22 PM, Robert Collins wrote: > > I think that WSGI got many things right - thats why so many things > support it - but identifying which of its attributes is a factor for > success, and which isn't is really hard: we're a decade on, more or > less, and the ecosystem is a l

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

So, as Graham said, I think calling it 2.0 is a bit of an issue - HTTP/2.0 and WSGI 2.0 are not synonymous, given the diverse requirements we have. On 5 January 2016 at 01:27, Cory Benfield wrote: > All, > > **TL;DR: What do you believe WSGI 2.0 should and should not do? Should we do > it at a

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

> On 4 Jan 2016, at 11:27 PM, Cory Benfield wrote: > > All, > > **TL;DR: What do you believe WSGI 2.0 should and should not do? Should we do > it at all?** > > It’s a new year, and that means it’s time for another attempt to get WSGI 2.0 > off the ground. Many of you may remember that we att

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

Thought I should weigh in on this, as I got mentioned by name in it. Sorry about maybe not getting the threading right, I wasn't subscribed to the list still it sprang from the grave this morning! So, to quote the reply I just sent to Cory in django-developers: I don't think ASGI would be a suit

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

Hi, On 04/01/2016 16:30, Cory Benfield wrote: Your core question seems to be: “why do we need a spec that specifies concurrency?” I think this is reasonable. One way out might be to take the route of ASGI[0], which essentially uses a message broker to act as the interface between server and appl

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

> On 4 Jan 2016, at 15:08, Armin Ronacher wrote: > > I honestly do not think that you can have it both ways: a WSGI specification > and a raw socket. Maybe we reached the point where WSGI should just be > deprecated and frameworks themselves will fill the gap. We would only specify > a data

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

Hi, On 04/01/2016 16:15, Cory Benfield wrote: I don’t believe that will work. Correct. This cannot be done except for very simplistic servers. Regards, Armin ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Un

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

> On 4 Jan 2016, at 14:56, Damjan Georgievski wrote: > **TL;DR: What do you believe WSGI 2.0 should and should not do? Should we do it at all?** >>> … - Support websockets - Support HTTP/2 >>> >>> What does HTTP/2 support mean? What features of HTTP/2 need to be >>> exposed

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

Hi, I personally probably do not want to participate in this discussion much but I want to leave some thoughts in case someone finds them useful. I personally think that fundamentally "concurrent programming" and just getting access to a socket is not something that fits into a generically d

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

>>> **TL;DR: What do you believe WSGI 2.0 should and should not do? Should we >>> do it at all?** >> … >>> - Support websockets >>> - Support HTTP/2 >> >> What does HTTP/2 support mean? What features of HTTP/2 need to be >> exposed in the wsgi api? > > (CC-ing the list) > > The current WSGI API do

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

> On 4 Jan 2016, at 14:48, Damjan Georgievski wrote: > >> **TL;DR: What do you believe WSGI 2.0 should and should not do? Should we do >> it at all?** > … >> - Support websockets >> - Support HTTP/2 > > What does HTTP/2 support mean? What features of HTTP/2 need to be > exposed in the wsgi api

Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

> On 4 Jan 2016, at 12:27, Cory Benfield wrote: > > All, > > **TL;DR: What do you believe WSGI 2.0 should and should not do? Should we do > it at all?** Having set up the conversation, I also want to take part in it. So let me outline what I think we need from WSGI 2. In my opinion, right n

[Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

All, **TL;DR: What do you believe WSGI 2.0 should and should not do? Should we do it at all?** It’s a new year, and that means it’s time for another attempt to get WSGI 2.0 off the ground. Many of you may remember that we attempted to do this last year with Rob Collins leading the charge, but