Re: [Web-SIG] Collating follow-up on the future of WSGI

2016-01-21 Thread Cory Benfield
> On 21 Jan 2016, at 06:39, Benoit Chesneau wrote: > > because i am not speaking about making a specification, but a way to expose > in the API (environ) custom extensions that a server want to experiment. > there are actually no easy way except checking "wsgi." indeed

Re: [Web-SIG] Collating follow-up on the future of WSGI

2016-01-20 Thread Benoit Chesneau
I am not speaking about websockets. You could use it for SSE, or some apps could use the Upgrade header to upgrade from http to their own protocol etc... The only discussion i saw about websockets are about the addition of an async api or an external api. I am not describing that. I am speaking

Re: [Web-SIG] Collating follow-up on the future of WSGI

2016-01-20 Thread Graham Dumpleton
I am still confused as to why you keep talking as if you seemingly are trying to force extensions to the existing WSGI specification into the core WSGI specification when an alternative has already been cited. Extensions and the process for describing them and getting them accepted, plus the

Re: [Web-SIG] Collating follow-up on the future of WSGI

2016-01-20 Thread Benoit Chesneau
because i am not speaking about making a specification, but a way to expose in the API (environ) custom extensions that a server want to experiment. there are actually no easy way except checking "wsgi." indeed but that doesn't make it as clear as a separate namespace where to put all server

Re: [Web-SIG] Collating follow-up on the future of WSGI

2016-01-20 Thread Benoit Chesneau
On Wed, Jan 20, 2016 at 1:57 AM Robert Collins wrote: > On 20 January 2016 at 12:04, Benoit Chesneau wrote: > > > > > not at all. But I made the assumption that the wsgi server maintained a > > thread directly or not where the python application

Re: [Web-SIG] Collating follow-up on the future of WSGI

2016-01-20 Thread Graham Dumpleton
> On 21 Jan 2016, at 2:48 AM, Benoit Chesneau wrote: > > > > On Wed, Jan 20, 2016 at 1:57 AM Robert Collins > wrote: > On 20 January 2016 at 12:04, Benoit Chesneau

Re: [Web-SIG] Collating follow-up on the future of WSGI

2016-01-20 Thread Robert Collins
On 21 January 2016 at 11:27, Benoit Chesneau wrote: > again. any server can do such implementation if we create a new Resource > abstraction. This abstraction would expose a common api to read and write. > The implementation would be specific to the server. > > Now like we

Re: [Web-SIG] Collating follow-up on the future of WSGI

2016-01-20 Thread Benoit Chesneau
again. any server can do such implementation if we create a new Resource abstraction. This abstraction would expose a common api to read and write. The implementation would be specific to the server. Now like we have wsgi.thread I would instead suggest to add a system of capability or extension

Re: [Web-SIG] Collating follow-up on the future of WSGI

2016-01-20 Thread Graham Dumpleton
> On 21 Jan 2016, at 9:27 AM, Benoit Chesneau wrote: > > again. any server can do such implementation if we create a new Resource > abstraction. This abstraction would expose a common api to read and write. > The implementation would be specific to the server. If you

Re: [Web-SIG] Collating follow-up on the future of WSGI

2016-01-20 Thread Cory Benfield
> On 20 Jan 2016, at 06:04, Graham Dumpleton wrote: > > For response content, if a WSGI application currently doesn’t set a > Content-Length on response, A HTTP/1.1 web server is at liberty to chunk the > response. > > So I am not sure what is missing. My

Re: [Web-SIG] Collating follow-up on the future of WSGI

2016-01-20 Thread André Malo
* Cory Benfield wrote: > > On 20 Jan 2016, at 06:04, Graham Dumpleton > > wrote: > > > > For response content, if a WSGI application currently doesn’t set a > > Content-Length on response, A HTTP/1.1 web server is at liberty to chunk > > the response. > > > > So I am

Re: [Web-SIG] Collating follow-up on the future of WSGI

2016-01-20 Thread Graham Dumpleton
> On 20 Jan 2016, at 10:25 PM, André Malo wrote: > > * Cory Benfield wrote: > >>> On 20 Jan 2016, at 06:04, Graham Dumpleton >>> wrote: >>> >>> For response content, if a WSGI application currently doesn’t set a >>> Content-Length on response, A

