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

On Sun, Jan 31, 2016 at 8:57 PM, Andrew Godwin wrote: > The idea of a standardised protocol escape is indeed interesting, though I'm > not so keen on the idea of making triply nested functions a requirement for > something like this. It's not a requirement; the exact

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

On Thu, Jan 21, 2016 at 12:12 AM, Benoit Chesneau wrote: > 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

Re: [Web-SIG] Draft 2: WSGI Response Upgrade Bridging

On Sun, Oct 12, 2014 at 6:47 PM, Robert Collins robe...@robertcollins.net wrote: FWIW I'm totally fine with you bringing together that PEP - as you say its complementary to what I'm focused on (I believe I even suggested you might want to do that). Did you have any feedback on the proposal

Re: [Web-SIG] Draft 2: WSGI Response Upgrade Bridging

On Fri, Oct 10, 2014 at 8:56 AM, Graham Dumpleton graham.dumple...@gmail.com wrote: So PJE, please step back and do not go rushing out to create a PEP. That is the worst thing you could do at this point and will only serve to deter people from the community contributing and so stifle proper

[Web-SIG] Draft 2: WSGI Response Upgrade Bridging

Based on last week's public and private feedback on my native server APIs pre-PEP, I've done an almost complete rewrite of the previous draft, in order to provide *concrete examples* of the proposal in use, along with code samples for Django and WebOb, as well as both HTTP/2 and Websockets. The

Re: [Web-SIG] Pre-PEP: The WSGI Middleware Escape for Native Server APIs

On Tue, Sep 30, 2014 at 3:40 AM, Roberto De Ioris robe...@unbit.it wrote: While i totally like your proposal, i fear it will not solve one of the biggest problems without another layer: Of course. An escape to a native API isn't much use without the native APIs. ;-) currently (and i speak

Re: [Web-SIG] Pre-PEP: The WSGI Middleware Escape for Native Server APIs

On Tue, Sep 30, 2014 at 4:09 AM, Cory Benfield c...@lukasa.co.uk wrote: This was exactly the concern I was about to articulate. Having a standard way to 'escape' WSGI is great, but what it does is force us down a road where any application that wants to use HTTP/2 or WebSockets picks one

Re: [Web-SIG] Pre-PEP: The WSGI Middleware Escape for Native Server APIs

On Tue, Sep 30, 2014 at 5:03 AM, Sylvain Hellegouarch s...@defuze.org wrote: Hi, 2014-09-30 1:19 GMT+02:00 PJ Eby p...@telecommunity.com: * Web servers can expose their native API to any WSGI application or framework It's kind of already the case with all the existing servers. They all

Re: [Web-SIG] WSGI2: write callable?

On Sun, Sep 28, 2014 at 10:09 PM, Robert Collins robe...@robertcollins.net wrote: On 29 September 2014 08:32, PJ Eby p...@telecommunity.com wrote: On Sat, Sep 27, 2014 at 5:38 PM, Robert Collins robe...@robertcollins.net wrote: I think we're uncovering important assumptions / facts here

[Web-SIG] Pre-PEP: The WSGI Middleware Escape for Native Server APIs

Per the previous discussion about HTTP/2, websockets, et al, here's my attempt at providing something we can start using and implementing today, as a bridge to future specifications. If you'd prefer to read it nicely formatted, you can find an HTML version in progress at:

Re: [Web-SIG] WSGI2: write callable?

On Sat, Sep 27, 2014 at 5:38 PM, Robert Collins robe...@robertcollins.net wrote: I think we're uncovering important assumptions / facts here. Indeed! For clarity: I'm not interested in a nice API for HTTP/2. I want HTTP/2 and its full featureset to be *possible*, *efficient* and *clear* in

Re: [Web-SIG] WSGI2: write callable?

