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

Re: [Web-SIG] WSGI 2.0

Graham Dumpleton ha scritto: > On 08/10/2007, Manlio Perillo <[EMAIL PROTECTED]> wrote: >> Phillip J. Eby ha scritto: >>> At 01:02 PM 10/8/2007 +0200, Manlio Perillo wrote: Supporting "legacy" and "huge" WSGI applications is not really a priority for me. >>> Then you should really make it

Re: [Web-SIG] WSGI 2.0

On 08/10/2007, Manlio Perillo <[EMAIL PROTECTED]> wrote: > Phillip J. Eby ha scritto: > > At 01:02 PM 10/8/2007 +0200, Manlio Perillo wrote: > >> Supporting "legacy" and "huge" WSGI applications is not really a > >> priority for me. > > > > Then you should really make it clear to your users that yo

Re: [Web-SIG] WSGI 2.0

Phillip J. Eby ha scritto: > At 01:02 PM 10/8/2007 +0200, Manlio Perillo wrote: >> Supporting "legacy" and "huge" WSGI applications is not really a >> priority for me. > > Then you should really make it clear to your users that your Nginx > module does not support WSGI. The entire point of WSGI

Re: [Web-SIG] WSGI 2.0

At 01:02 PM 10/8/2007 +0200, Manlio Perillo wrote: >Supporting "legacy" and "huge" WSGI applications is not really a >priority for me. Then you should really make it clear to your users that your Nginx module does not support WSGI. The entire point of WSGI is to allow "legacy" (i.e. already-wri

Re: [Web-SIG] WSGI 2.0

Ian Bicking ha scritto: > Manlio Perillo wrote: >> Phillip J. Eby ha scritto: >>> At 11:04 AM 10/6/2007 +0200, Manlio Perillo wrote: As an example, the WSGI write callable cannot be implemented in a conforming way in Nginx. >>> ...unless you use a separate thread or process. >>> >> >> I'm

Re: [Web-SIG] WSGI 2.0

Manlio Perillo wrote: > Phillip J. Eby ha scritto: >> At 11:04 AM 10/6/2007 +0200, Manlio Perillo wrote: >>> As an example, the WSGI write callable cannot be implemented in a >>> conforming way in Nginx. >> ...unless you use a separate thread or process. >> > > I'm insisting about asynchronous sup

Re: [Web-SIG] WSGI 2.0

On 07/10/2007, Manlio Perillo <[EMAIL PROTECTED]> wrote: > Graham Dumpleton ha scritto: > > On 07/10/2007, Manlio Perillo <[EMAIL PROTECTED]> wrote: > >> Phillip J. Eby ha scritto: > >>> At 11:04 AM 10/6/2007 +0200, Manlio Perillo wrote: > As an example, the WSGI write callable cannot be imple

Re: [Web-SIG] WSGI 2.0

Phillip J. Eby ha scritto: > At 05:48 PM 10/6/2007 +0200, Manlio Perillo wrote: >> Phillip J. Eby ha scritto: >> > At 11:04 AM 10/6/2007 +0200, Manlio Perillo wrote: >> >> As an example, the WSGI write callable cannot be implemented in a >> >> conforming way in Nginx. >> > >> > ...unless you use a

Re: [Web-SIG] WSGI 2.0

Graham Dumpleton ha scritto: > On 07/10/2007, Manlio Perillo <[EMAIL PROTECTED]> wrote: >> Phillip J. Eby ha scritto: >>> At 11:04 AM 10/6/2007 +0200, Manlio Perillo wrote: As an example, the WSGI write callable cannot be implemented in a conforming way in Nginx. >>> ...unless you use a s

Re: [Web-SIG] WSGI 2.0

On Oct 6, 2007, at 10:33 AM, Robin Bryce wrote: > An async > server should have no problem with synchronous applications that > *dont* use wsgi.input yes ? That's certainly not the case. One of the more popular things to do in a webapp is talk to a database. Most such accesses are done in a b

Re: [Web-SIG] WSGI 2.0

At 05:48 PM 10/6/2007 +0200, Manlio Perillo wrote: >Phillip J. Eby ha scritto: > > At 11:04 AM 10/6/2007 +0200, Manlio Perillo wrote: > >> As an example, the WSGI write callable cannot be implemented in a > >> conforming way in Nginx. > > > > ...unless you use a separate thread or process. > > > >I

Re: [Web-SIG] WSGI 2.0

On 07/10/2007, Manlio Perillo <[EMAIL PROTECTED]> wrote: > Phillip J. Eby ha scritto: > > At 11:04 AM 10/6/2007 +0200, Manlio Perillo wrote: > >> As an example, the WSGI write callable cannot be implemented in a > >> conforming way in Nginx. > > > > ...unless you use a separate thread or process. >

Re: [Web-SIG] WSGI 2.0

Phillip J. Eby ha scritto: > At 11:04 AM 10/6/2007 +0200, Manlio Perillo wrote: >> As an example, the WSGI write callable cannot be implemented in a >> conforming way in Nginx. > > ...unless you use a separate thread or process. > I'm insisting about asynchronous support in WSGI because Nginx *d

Re: [Web-SIG] WSGI 2.0

At 01:34 PM 10/6/2007 +0100, Robin Bryce wrote: >There are plenty of stateless synchronous wsgi components out there >that I would like the option of serving as is. As the person choosing >the components in my wsgi stack I'm perfectly capable of deciding >whether such a synchronous app is safe in t

Re: [Web-SIG] WSGI 2.0

At 11:04 AM 10/6/2007 +0200, Manlio Perillo wrote: >As an example, the WSGI write callable cannot be implemented in a >conforming way in Nginx. ...unless you use a separate thread or process. > > If we were going to try to implement an asynchronous WSGI, what we would > > *really* need to do is

Re: [Web-SIG] WSGI 2.0

On 05/10/2007, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 10:13 PM 10/5/2007 +0100, Robin Bryce wrote: > >That's to much chicken/egg for my tastes. All you are really saying is > >that the CGI model covers the majority of 'common' use cases. I don't > >know of anyone who would disagree with thi

Re: [Web-SIG] WSGI 2.0

Ignore last, over sensitive laptop touch pad :) On 06/10/2007, Manlio Perillo <[EMAIL PROTECTED]> wrote: > Phillip J. Eby ha scritto: > > At 10:13 PM 10/5/2007 +0100, Robin Bryce wrote: > >> That's to much chicken/egg for my tastes. All you are really saying is > >> that the CGI model covers the m