Re: [Web-SIG] Collating follow-up on the future of WSGI

2016-01-20 Thread André Malo
* Graham Dumpleton wrote: > > On 20 Jan 2016, at 10:25 PM, André Malo wrote: > > Regarding chunked requests - in my own WSGI implementation I went the > > most pragmatic way and simply provided a CONTENT_LENGTH of -1 for unknown > > request sizes (it maps very well to

Re: [Web-SIG] Collating follow-up on the future of WSGI

2016-01-19 Thread Graham Dumpleton
> On 20 Jan 2016, at 8:29 AM, Benoit Chesneau wrote: > > > > On Tue, Jan 19, 2016 at 10:49 PM Graham Dumpleton > wrote: > >> On 20 Jan 2016, at 7:43 AM, Benoit Chesneau >

Re: [Web-SIG] Collating follow-up on the future of WSGI

2016-01-19 Thread Benoit Chesneau
On Tue, Jan 19, 2016 at 11:58 PM Robert Collins wrote: > On 20 January 2016 at 05:55, Cory Benfield wrote: > > All, > > > > Thanks so much for your feedback to my original request for comments on > the future of WSGI. You provided a ton of really

Re: [Web-SIG] Collating follow-up on the future of WSGI

2016-01-19 Thread Graham Dumpleton
> On 20 Jan 2016, at 2:55 AM, Cory Benfield wrote: > > Content Lengths > ~~~ > > We should clarify in the new specification that an application that reads > beyond the logical length of the request as given by CONTENT_LENGTH will have > its reads return

Re: [Web-SIG] Collating follow-up on the future of WSGI

2016-01-19 Thread Benoit Chesneau
On Tue, Jan 19, 2016 at 11:34 PM Graham Dumpleton < graham.dumple...@gmail.com> wrote: > > On 20 Jan 2016, at 8:29 AM, Benoit Chesneau wrote: > > > > On Tue, Jan 19, 2016 at 10:49 PM Graham Dumpleton < > graham.dumple...@gmail.com> wrote: > >> >> On 20 Jan 2016, at 7:43 AM,

Re: [Web-SIG] Collating follow-up on the future of WSGI

2016-01-19 Thread Robert Collins
On 20 January 2016 at 05:55, Cory Benfield wrote: > All, > > Thanks so much for your feedback to my original request for comments on the > future of WSGI. You provided a ton of really useful feedback: when printed > out on my printer it ended up at about 50 pages of

Re: [Web-SIG] Collating follow-up on the future of WSGI

2016-01-19 Thread Benoit Chesneau
On Tue, Jan 19, 2016 at 10:49 PM Graham Dumpleton < graham.dumple...@gmail.com> wrote: > > On 20 Jan 2016, at 7:43 AM, Benoit Chesneau wrote: > > I will make a more complete answer soon. But about: > > >> >> Socket Escape Hatch >> ~~~ >> >> Aside from Benoit,

Re: [Web-SIG] Collating follow-up on the future of WSGI

2016-01-19 Thread Benoit Chesneau
I will make a more complete answer soon. But about: > > Socket Escape Hatch > ~~~ > > Aside from Benoit, server operators were unanimously dismissive of the > idea of a socket 'escape hatch'. In general it seems like servers would not > be capable of achieving this. I think,

Re: [Web-SIG] Collating follow-up on the future of WSGI

2016-01-19 Thread Robert Collins
On 20 January 2016 at 12:04, Benoit Chesneau wrote: > > not at all. But I made the assumption that the wsgi server maintained a > thread directly or not where the python application is running . > > In any case there is some sort of wrapping done in the same thread/process >

Re: [Web-SIG] Collating follow-up on the future of WSGI

2016-01-19 Thread Graham Dumpleton
> On 20 Jan 2016, at 8:56 AM, Robert Collins wrote: > >> REQUEST_URI environ variable >> >> >> Multiple contributors expressed an interest in bringing this environment >> variable into WSGI directly, making it a required part of the

Re: [Web-SIG] Collating follow-up on the future of WSGI

2016-01-19 Thread Graham Dumpleton
> On 20 Jan 2016, at 10:57 AM, Robert Collins wrote: > > On 20 January 2016 at 12:04, Benoit Chesneau wrote: > >> >> not at all. But I made the assumption that the wsgi server maintained a >> thread directly or not where the python application