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

> 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 but that > doesn't make

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

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 extens

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

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 ap

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

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 abo

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

> 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 mean not exposing the raw

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

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 have wsgi.thread I would

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

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 li

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

> 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 > wrote: > > > > > not at all. But I made the assumption that the

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

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 is running . > > > > In any case there is some sor

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

aminus.org From: Web-SIG [web-sig-bounces+fumanchu=aminus@python.org] on behalf of André Malo [n...@perlig.de] Sent: Wednesday, January 20, 2016 3:25 AM To: web-sig@python.org Subject: Re: [Web-SIG] Collating follow-up on the future of WSGI * Cory Benfield wrot

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

> On 20 Jan 2016, at 11:25, André Malo wrote: > > Those APIs are just broken then. The HTTP RFCs state very clearly [1], that > any hop may modify the transfer encoding. In other words: the transfer > encoding is transparent to the representation layer. That’s a good point, and seems like as go

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

> On 20 Jan 2016, at 11:24 PM, André Malo wrote: > > * 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 >>> req

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

* 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 file.read(size)). Something

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

> 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 HTTP/1.1 web server is at liberty to chunk >>>

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

* 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 not sure what is missing. > >

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

> 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 specific concern is the distinction

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

> 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 environ >> dictionary. An alter

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

> 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 is running . >> >> In any case there is some sor

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

> On 20 Jan 2016, at 8:56 AM, Robert Collins wrote: > >> >> Chunked Transfer Encoding >> ~ >> >> It would be nice to formalise chunked transfer encoding in WSGI. Currently >> there is no way to signal to applications that chunked transfer encoding is >> in use by the

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

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 > where the python appl

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

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 useful feedback: when > printed out on my printer

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

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 information that was > reall

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

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, Benoit Chesneau wrote

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

> 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 > > wrote: >> >> I will make a more complete answer soon. B

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

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, server operators were

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

> 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, server operators were unanimously dismissive of the idea > of a socket 'escape hatch'. In general it seems li

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

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, there

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

> 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 immediately with the empty

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

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 information that was really engaging reading. I also want to thank you all for keeping t