Re: [Web-SIG] WSGI 2.0

On 06/10/2007, Manlio Perillo <[EMAIL PROTECTED]> wrote: > Phillip J. Eby ha scritto: > > At 10:13 PM 10/5/2007 +0100, Robin Bryce wrote: > >> That's to much chicken/egg for my tastes. All you are really saying is > >> that the CGI model covers the majority of 'common' use cases. I don't > >> know

Re: [Web-SIG] WSGI 2.0

Phillip J. Eby ha scritto: > At 10:13 PM 10/5/2007 +0100, Robin Bryce wrote: >> That's to much chicken/egg for my tastes. All you are really saying is >> that the CGI model covers the majority of 'common' use cases. I don't >> know of anyone who would disagree with this. But as things stand all >>

Re: [Web-SIG] WSGI 2.0

At 10:13 PM 10/5/2007 +0100, Robin Bryce wrote: >That's to much chicken/egg for my tastes. All you are really saying is >that the CGI model covers the majority of 'common' use cases. I don't >know of anyone who would disagree with this. But as things stand all >wsgi-ish implementations which aim to

Re: [Web-SIG] WSGI 2.0

On 05/10/2007, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 05:34 PM 10/5/2007 +0100, Robin Bryce wrote: > >Is there a means to support a non blocking read on wsgi.input ? > > No. Some ideas have been proposed, but nobody has shown a practical > scenario where it is useful. > > For it to be usef

Re: [Web-SIG] WSGI 2.0

At 07:38 PM 10/5/2007 +0200, Manlio Perillo wrote: >Phillip J. Eby ha scritto: > > I still don't see how this is *useful*. What will the application *do* > > with this information? > >As an example (not tested) SQLAlchemy can implements a >RequestSingletonPool, that is the equivalend of ThreadSing

Re: [Web-SIG] WSGI 2.0