On Sat, Sep 27, 2014 at 2:55 PM, PJ Eby p...@telecommunity.com wrote: On Sat, Sep 27, 2014 at 12:20 AM, Robert Collins robe...@robertcollins.net wrote: Right now, anything providing the server profile has to cope with exceptions and translate those to 500 errors, so we have the variation

Re: [Web-SIG] WSGI2: write callable?

On Fri, Sep 26, 2014 at 5:02 PM, Robert Collins robe...@robertcollins.net wrote: But perhaps it would be nicer to say: iterator of headers_dict_or_body_bytes With the first item yielded having to be headers (or error thrown),and the last item yielded may be a dict to emit trailers. So: def

Re: [Web-SIG] WSGI2: write callable?

On Fri, Sep 26, 2014 at 7:41 PM, Robert Collins robe...@robertcollins.net wrote: One thing we could do with the status code in the headers dict is to default to 200 - the vastly common case (in the same way that throwing an error generates a 500). Then status wouldn't be required at all for

Re: [Web-SIG] [python-tulip] Re: [Python-Dev] wsgi validator with asynchronous handlers/servers

On Sat, Apr 27, 2013 at 1:24 AM, Graham Dumpleton graham.dumple...@gmail.com wrote: I described a different way of doing WSGI which would better cope with post response hooks at the Python Web Summit at PyCon in 2012. It made use of the context manager abstraction so it wouldn't screw with the

Re: [Web-SIG] [Python-Dev] wsgi validator with asynchronous handlers/servers

On Sat, Mar 23, 2013 at 7:30 PM, Luca Sbardella luca.sbarde...@gmail.com wrote: PJ Eby wrote: The validator is correct for the spec. You *must* call start_response() before yielding any strings at all. Thanks for response PJ, that is what I, unfortunately, didn't want to hear, the validator

Re: [Web-SIG] websocket support in WSGI

On Wed, May 23, 2012 at 3:17 PM, Roberto De Ioris robe...@unbit.it wrote: Can't we simply define something like environ['wsgi.raw_socket'] (or whatever name you want) mapping to the client (or webserver in case of proxied) socket ? Probably not. What happens if middleware has already sent

Re: [Web-SIG] A more useful command-line wsgiref.simple_server?

On Fri, Mar 30, 2012 at 11:57 PM, Graham Dumpleton graham.dumple...@gmail.com wrote: On 31 March 2012 14:36, PJ Eby p...@telecommunity.com wrote: Why give them a __name__ at all? Aren't they scripts, rather than modules? ISTM that not having a __name__ would also let things like pickles

Re: [Web-SIG] A more useful command-line wsgiref.simple_server?

On Fri, Mar 30, 2012 at 2:22 PM, Sasha Hart s...@sashahart.net wrote: I do really like the idea of having a quick WSGI runner in the stdlib, What's kind of funny is that this was actually one of the original use cases that resulted in the invention of WSGI; back in the early 2000's, PEAK had

Re: [Web-SIG] A more useful command-line wsgiref.simple_server?

On Thu, Mar 29, 2012 at 4:16 PM, Sasha Hart s...@sashahart.net wrote: If the colon can be made safe for Windows it might be desirable, since it looks fine and reflects existing practice in a number of places. For *modules*, yes. For scripts, no. But for module names, there's no conflict.

Re: [Web-SIG] A 'shutdown' function in WSGI

The standard way to do this would be to define an optional server extension API supplied in the environ; for example, a 'x-wsgiorg.register_shutdown' function. The wsgi.org wiki used to be the place to propose these sorts of things for standardization, but it appears to no longer be a wiki, so

Re: [Web-SIG] A 'shutdown' function in WSGI

2012/2/20 Chris McDonough chr...@plope.com On Mon, 2012-02-20 at 17:39 -0500, PJ Eby wrote: The standard way to do this would be to define an optional server extension API supplied in the environ; for example, a 'x-wsgiorg.register_shutdown' function. Unlikely, AFACIT, as shutdown may