Phillip J. Eby ha scritto: > At 05:14 PM 10/5/2007 +0200, Manlio Perillo wrote: >> Phillip J. Eby ha scritto: >> > At 12:41 PM 10/5/2007 +0200, Manlio Perillo wrote: >> >> Phillip J. Eby ha scritto: >> >> > In other words, those flags were to support legacy frameworks >> detecting >> >> > that the

Re: [Web-SIG] WSGI 2.0

At 05:34 PM 10/5/2007 +0100, Robin Bryce wrote: >Is there a means to support a non blocking read on wsgi.input ? No. Some ideas have been proposed, but nobody has shown a practical scenario where it is useful. For it to be useful, you would have to have an asynchronous server that is interleav

Re: [Web-SIG] WSGI 2.0

At 05:14 PM 10/5/2007 +0200, Manlio Perillo wrote: >Phillip J. Eby ha scritto: > > At 12:41 PM 10/5/2007 +0200, Manlio Perillo wrote: > >> Phillip J. Eby ha scritto: > >> > In other words, those flags were to support legacy frameworks detecting > >> > that they were in an incompatible hosting envir

Re: [Web-SIG] WSGI 2.0

On 04/10/2007, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 05:54 PM 10/4/2007 +0200, Manlio Perillo wrote: > >Phillip J. Eby ha scritto: > > > At 04:48 PM 10/4/2007 +0200, Manlio Perillo wrote: > > >> Phillip J. Eby ha scritto: > > >> > It's always the case that a WSGI application can be paused

Re: [Web-SIG] WSGI 2.0

Manlio Perillo ha scritto: > Ian Bicking ha scritto: >> [...] >>> Ok, here is more useful definition. >>> >>> If wsgi.asynchronous evaluates to true, then the WSGI application >>> *will* be executed into the server main process cycle and thus the >>> application execution *will* be interleaved (s

Re: [Web-SIG] WSGI 2.0

Ian Bicking ha scritto: > [...] >> Ok, here is more useful definition. >> >> If wsgi.asynchronous evaluates to true, then the WSGI application >> *will* be executed into the server main process cycle and thus the >> application execution *will* be interleaved (since this is the only >> way to su

Re: [Web-SIG] WSGI 2.0

Manlio Perillo wrote: > Phillip J. Eby ha scritto: >> At 12:41 PM 10/5/2007 +0200, Manlio Perillo wrote: >>> Phillip J. Eby ha scritto: In other words, those flags were to support legacy frameworks detecting that they were in an incompatible hosting environment. However, IIUC, there

Re: [Web-SIG] WSGI 2.0

Phillip J. Eby ha scritto: > At 12:41 PM 10/5/2007 +0200, Manlio Perillo wrote: >> Phillip J. Eby ha scritto: >> > In other words, those flags were to support legacy frameworks detecting >> > that they were in an incompatible hosting environment. However, IIUC, >> > there is no such existing frame

Re: [Web-SIG] WSGI 2.0

At 12:41 PM 10/5/2007 +0200, Manlio Perillo wrote: >Phillip J. Eby ha scritto: > > In other words, those flags were to support legacy frameworks detecting > > that they were in an incompatible hosting environment. However, IIUC, > > there is no such existing framework that could meaningfully use t

Re: [Web-SIG] WSGI 2.0

Phillip J. Eby ha scritto: > At 07:53 PM 10/4/2007 +0200, Manlio Perillo wrote: >> Phillip J. Eby ha scritto: >> > At 06:58 PM 10/4/2007 +0200, Manlio Perillo wrote: >> >> But why you are against adding a new environ value (not necessary >> named >> >> wsgi.asynchronous), that will explicitly stat

Re: [Web-SIG] WSGI 2.0

Graham Dumpleton wrote: > On 05/10/2007, Phillip J. Eby <[EMAIL PROTECTED]> wrote: >> At 07:53 PM 10/4/2007 +0200, Manlio Perillo wrote: >>> Phillip J. Eby ha scritto: At 06:58 PM 10/4/2007 +0200, Manlio Perillo wrote: > But why you are against adding a new environ value (not necessary nam

Re: [Web-SIG] WSGI 2.0

On 05/10/2007, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 07:53 PM 10/4/2007 +0200, Manlio Perillo wrote: > >Phillip J. Eby ha scritto: > > > At 06:58 PM 10/4/2007 +0200, Manlio Perillo wrote: > > >> But why you are against adding a new environ value (not necessary named > > >> wsgi.asynchronou

Re: [Web-SIG] WSGI 2.0

At 07:53 PM 10/4/2007 +0200, Manlio Perillo wrote: >Phillip J. Eby ha scritto: > > At 06:58 PM 10/4/2007 +0200, Manlio Perillo wrote: > >> But why you are against adding a new environ value (not necessary named > >> wsgi.asynchronous), that will explicitly state if the WSGI server will > >> interle

Re: [Web-SIG] WSGI 2.0

Phillip J. Eby ha scritto: > At 06:58 PM 10/4/2007 +0200, Manlio Perillo wrote: >> But why you are against adding a new environ value (not necessary named >> wsgi.asynchronous), that will explicitly state if the WSGI server will >> interleave the WSGI application? > > Why do you think it's useful?

Re: [Web-SIG] WSGI 2.0

At 06:58 PM 10/4/2007 +0200, Manlio Perillo wrote: >But why you are against adding a new environ value (not necessary named >wsgi.asynchronous), that will explicitly state if the WSGI server will >interleave the WSGI application? Why do you think it's useful? _

Re: [Web-SIG] WSGI 2.0

Phillip J. Eby ha scritto: > At 06:37 PM 10/4/2007 +0200, Manlio Perillo wrote: >> To make an example (not tested), suppose that a WSGI application keeps a >> global counter (as a thread specific data). >> >> When a new request arrives, the counter is reset to 0, and its value is >> incremented for

Re: [Web-SIG] WSGI 2.0

At 06:37 PM 10/4/2007 +0200, Manlio Perillo wrote: >To make an example (not tested), suppose that a WSGI application keeps a >global counter (as a thread specific data). > >When a new request arrives, the counter is reset to 0, and its value is >incremented for every iteration. > >With all the exis

Re: [Web-SIG] WSGI 2.0

Phillip J. Eby ha scritto: > [...] >> and existing >> WSGI implementations does not interleave the iteration, as far as I know. > > Nothing in the spec stops them from doing so - indeed, they're > *encouraged* to do so: > > http://www.python.org/dev/peps/pep-0333/#middleware-handling-of-block-b

Re: [Web-SIG] WSGI 2.0

At 05:54 PM 10/4/2007 +0200, Manlio Perillo wrote: >Phillip J. Eby ha scritto: > > At 04:48 PM 10/4/2007 +0200, Manlio Perillo wrote: > >> Phillip J. Eby ha scritto: > >> > It's always the case that a WSGI application can be paused after it > >> > yields data, even in WSGI 1.0. > >> > >> I was not

Re: [Web-SIG] WSGI 2.0

Phillip J. Eby ha scritto: > At 04:48 PM 10/4/2007 +0200, Manlio Perillo wrote: >> Phillip J. Eby ha scritto: >> > [...] >> > >> > WSGI 2.0 does not have a start_response() callable in the first place, >> > so none of these apply. >> > >> >> I thought that the current WSGI 2.0 draft was only, indee

Re: [Web-SIG] WSGI 2.0

At 04:48 PM 10/4/2007 +0200, Manlio Perillo wrote: >Phillip J. Eby ha scritto: > > [...] > > > > WSGI 2.0 does not have a start_response() callable in the first place, > > so none of these apply. > > > >I thought that the current WSGI 2.0 draft was only, indeed, a draft. That's correct. But elimi

Re: [Web-SIG] WSGI 2.0

Phillip J. Eby ha scritto: > [...] > > WSGI 2.0 does not have a start_response() callable in the first place, > so none of these apply. > I thought that the current WSGI 2.0 draft was only, indeed, a draft. > > [...] >> 4) the environ dictionary should have a new WSGI-defined variable: >>

Re: [Web-SIG] WSGI 2.0

At 03:47 PM 10/4/2007 +0200, Manlio Perillo wrote: >Ian Bicking ha scritto: > > PJE wants to talk about WSGI 2. That's cool; I remind everyone that > > there's a page to bring up issues you might want to discuss for 2.0: > > http://wsgi.org/wsgi/WSGI_2.0 > > > > Feel free to add to, or discuss, is

Re: [Web-SIG] WSGI 2.0

Ian Bicking ha scritto: > PJE wants to talk about WSGI 2. That's cool; I remind everyone that > there's a page to bring up issues you might want to discuss for 2.0: > http://wsgi.org/wsgi/WSGI_2.0 > > Feel free to add to, or discuss, issues on that page... > I'll write my ideas here: 1) start

[Web-SIG] WSGI 2.0

PJE wants to talk about WSGI 2. That's cool; I remind everyone that there's a page to bring up issues you might want to discuss for 2.0: http://wsgi.org/wsgi/WSGI_2.0 Feel free to add to, or discuss, issues on that page... Ian ___ Web-SIG mailing

Re: [Web-SIG] WSGI 2.0

On 06/04/07, James Y Knight <[EMAIL PROTECTED]> wrote: > > On Apr 5, 2007, at 10:08 PM, Graham Dumpleton wrote: > > FWIW, in mod_wsgi I have now added a directive which allows one to > > enable within a specific context that chunked transfer encoding should > > be used for a response when a HTTP/1.

Re: [Web-SIG] WSGI 2.0

On 07/04/07, Clark C. Evans <[EMAIL PROTECTED]> wrote: > On Fri, Apr 06, 2007 at 12:08:17PM +1000, Graham Dumpleton wrote: > | FWIW, in mod_wsgi I have now added a directive which allows one to > | enable within a specific context that chunked transfer encoding should > | be used for a response whe

Re: [Web-SIG] WSGI 2.0

On Apr 6, 2007, at 2:41 AM, Graham Dumpleton wrote: > Am I take this then that you believe or are proposing that WSGI 2.0 > should require that if no content length is provided in a response and > it can' be calculated, that a WSGI adapter should ensure the web > server uses chunked transfer encodi

Re: [Web-SIG] WSGI 2.0

On Fri, Apr 06, 2007 at 12:08:17PM +1000, Graham Dumpleton wrote: | On 03/04/07, Clark C. Evans <[EMAIL PROTECTED]> wrote: | >On Fri, Mar 30, 2007 at 11:10:17AM +1000, Graham Dumpleton wrote: | >| One other issue if aiming at supporting chunked encoding for a request, | >| is how (if one even can)

Re: [Web-SIG] WSGI 2.0

On 06/04/07, James Y Knight <[EMAIL PROTECTED]> wrote: > > On Apr 5, 2007, at 10:52 PM, Graham Dumpleton wrote: > > > On 06/04/07, James Y Knight <[EMAIL PROTECTED]> wrote: > >> What's the point of a switch? If the app didn't provide a content- > >> length, and you can't otherwise determine a conte

Re: [Web-SIG] WSGI 2.0

On Apr 5, 2007, at 10:52 PM, Graham Dumpleton wrote: > On 06/04/07, James Y Knight <[EMAIL PROTECTED]> wrote: >> What's the point of a switch? If the app didn't provide a content- >> length, and you can't otherwise determine a content-length (because >> for example the result is a simple list of

Re: [Web-SIG] WSGI 2.0

On 06/04/07, James Y Knight <[EMAIL PROTECTED]> wrote: > > On Apr 5, 2007, at 10:08 PM, Graham Dumpleton wrote: > > FWIW, in mod_wsgi I have now added a directive which allows one to > > enable within a specific context that chunked transfer encoding should > > be used for a response when a HTTP/1.

Re: [Web-SIG] WSGI 2.0

On Apr 5, 2007, at 10:08 PM, Graham Dumpleton wrote: > FWIW, in mod_wsgi I have now added a directive which allows one to > enable within a specific context that chunked transfer encoding should > be used for a response when a HTTP/1.1 client is being used. Thus, if > you know the content generate

Re: [Web-SIG] WSGI 2.0

On 03/04/07, Clark C. Evans <[EMAIL PROTECTED]> wrote: > On Fri, Mar 30, 2007 at 11:10:17AM +1000, Graham Dumpleton wrote: > | One other issue if aiming at supporting chunked encoding for a request, > | is how (if one even can) make available the trailing headers if present > | after the final null

  1   2   >