From cory at lukasa.co.uk Mon Jan 4 07:27:18 2016 From: cory at lukasa.co.uk (Cory Benfield) Date: Mon, 4 Jan 2016 12:27:18 +0000 Subject: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest Message-ID: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> 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 unfortunately personal commitments made it impossible for Rob to keep pushing that attempt forward. Since then, the need for a revision of WSGI has become even more apparent. Casual discussion on the web has indicated that application developers are uncomfortable with the limitations of WSGI. These limitations are providing an incentive for both application developers and server developers to take an end-run around WSGI in an attempt to get a framework that is more suitable for the modern web. A great example of the result of WSGI?s deficiencies is Andrew Godwin?s channels work[0] for Django, which represents a paradigm shift in application development that takes it far away from what WSGI is today. For this reason, I think we need to try again to get WSGI 2.0 off the ground. But I don?t believe we can do this without getting broad consensus from the developer community that a revision to WSGI is needed, and without understanding what developers need from a new revision of WSGI. This should take into account the prior discussions we?d had on this thread: however, I?m also going to actively solicit feedback from some of the more notable WSGI implementers, to ensure that whatever comes out of this SIG is something that they would actually use. This WG already had a list of requirements, which are as follows: - Support servers speaking HTTP/1.x, HTTP/2 and Websockets (potentially all on a single port). - Support graceful degradation for applications that can use HTTP/2 but still support HTTP/1.x requests. - Graceful incremental adoption path - no upgrade-all-components requirement baked into the design. - Support Python 2.7 and 3.x (where x is not yet discussed) - Support the existing ecosystem of containers (such as mod_wsgi) with the new API. We want a clean, fast and approachable API, and we want to ensure that its no less friendly to work with than WSGI, for all that it will expose much more functionality. - Apps need to be able to tell what protocol is in use, and what optional features are available. For instance, HTTP/2 PUSH PROMISE is an optional feature that can be disabled by clients. Websockets needs to expose a socket like object, and so on. - Support websockets - Support HTTP/2 - Support HTTP/1.x (which may be just 'point at PEP-3333?.) - Continue to support lightweight shims being built on top such as https://github.com/Pylons/webob/blob/master/webob/request.py I believe that all of these requirements are up for grabs, and subject to change and consensus discussion. In this thread, then, I?d like to hear from people about these requirements and others. What do you believe WSGI 2.0 should do? Just as importantly, what do you believe it should not do? What prior art should we take into account? Should we bother revising WSGI at all, or should we let the wider application ecosystem pursue its own solutions ? la Django's channels? Should we simply adopt Andrew Godwin?s ASGI draft[1] on which channels is based and call *that* WSGI 2.0? Right now I want this to be very open. I?d like people to come up with a broad statement listing what they believe should and should not be present in WSGI. This first stage of the work is very general: I just want to get a feeling for what the community believes is important. Once we?re done with that, if the consensus is that this work is worth pursuing, I?ll come up with an initial draft that we can start making concrete changes to. In the short term, I?m going to keep this consultation open for **at least two weeks**: that is, I will not start working on an initial draft PEP until at least the **18th of January**. If you believe there are application or server developers that should be involved in this discussion, please reach out to them and point them to this list. I personally have CC?d some people that I believe need to be involved in the discussion, but please reach out to others as well. I?d really love to come to the end of 2016 with a solid direction for the future of web programming in Python. I?m looking forward to working with you all on achieving that. Thanks, Cory [0]: https://channels.readthedocs.org/en/latest/ [1]: https://channels.readthedocs.org/en/latest/asgi.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From cory at lukasa.co.uk Mon Jan 4 09:36:26 2016 From: cory at lukasa.co.uk (Cory Benfield) Date: Mon, 4 Jan 2016 14:36:26 +0000 Subject: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest In-Reply-To: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> References: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> Message-ID: <51E5E83F-235B-4845-B6F7-4D909555D8F3@lukasa.co.uk> > 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 now WSGI suffers from the following problems: 1. No out-of-the-box support for the concurrent programming techniques that are becoming extremely popular in the Python community and that should be encouraged. 2. No support for WebSockets, HTTP/2 server push, or any kind of generalised ?extension? to the HTTP/1.1 request-response model. 3. A lack of an ?escape hatch? that allows an application to take responsibility for a connection from the server, thereby ensuring that servers WSGI servers are the bottleneck for innovative and unusual programming techniques. 4. A confused bytes/unicode model that makes it mandatory to mix bytes and unicode in confusing ways at different parts of the stack. 5. A backward-looking design that favours applications doing in-memory buffering of responses over flushing response data to disk as it becomes available. For this reason, my ideal WSGI 2.0 would be a relatively minor revision of PEP 3333, focusing on addressing these core concerns. PEP 3333 actually contains a great deal of what we already need, but either does not make it mandatory or fails to provide examples of how the tools can be used to solve the problem. Problem (4) is easily resolved by coming to a consensus position on what fields should be byte strings, what ones should be unicode strings, and then very clearly setting out the rules for handling each side of that interaction. I?d like to remove the `write` callable and instead **require** that the return value from the application callable be an iterable that produces the body. This should help encourage applications to use generators (or coroutines, as discussed later) to iteratively generate their output. This should help with problem (5) because it will allow us to propagate backpressure through a WSGI server to its application, based on how swiftly the server is able to flush data to the network. Problem (2) is not actually entirely true: uWSGI has demonstrated that it?s entirely possible to extend WSGI to handle websockets, and such a model could presumably also be used for HTTP/2 server push. I?d like to take the approach of essentially creating ?blessed? extensions for websockets and HTTP/2 server push that tie in with the requirement for concurrency in problem (1). These will serve double duty, firstly ensuring that there?s a widely applicable general approach to supporting these features, while also providing a useful example of how WSGI 2 can be extended to support similar HTTP protocol extensions in future. Fixing problem (3) seems useful to me, but I definitely need feedback from server implementers to see how they feel about becoming essentially dumb TCP proxies for applications in some scenarios. Fixing problem (1) is the hardest, and for that reason I?ve reached out to a few Python concurrency experts. The best idea I have right now is based on trying to standardise on the ?awaitable? type and the ?async for? logic from PEP 492 to base WSGI 2 on asynchronous iterators. Essentially, the WSGI 2 callable would return a PEP 493 asynchronous iterable. I have some concerns about this approach, however. Firstly, I?m nervous about how well this works when called from C (e.g. for servers like uWSGI). Secondly, I want to make sure that it continues to function well with other event loop implementations (e.g. Twisted). For that reason, I?m open to alternative suggestions here. However, I do believe we need to support Python applications running concurrently in an event loop (e.g. asyncio-based or Twisted-based). I have one further thing that I believe is important: I believe we need to support Python 2.7. It?s my sincere belief that if WSGI 2 is Python 3 only, we will struggle to get anyone to implement it: both servers and application frameworks will wait for people to take up Python 3 before implementing it, and users will not take up Python 3 until servers and application frameworks support WSGI 2. What do people think of these goals? Cory -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From cory at lukasa.co.uk Mon Jan 4 09:53:14 2016 From: cory at lukasa.co.uk (Cory Benfield) Date: Mon, 4 Jan 2016 14:53:14 +0000 Subject: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest In-Reply-To: References: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> Message-ID: <7EACFF1A-A30D-4CB3-A68E-8A874F8FEC60@lukasa.co.uk> > 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? (CC-ing the list) The current WSGI API does not provide any consensus method for doing server push. Such a thing could absolutely be done as an extension to WSGI in its current form, and we should consider that. More generally, HTTP/2 is a bit more generous with what can be done with a stream than is the case in HTTP/1.1. For example, a stream could in principle be kept open indefinitely and used as a bi-directional communications channel: WSGI in its current form does not make that easy to do. Cory -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From gdamjan at gmail.com Mon Jan 4 09:56:08 2016 From: gdamjan at gmail.com (Damjan Georgievski) Date: Mon, 4 Jan 2016 15:56:08 +0100 Subject: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest In-Reply-To: <7EACFF1A-A30D-4CB3-A68E-8A874F8FEC60@lukasa.co.uk> References: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> <7EACFF1A-A30D-4CB3-A68E-8A874F8FEC60@lukasa.co.uk> Message-ID: >>> **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 does not provide any consensus method for doing server push. Such a thing could absolutely be done as an extension to WSGI in its current form, and we should consider that. > > More generally, HTTP/2 is a bit more generous with what can be done with a stream than is the case in HTTP/1.1. For example, a stream could in principle be kept open indefinitely and used as a bi-directional communications channel: WSGI in its current form does not make that easy to do. > So will a general solution for both HTTP/2 and Websockets be exposing the underlaying socket as an 'wsgi.fd' environment variable? -- damjan From armin.ronacher at active-4.com Mon Jan 4 10:08:02 2016 From: armin.ronacher at active-4.com (Armin Ronacher) Date: Mon, 4 Jan 2016 16:08:02 +0100 Subject: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest In-Reply-To: <51E5E83F-235B-4845-B6F7-4D909555D8F3@lukasa.co.uk> References: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> <51E5E83F-235B-4845-B6F7-4D909555D8F3@lukasa.co.uk> Message-ID: <568A8AD2.6010804@active-4.com> 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 deployable container specification which is what WSGI largely is. WSGI was quite trivially specified as what happens from request to response and even in that area it already suffered from significant limitations in regards to where the specification did not consider what servers would do with it. I do not want to go into detail too much but WSGI the spec never really concerned itself with the vast complexity that is HTTP in practice (chunked requests, transfer encodings, stream termination signalling etc.) I heavily doubt that dragging concurrency into the spec will make it any less problematic for real world situations. Why do we need concurrency on the spec level? I honestly do not see the point because in practical terms we might just make a spec that then cannot really be deployed in practice just because nobody would want to. Making a server that gracefully shuts down when things are purely request/response is already tricky enough, but finding a method to shut down a server with active stream connections is something that does not even have enough agreement between implementations yet (which also needs a lot of client support) that I don't think will fit into a specification. 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 exchange layer so that frameworks can interoperate in some way or another. Regards, Armin From cory at lukasa.co.uk Mon Jan 4 10:15:40 2016 From: cory at lukasa.co.uk (Cory Benfield) Date: Mon, 4 Jan 2016 15:15:40 +0000 Subject: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest In-Reply-To: References: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> <7EACFF1A-A30D-4CB3-A68E-8A874F8FEC60@lukasa.co.uk> Message-ID: <2C44E671-BDD5-4CF1-8A2C-CBE31396DA5A@lukasa.co.uk> > 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 in the wsgi api? >> >> (CC-ing the list) >> >> The current WSGI API does not provide any consensus method for doing server push. Such a thing could absolutely be done as an extension to WSGI in its current form, and we should consider that. >> >> More generally, HTTP/2 is a bit more generous with what can be done with a stream than is the case in HTTP/1.1. For example, a stream could in principle be kept open indefinitely and used as a bi-directional communications channel: WSGI in its current form does not make that easy to do. >> > > So will a general solution for both HTTP/2 and Websockets be exposing > the underlaying socket as an 'wsgi.fd' environment variable? I don?t believe that will work. Both HTTP/2 and Websockets have framing logic, and HTTP/2 also has a moderately-complex connection-level state machine that makes passing off the FD to an application a fraught endeavour. I suspect in both cases they will be best handled by having a extension protocol that allows the protocol-specific logic to function sensibly. In both cases, standard Python generators used as coroutines would be totally suitable, with concurrency being the only fly in the ointment to getting this right. Cory -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From armin.ronacher at active-4.com Mon Jan 4 10:16:47 2016 From: armin.ronacher at active-4.com (Armin Ronacher) Date: Mon, 4 Jan 2016 16:16:47 +0100 Subject: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest In-Reply-To: <2C44E671-BDD5-4CF1-8A2C-CBE31396DA5A@lukasa.co.uk> References: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> <7EACFF1A-A30D-4CB3-A68E-8A874F8FEC60@lukasa.co.uk> <2C44E671-BDD5-4CF1-8A2C-CBE31396DA5A@lukasa.co.uk> Message-ID: <568A8CDF.6080908@active-4.com> 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 From cory at lukasa.co.uk Mon Jan 4 10:30:31 2016 From: cory at lukasa.co.uk (Cory Benfield) Date: Mon, 4 Jan 2016 15:30:31 +0000 Subject: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest In-Reply-To: <568A8AD2.6010804@active-4.com> References: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> <51E5E83F-235B-4845-B6F7-4D909555D8F3@lukasa.co.uk> <568A8AD2.6010804@active-4.com> Message-ID: <84650D48-D2C5-431B-9CD5-6CFF5BA7C7C6@lukasa.co.uk> > 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 exchange layer so that frameworks can interoperate in some way or another. This is one of the bits of feedback I expected we?d get, and it?s one we really do need to consider. It?s possible that the time for WSGI is coming to a close. However, I?d like to try not to give up as a first step. =) 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 application. This lets applications handle their own concurrency without needing to co-ordinate with the server. From there the spec doesn?t need to handle concurrency, as the application and server are in separate processes. However, if the application and server run together (as with WSGI today), I don?t think we can get out of needing to talk about concurrency, because *not* talking about it essentially forces the application to assume that each request/response cycle runs in a new process and that it cannot share memory or resources. That?s what we have at the moment, and using something like asyncio or Twisted in such an environment is very tricky and essentially requires that you run on top a server that also uses them (see Hendrix or Klein). Let?s step back for a moment and consider the most simple case: one request, one response, both sent across WSGI as a complete entity. Could we not specify that the application callable has to return an object that is analogous to a future/promise/Deferred: essentially, an object that can be waited on until the response is ready. In that situation, a WSGI server could repeatedly call the application callable and then wait until any of the future/promise/Deferreds is ready, then send that data back in the response. This would allow the application to use its own concurrency model. Setting aside whether it?s a good model (it?s not), do you agree that it would work? If it would, I think it?s reasonable to consider whether we can come up with a different, sufficiently-general approach to this problem, potentially based on that kind of approach. Cory [0]: https://channels.readthedocs.org/en/latest/asgi.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From armin.ronacher at active-4.com Mon Jan 4 10:36:04 2016 From: armin.ronacher at active-4.com (Armin Ronacher) Date: Mon, 4 Jan 2016 16:36:04 +0100 Subject: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest In-Reply-To: <84650D48-D2C5-431B-9CD5-6CFF5BA7C7C6@lukasa.co.uk> References: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> <51E5E83F-235B-4845-B6F7-4D909555D8F3@lukasa.co.uk> <568A8AD2.6010804@active-4.com> <84650D48-D2C5-431B-9CD5-6CFF5BA7C7C6@lukasa.co.uk> Message-ID: <568A9164.4060808@active-4.com> 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 application. This lets > applications handle their own concurrency without needing to > co-ordinate with the server. From there the spec doesn?t need to > handle concurrency, as the application and server are in separate > processes. I think the *only* way to scale websockets is to use an RPC system to dispatch commands and to handle fan out somewhere centralized. This for instance works really well with redis as a broker. All larger deployments of websockets I have worked with so far involved a simple redis to websocket server that barely restarts and dispatches commands (and receives messages) via redis. That's a simple an straightforward way that still keeps deployments work well because you never restart the actual connections unless you need to pull a cable or you have a bug in the websocket server. That's why I'm personally also not really interested in this topic as for large scale deployments this is not really an issue and for toy applications I do not use websockets ;) Regards, Armin From andrew at aeracode.org Mon Jan 4 12:44:07 2016 From: andrew at aeracode.org (Andrew Godwin) Date: Mon, 4 Jan 2016 09:44:07 -0800 Subject: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest Message-ID: 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 suitable replacement for WSGI in the current form; in particular, I suspect it will have a performance disadvantage, though I've not quantified yet. That said, if Django Channels does become the primary method for communication with web clients, the only thing we would want out of WSGI 2 would be something that could easily plug into ASGI - that is, something that supports WebSockets, can handle simultaneous connections with many clients in the same thread via cooperative multitasking or similar, and allows raw access to sockets. Given those things, an ASGI HTTP/WebSocket protocol server could simply be a WSGI 2 application, allowing much better code reuse. In particular, ASGI is never going to be low-level enough for people who want to do crazy things; there's no access to input and output socket streams, for starters. While I've tried to maintain some of the WSGI familiarity, the whole thing is one step higher a level of abstraction, and with that brings inflexibility and slight performance decreases that I suspect people will get mad about if it becomes WSGI 2. Now, I do think that the majority of web frameworks out there right now could be ported to ASGI in no time at all; the asgiref package I'm working on will ship with an ASGI-to-WSGI wrapper that just makes that work, as long as the WSGI application doesn't try and be too clever with output I don't want to express an opinion on if this means WSGI 2 is unnecessary since I'm pretty biased; we need _some_ sort of standard that covers WebSockets going forward, or we have the uwsgi problem where everyone invents their own API for it. My wishlist, though, is basically: - WebSocket support - Concurrent client handling support - WebSockets and HTTP mixed-mode (i.e. on the same port and URLs) - Fix the bytes/unicode issue that's all over the place in the current spec These would all work super well in making ASGI itself pluggable into WSGI 2. HTTP/2 features also need some place (like server push), and there's other things cropping up like WebRTC that we might need to eventually support. This is one of the reasons ASGI separates transport from protocol encoding; I know people will invent new crazy web stuff in the next few years, and I wanted a pattern that could extend to support most protocol types without changing the abstraction completely. Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From graham.dumpleton at gmail.com Mon Jan 4 19:12:39 2016 From: graham.dumpleton at gmail.com (Graham Dumpleton) Date: Tue, 5 Jan 2016 11:12:39 +1100 Subject: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest In-Reply-To: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> References: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> Message-ID: > 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 attempted to do this last year with Rob Collins leading the charge, but unfortunately personal commitments made it impossible for Rob to keep pushing that attempt forward. Although you call this round 2, it isn?t really. Robert?s effort was not the first time someone has pushed a WSGI 2.0 variant. So this is more like being about round 5 or 6. In part because of those repeated attempts by people to propose something and label it as WSGI 2.0, I am very cool on reusing the WSGI 2.0 moniker. You will find little or no mention of ?WSGI 2.0? as a label in: https://github.com/python-web-sig/wsgi-ng That is probably somewhat due to my grumbling about the use of ?WSGI 2.0? back then. Time has moved on and so the bad feelings and memories associated with the ?WSGI 2.0? label due to early failed efforts have faded, but I would still suggest avoiding the label ?WSGI 2.0? if at all possible. My general feeling is that if any proposed changes to the existing WSGI (PEP 3333) specification cannot be technically implemented on all existing WSGI server/adapter implementations that any new specification should not still be called WSGI. In other words, even if many of these implementations may not be used much any more, it must be able to work, without needing to mark things as optional, on CGI, FASTCGI, SCGI, mod_wsgi, gunicorn, uWSGI, Waitress, etc etc. This is purely to avoid the confusion whereby implementations cannot or choose not to implement any new specification. The last thing any WSGI server author wants is having to deal with a constant stream of questions and bug reports about not supporting an updated specification where technically it was never going to be possible. We have some obligation not to inflict this on what are, in nearly all cases, volunteers in the Open Source world who work on these things in their spare time and who are not doing it as part of their paid employment. > Since then, the need for a revision of WSGI has become even more apparent. Casual discussion on the web has indicated that application developers are uncomfortable with the limitations of WSGI. These limitations are providing an incentive for both application developers and server developers to take an end-run around WSGI in an attempt to get a framework that is more suitable for the modern web. A great example of the result of WSGI?s deficiencies is Andrew Godwin?s channels work[0] for Django, which represents a paradigm shift in application development that takes it far away from what WSGI is today. > > For this reason, I think we need to try again to get WSGI 2.0 off the ground. But I don?t believe we can do this without getting broad consensus from the developer community that a revision to WSGI is needed, and without understanding what developers need from a new revision of WSGI. This should take into account the prior discussions we?d had on this thread: however, I?m also going to actively solicit feedback from some of the more notable WSGI implementers, to ensure that whatever comes out of this SIG is something that they would actually use. > > This WG already had a list of requirements, which are as follows: > > - Support servers speaking HTTP/1.x, HTTP/2 and Websockets (potentially all on a single port). Any support for implementing WebSockets should though be seen as a separate requirement to implementing HTTP/2. A specific WSGI server implementation may be able to support HTTP/2, but not support WebSockets, or it could support WebSockets via HTTP/1.x already. In fact basic request/response functionality of HTTP/2 maps into the existing WSGI API specification and doesn?t really require any changes be made to the WSGI specification. 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 with no code changes to mod_wsgi. To support WebSockets is a much bigger problem and is not achievable with CGI, FASTCGI, SCGI. It may be able to be supported within the Apache/mod_wsgi implementation, but the major re-architecting required in the mod_wsgi code, and the fact that it couldn?t be done by simply exposing a socket, but by requiring a new high level abstract API be developed which doesn?t expose the actual socket object, means you are really talking about a whole new API. To me the WebSocket requirement and the need for a completely new API rules out ever doing this as part of an updated WSGI specification. It should really be treated as a completely separate thing. There has been discussed previously the possibility of bootstrapping into a WebSocket session (or any other new protocol or its corresponding API) via a connection upgrade process. In other words, you have the request actually make it to the WSGI application and it then decides to push back some response that causes the underlying server to resubmit the request back to the Python web application as a whole, but via a different API. This idea that the WSGI application would make the decision though was a somewhat clumsy mechanism and could easily be messed up where people start wrapping WSGI middleware around applications and so the decision point is nested. This would likely be impractical for implementations such as mod_wsgi and may be uWSGI as well, where you may at the point of calling into the Python code already be nested within the layers of some C level abstractions that exist between the WSGI application and the underlying server. You are really well past the point where the decision to use a particular protocol can sensibly be made. It is just too hard to try and unwind any server level layers and switch protocols. So if something were to support WebSockets, it should be a decision made down in the underlying server and calling into any Python web application should be done through a distinct API from the existing WSGI application API, where the API entry point for WebSocket was defined distinct from the WSGI application one. They are therefore two different APIs and so why WebSocket should be dealt with in a separate specification and not carry the WSGI label at all. A specific WSGI server could still support the new WebSocket API, but purely because it decides to support both in the same process. Not because the WebSocket API makes use of the WSGI specification. The only thing you might allow to make it easier to have both coexist in same code, is to add a convention that a WSGI application callable might provide a new function such as ?__endpoint__(protocol)? which allows the underlying server to request of the same application object an API entry point for any new protocol such as WebSocket. This may well be better done though as some new higher level abstraction encapsulating the whole concept of a web application which supports idea of startup/shutdown hooks, passing of configuration from the server etc. Right now there is no consistency for this between WSGI servers. If such a higher level abstraction for an entrypoint were created, even getting a the ?WSGI? API endpoint may require the initial call to request it. Whatever way a server learns about a web application supporting additional protocols, be it through server configuration or a discoverable higher level application object abstraction, the key thing is that the server should be the one left to make the decision of what actual Python API object to call into so that the server is more readily able to set up any protocol stack with the server part to match before it is too late and it isn?t possible to undo what it may have already set up. > - Support graceful degradation for applications that can use HTTP/2 but still support HTTP/1.x requests. The issue here is really how much of the new functionality of HTTP/2 you expose to a Python web application. As far as basic request/response mapping into existing WSGI interface there is no need for graceful degradation to be considered, at least not at the WSGI level, as that is an issue for the underlying server. Whether the server handles it as HTTP/1.x or HTTP/2, it still maps to the same WSGI application API and the application wouldn?t care. For new functionality of HTTP/2, much like WebSockets, I believe a completely new API should be developed. It isn?t necessarily going to be realistic to try and shoe horn it into the existing WSGI API somehow. > - Graceful incremental adoption path - no upgrade-all-components requirement baked into the design. It is hard to see what you expectations are here. Prior attempts to force ASYNC into WSGI, and in some respects WebSockets through forcing raw fd access have not been practical. WSGI simply is not a good vehicle for it. Long term it is going to be much better to have new APIs for new WebSocket and HTTP/2 support. The only even partly graceful path is perhaps first ignoring WebSockets and HTTP/2 and coming up with a more rich higher level abstraction for the complete Python web application entry point itself. So the idea above of a higher level object which defines hooks for startup/shutdown, passing configuration and also perhaps the querying of what protocols are supported by the application and even optionally what specific URL endpoints those protocols are active on. You could even have a application say where static file assets live so the server could host them itself via any more optimal methods than the application itself could use. Get this in place then existing WSGI servers could be changed to accomodate this new higher level abstraction for the entrypoint. They may not support new protocols initially, or maybe not at all, but it at least provides a framework for the server and application to coordinate better and so allow a server to direct certain protocol types to different endpoints in the application, or even for the server to notify the application that certain protocols aren?t supported and so allow an application to use alternative mechanisms. Down the track with HTTP/2 support, with the ability of the application to say, this is where my static assets are, you could even perhaps have a way of flagging that certain assets should be pushed back by the server knowing that they will be required. This way the server becomes responsible for that at the place where lower level access to HTTP/2 primitives is available, which might not be passed through a higher level API. > - Support Python 2.7 and 3.x (where x is not yet discussed) 3.3 would need to be the absolute minimum. Support anything older in 3.x is too much of a pain. > - Support the existing ecosystem of containers (such as mod_wsgi) with the new API. We want a clean, fast and approachable API, and we want to ensure that its no less friendly to work with than WSGI, for all that it will expose much more functionality. > - Apps need to be able to tell what protocol is in use, and what optional features are available. For instance, HTTP/2 PUSH PROMISE is an optional feature that can be disabled by clients. Websockets needs to expose a socket like object, and so on. I will stress my opposition to exposing of any raw socket. Some existing servers will simply not be able to do that in a sensible way where they already use a internal proxying arrangement where there exists a messaging layer between processes and the raw socket is actually only available in a completely different process to the web application. > - Support websockets > - Support HTTP/2 > - Support HTTP/1.x (which may be just 'point at PEP-3333?.) > - Continue to support lightweight shims being built on top such as https://github.com/Pylons/webob/blob/master/webob/request.py > > I believe that all of these requirements are up for grabs, and subject to change and consensus discussion. In this thread, then, I?d like to hear from people about these requirements and others. What do you believe WSGI 2.0 should do? Just as importantly, what do you believe it should not do? What prior art should we take into account? Should we bother revising WSGI at all, or should we let the wider application ecosystem pursue its own solutions ? la Django's channels? Should we simply adopt Andrew Godwin?s ASGI draft[1] on which channels is based and call *that* WSGI 2.0? My current thinking is that what needs to be done is: 1. An optionally updated WSGI specification labelled as WSGI 1.1. This has got nothing really to do with the initiative to have a way to handle WebSockets and HTTP/2. It would simply to be integrate changes which were raised the last time the WSGI specification was updated, but which were passed over because a PEP was in the end rushed through just to deal with Python 3, ignoring other concerns. There are only a few changes which this would cover. The first relates to the guarantee that you are able to read past CONTENT_LENGTH because a WSGI server will return an empty string on end of input. This is to support chunked request encoding and compressed request content where decompression is handled by the server. Basically, CONTENT_LENGTH becomes advisory only. WSGI applications are allowed to ignore it, expect maybe for raising a 413 response, and read to end of input. The change of wsgi.version to 1.1 is needed to allow frameworks to know the guarantee exists that this will work. This ability has existed in Apache/mod_wsgi for a long time and the Flask builtin server also supports it with Werkzeug/Flask currently relying on looking for special non standard markers in WSGI environ to know the guarantee exists. I have blogged about this issue before. The second relates to the wsgi.file_wrapper object being required to be a class type. I will not go into how as I have also blogged about this before, but this allows middleware to wrap a response iterable to add a action on close() but not break any optimisations for more performant sending of files. A third change is to fix the example for wsgi.file_wrapper fallback, which doesn?t close the file descriptor properly and so results in leakage of file descriptors, with them only being cleaned up by the garbage collector. I vaguely recollect there may have been another issue for wsgi.file_wrapper around response Content-Length. I can?t remember if that definitely required a change. I will need to go back my blog posts about that one. There could also be other things I have found as still being wrong. As I note above, this is optional. But if we are going to close out WSGI and not develop it further, would be nice to fix up some of the last problems with it. 2. Develop a higher level abstraction for what is a Python web application. Thus hooks for startup/shutdown, passing configuration from the server, or querying back configuration from the application pertaining to supported protocols, along with what sub URLs protocols are supported on, and where static file assets may be that application may want the server to handle if that would be more performant. I believe that such a new high level abstraction will provide a better framework to hang things off when we introduce new protocols. 3. Separate WebSocket API. Basically ignore existing WSGI specification completely. Come up with the best API one can for WebSocket interaction at the server level. This should not just be exposing a socket, but be a higher level abstraction involving passing of actual WebSocket messages. By using higher level abstraction it allows a server to implement the details using whatever mechanisms best fit that server implementation. 4. Separate HTTP/2 API. Again, ignore existing WSGI specification complete. Come up with the best API one can for dealing with HTTP/2. For (3) and (4) lets do these as being our holy grail. Rather than compromise by trying to work with WSGI, lets first come up with what would be our ideal. Then lets see how that can fit within existing servers, possibly integrated via the richer application abstraction of (2). > Right now I want this to be very open. I?d like people to come up with a broad statement listing what they believe should and should not be present in WSGI. This first stage of the work is very general: I just want to get a feeling for what the community believes is important. Once we?re done with that, if the consensus is that this work is worth pursuing, I?ll come up with an initial draft that we can start making concrete changes to. > > In the short term, I?m going to keep this consultation open for **at least two weeks**: that is, I will not start working on an initial draft PEP until at least the **18th of January**. If you believe there are application or server developers that should be involved in this discussion, please reach out to them and point them to this list. I personally have CC?d some people that I believe need to be involved in the discussion, but please reach out to others as well. It isn?t clear what you expect this PEP to include, but trying to push for a PEP so quickly is unrealistic. There is likely going to need to be a fair bit of discussion and with the fact that people have real jobs, or other obligations, history has shown that rushing to a PEP just disenfranchises people and they will not contribute due to the inability to do so in too short a time frame. > I?d really love to come to the end of 2016 with a solid direction for the future of web programming in Python. I?m looking forward to working with you all on achieving that. Graham -------------- next part -------------- An HTML attachment was scrubbed... URL: From robertc at robertcollins.net Mon Jan 4 21:22:27 2016 From: robertc at robertcollins.net (Robert Collins) Date: Tue, 5 Jan 2016 15:22:27 +1300 Subject: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest In-Reply-To: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> References: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> Message-ID: 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 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 unfortunately personal commitments made it impossible for Rob to keep pushing that attempt forward. > > Since then, the need for a revision of WSGI has become even more apparent. Casual discussion on the web has indicated that application developers are uncomfortable with the limitations of WSGI. These limitations are providing an incentive for both application developers and server developers to take an end-run around WSGI in an attempt to get a framework that is more suitable for the modern web. A great example of the result of WSGI?s deficiencies is Andrew Godwin?s channels work[0] for Django, which represents a paradigm shift in application development that takes it far away from what WSGI is today. > > For this reason, I think we need to try again to get WSGI 2.0 off the ground. But I don?t believe we can do this without getting broad consensus from the developer community that a revision to WSGI is needed, and without understanding what developers need from a new revision of WSGI. This should take into account the prior discussions we?d had on this thread: however, I?m also going to actively solicit feedback from some of the more notable WSGI implementers, to ensure that whatever comes out of this SIG is something that they would actually use. > > This WG already had a list of requirements, which are as follows: > > - Support servers speaking HTTP/1.x, HTTP/2 and Websockets (potentially all on a single port). > - Support graceful degradation for applications that can use HTTP/2 but still support HTTP/1.x requests. > - Graceful incremental adoption path - no upgrade-all-components requirement baked into the design. > - Support Python 2.7 and 3.x (where x is not yet discussed) > - Support the existing ecosystem of containers (such as mod_wsgi) with the new API. We want a clean, fast and approachable API, and we want to ensure that its no less friendly to work with than WSGI, for all that it will expose much more functionality. > - Apps need to be able to tell what protocol is in use, and what optional features are available. For instance, HTTP/2 PUSH PROMISE is an optional feature that can be disabled by clients. Websockets needs to expose a socket like object, and so on. > - Support websockets > - Support HTTP/2 > - Support HTTP/1.x (which may be just 'point at PEP-3333?.) > - Continue to support lightweight shims being built on top such as https://github.com/Pylons/webob/blob/master/webob/request.py > > I believe that all of these requirements are up for grabs, and subject to change and consensus discussion. In this thread, then, I?d like to hear from people about these requirements and others. What do you believe WSGI 2.0 should do? Just as importantly, what do you believe it should not do? What prior art should we take into account? Should we bother revising WSGI at all, or should we let the wider application ecosystem pursue its own solutions ? la Django's channels? Should we simply adopt Andrew Godwin?s ASGI draft[1] on which channels is based and call *that* WSGI 2.0? > > Right now I want this to be very open. I?d like people to come up with a broad statement listing what they believe should and should not be present in WSGI. This first stage of the work is very general: I just want to get a feeling for what the community believes is important. Once we?re done with that, if the consensus is that this work is worth pursuing, I?ll come up with an initial draft that we can start making concrete changes to. > > In the short term, I?m going to keep this consultation open for **at least two weeks**: that is, I will not start working on an initial draft PEP until at least the **18th of January**. If you believe there are application or server developers that should be involved in this discussion, please reach out to them and point them to this list. I personally have CC?d some people that I believe need to be involved in the discussion, but please reach out to others as well. > > I?d really love to come to the end of 2016 with a solid direction for the future of web programming in Python. I?m looking forward to working with you all on achieving that. Whats the goal? The goal I had when I started was to enable a portable-across-servers websockets + HTTP/2 capability in the Python world. A PEP is one route to doing that. Just putting some code together and offering it to many projects is another way forward. WSGI is sufficiently lightweight in definition that there is no need to include anyone else's implementation. I (sadly) suspect that that is still important to folk, particularly folk like Graham who are doing cross-process things already (and have been for years). Things that I think are not a goal: - being able to handle any future IETF protocol through this thing. If its a ratified standard that doesn't look like HTTP{1,2} or websockets, there's no guarantee that it will fit the model we come up with now. That said, there are WSGI adapters to do SMTP, and that certainly doesn't look like HTTP :). - being directly compatible with WSGI - being an exact fit for any one, or even most Python web frameworks today. 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 lot bigger. w.r.t. ASGI, it sounds like mongrel2 just in earlier days. Its a nifty way to build things, but I think its missing a fairly important thing: its not conceptually simple any more. I think what we would benefit from is: - engagement from mod_wsgi, the nginx uwsgi folk, and perhaps a smattering of the active people from http://wsgi.readthedocs.org/en/latest/servers.html - likewise on the application side: we need a Django person engaged with this - I reached out for one at the start of the last initiative but didn't manage to hook anyone, flask folk being interested would be good etc. I think WSGI got the following things really right: - it was widely advertised (europython talks, etc etc) - it *is* a defined standard - framework authors can write good-enough adapters to their own stuff in a day, more or less. - servers can support it in a day, more or less [assuming they already have HTTP support themselves] - it doesn't bake in any assumptions that are really hard to satisfy - there is a reference implementation that works What we actually need, concretely, is a proposal. Something that can be considered and thought about, and worked through by the many interested parties. As far as the requirements are concerned - that list above is actually pretty small. We could easily balloon it up by (for instance), insisting on async support (the prior discussion around this concluded that asyncio's whole set of interactions will be different, so that should be a different PEP, though they may be able to share some common data structures. If we try to futureproof, leaving deliberate ways to do something undefined in a compatible fashion, we're guaranteed to make things much much more complex. For instance - raw access to the socket was mentioned in your other mail?! Gosh no, thats simply impossible in a number of servers today, and it would make writing an adapter for this new thing really very hard. Even websockets sockets are not sockets in the sense that most folk think about sockets. Having spent the last year running off and tackling a bunch of other things, I'd like to propose the following way forward: 1 - draft a PEP for WSGI-NG that handles: - HTTP/1.x, HTTP/2, websockets - wrapping a WSGI app - wrapping an NG app for a WSGI server - retains the basic-types-only interface, for cross-process friendliness - no presumption of shared state in the specification. (WSGI is ambiguous about whether environ is shared in a stack of decorators or not, and its led to hilarity before) - strong - and I mean strong - isolation between servers-that-own-the-fd and any contained application. All three protocol's we're talking about have strict framing layers, and only server authors have any business dealing with the plumbing. - use coroutines or generators systematically 2 - socialise that with the various interested groups. Ask if they love it or hate it. Ask if supporting it is straightforward or requires fugly stuff. Ask if they would benefit if they adopted it. 3 - iterate. Or to put it another way - I think the opinions are well known, what we're missing right now is a careful detailed creation put together that brings in the needed expertise to craft something useful. On the asyncio / await etc side: I leave this up to the author. Thunking to WSGI from awaitable's would be tedious and thread-heavy I suspect. Obviously it can be done. AFAIK right now there is no mass move to asyncio from the server frameworks around: we're not going to solve the problems they have today with WSGI (e.g. the server-specific websockets requirements) by making standardisation be predicated on moving something like Django to a new server core. I recall attempts to move other big frameworks around years ago now, taking a long long time.... I think the question of 'how can we enable interop of HTTP applications in asyncio' is best handled by a dedicated effort analogous to WSGI but in that programming model. -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud From andrew at aeracode.org Mon Jan 4 21:44:41 2016 From: andrew at aeracode.org (Andrew Godwin) Date: Mon, 4 Jan 2016 18:44:41 -0800 Subject: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest In-Reply-To: References: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> Message-ID: 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 lot bigger. w.r.t. ASGI, it sounds like > mongrel2 just in earlier days. Its a nifty way to build things, but I > think its missing a fairly important thing: its not conceptually > simple any more. > I appreciate that, though I would argue that the spec makes it seem more complex than it actually is. You can write a ASGI application in about 4 lines, in a way that I think is no worse than start_response and environ in WSGI: while True: _, request = layer.receive_many("http.request", block=True) response = {"content": "Hello World!", "status": 200} layer.send(request['reply_channel'], response) There's no reason ASGI couldn't have a WSGI-like layer specified on top for HTTP requests so it looked more like current WSGI, but with slightly nicer request and response objects. That is, in fact, mostly what the Django Channels code does right now. Mongrel2's design had some other issues, ZeroMQ being top of the list (it's just not a good queuing system), as well as being way too stateful and complex. I could probably go on about the differences at length, but I'll refrain :) > - likewise on the application side: we need a Django person engaged > with this - I reached out for one at the start of the last initiative > but didn't manage to hook anyone, flask folk being interested would be > good etc. > Hi, I am very interested, obviously. Django _will probably have_ websocket support by next release, and it almost certainly will run using ASGI internally; what's up for debate is how it gets served, either via a WSGI shim, a WSGI-NG shim or native support in a server. I'm a big believer in going for implementation and iteration and polish before jumping to a PEP, which is why I didn't bring ASGI anywhere near that process yet. Once it's done, tested, implemented and we get it running well at scale, then I think it would be ready. Django got a big pot of funding from Mozilla just to get this process done, and several large sites waiting to beta test things and report back how they work in the real world. That said, I'm not stuck in some world where Django is the only Python web framework; I would love to see the input of others. My ideal would be for a new spec to renew the interest in writing more "raw" web apps in Python, rather than people turning to other languages which have ostensibly better WebSocket etc. support. > On the asyncio / await etc side: I leave this up to the author. > Thunking to WSGI from awaitable's would be tedious and thread-heavy I > suspect. Obviously it can be done. AFAIK right now there is no mass > move to asyncio from the server frameworks around: we're not going to > solve the problems they have today with WSGI (e.g. the server-specific > websockets requirements) by making standardisation be predicated on > moving something like Django to a new server core. I recall attempts > to move other big frameworks around years ago now, taking a long long > time.... I think the question of 'how can we enable interop of HTTP > applications in asyncio' is best handled by a dedicated effort > analogous to WSGI but in that programming model. > I agree that tying things to asyncio is a Bad Idea; any proposal should certainly be more friendly to it, but requiring people to write fully asynchronous code is a sure way to lose the simplicity of WSGI. We'd have to do an incredible amount of work to Django to make it fully asynchronous like that, to the point where it may never happen. What would probably happen is just serving requests one at a time using thread pools or something. Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From robertc at robertcollins.net Mon Jan 4 22:59:01 2016 From: robertc at robertcollins.net (Robert Collins) Date: Tue, 5 Jan 2016 16:59:01 +1300 Subject: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest In-Reply-To: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> References: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> Message-ID: 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 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 unfortunately personal commitments made it impossible for Rob to keep pushing that attempt forward. > > Since then, the need for a revision of WSGI has become even more apparent. Casual discussion on the web has indicated that application developers are uncomfortable with the limitations of WSGI. These limitations are providing an incentive for both application developers and server developers to take an end-run around WSGI in an attempt to get a framework that is more suitable for the modern web. A great example of the result of WSGI?s deficiencies is Andrew Godwin?s channels work[0] for Django, which represents a paradigm shift in application development that takes it far away from what WSGI is today. > > For this reason, I think we need to try again to get WSGI 2.0 off the ground. But I don?t believe we can do this without getting broad consensus from the developer community that a revision to WSGI is needed, and without understanding what developers need from a new revision of WSGI. This should take into account the prior discussions we?d had on this thread: however, I?m also going to actively solicit feedback from some of the more notable WSGI implementers, to ensure that whatever comes out of this SIG is something that they would actually use. > > This WG already had a list of requirements, which are as follows: > > - Support servers speaking HTTP/1.x, HTTP/2 and Websockets (potentially all on a single port). > - Support graceful degradation for applications that can use HTTP/2 but still support HTTP/1.x requests. > - Graceful incremental adoption path - no upgrade-all-components requirement baked into the design. > - Support Python 2.7 and 3.x (where x is not yet discussed) > - Support the existing ecosystem of containers (such as mod_wsgi) with the new API. We want a clean, fast and approachable API, and we want to ensure that its no less friendly to work with than WSGI, for all that it will expose much more functionality. > - Apps need to be able to tell what protocol is in use, and what optional features are available. For instance, HTTP/2 PUSH PROMISE is an optional feature that can be disabled by clients. Websockets needs to expose a socket like object, and so on. > - Support websockets > - Support HTTP/2 > - Support HTTP/1.x (which may be just 'point at PEP-3333?.) > - Continue to support lightweight shims being built on top such as https://github.com/Pylons/webob/blob/master/webob/request.py > > I believe that all of these requirements are up for grabs, and subject to change and consensus discussion. In this thread, then, I?d like to hear from people about these requirements and others. What do you believe WSGI 2.0 should do? Just as importantly, what do you believe it should not do? What prior art should we take into account? Should we bother revising WSGI at all, or should we let the wider application ecosystem pursue its own solutions ? la Django's channels? Should we simply adopt Andrew Godwin?s ASGI draft[1] on which channels is based and call *that* WSGI 2.0? > > Right now I want this to be very open. I?d like people to come up with a broad statement listing what they believe should and should not be present in WSGI. This first stage of the work is very general: I just want to get a feeling for what the community believes is important. Once we?re done with that, if the consensus is that this work is worth pursuing, I?ll come up with an initial draft that we can start making concrete changes to. > > In the short term, I?m going to keep this consultation open for **at least two weeks**: that is, I will not start working on an initial draft PEP until at least the **18th of January**. If you believe there are application or server developers that should be involved in this discussion, please reach out to them and point them to this list. I personally have CC?d some people that I believe need to be involved in the discussion, but please reach out to others as well. > > I?d really love to come to the end of 2016 with a solid direction for the future of web programming in Python. I?m looking forward to working with you all on achieving that. > > Thanks, > > Cory > > > [0]: https://channels.readthedocs.org/en/latest/ > [1]: https://channels.readthedocs.org/en/latest/asgi.html -- Robert Collins Distinguished Technologist HP Converged Cloud From cory at lukasa.co.uk Tue Jan 5 04:40:28 2016 From: cory at lukasa.co.uk (Cory Benfield) Date: Tue, 5 Jan 2016 09:40:28 +0000 Subject: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest In-Reply-To: References: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> Message-ID: > 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 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 unfortunately personal commitments made it impossible for Rob to keep pushing that attempt forward. > > Although you call this round 2, it isn?t really. Robert?s effort was not the first time someone has pushed a WSGI 2.0 variant. So this is more like being about round 5 or 6. > > In part because of those repeated attempts by people to propose something and label it as WSGI 2.0, I am very cool on reusing the WSGI 2.0 moniker. You will find little or no mention of ?WSGI 2.0? as a label in: > > https://github.com/python-web-sig/wsgi-ng > > That is probably somewhat due to my grumbling about the use of ?WSGI 2.0? back then. > > Time has moved on and so the bad feelings and memories associated with the ?WSGI 2.0? label due to early failed efforts have faded, but I would still suggest avoiding the label ?WSGI 2.0? if at all possible. Thanks for that feedback. Consider WSGI 2.0 a catch-all name for the purposes of this specific discussion (the ?what do we want WSGI to be going forward? one). As you?ve suggested here, it?s entirely possible that the result of this discussion will be several PEPs/APIs, or none at all, and it?s entirely possible that none of them would be called WSGI 2.0. > My general feeling is that if any proposed changes to the existing WSGI (PEP 3333) specification cannot be technically implemented on all existing WSGI server/adapter implementations that any new specification should not still be called WSGI. > > In other words, even if many of these implementations may not be used much any more, it must be able to work, without needing to mark things as optional, on CGI, FASTCGI, SCGI, mod_wsgi, gunicorn, uWSGI, Waitress, etc etc. > > This is purely to avoid the confusion whereby implementations cannot or choose not to implement any new specification. The last thing any WSGI server author wants is having to deal with a constant stream of questions and bug reports about not supporting an updated specification where technically it was never going to be possible. We have some obligation not to inflict this on what are, in nearly all cases, volunteers in the Open Source world who work on these things in their spare time and who are not doing it as part of their paid employment. Can I clarify this requirement a bit? Are you wanting to say that any future version of WSGI must be entirely compatible with PEP 3333: that is, may not introduce optional features or change existing behaviour, only clarify? Please don?t mistake this for me challenging the idea: I?m wanting to get a good understanding of what you?re suggesting with this, not agreeing or disagreeing at this stage. > 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 with no code changes to mod_wsgi. Agreed. If all we want is to keep the request/response cycle intact, then WSGI supports H2 already. One possibility that has already been suggested here would be to define a HTTP/2 extension to WSGI, advertised in the environ dict, that allows the application to signal pushes to the server. This would be a fairly simple extension to write and implement. > They are therefore two different APIs and so why WebSocket should be dealt with in a separate specification and not carry the WSGI label at all. A specific WSGI server could still support the new WebSocket API, but purely because it decides to support both in the same process. Not because the WebSocket API makes use of the WSGI specification. That?s reasonable: I?d be happy to have websocket support either be a WSGI extension or, as you suggest here, a wholly new API. One difficulty with creating a new API from whole cloth is encouraging server authors to support it, but it?s certainly possible to do. I?d like to hear back from the uWSGI, gunicorn, and Twisted folks in addition to yourself about whether they?d be interested in implementing such a non-WSGI API. >> - Graceful incremental adoption path - no upgrade-all-components requirement baked into the design. > > It is hard to see what you expectations are here. > > Prior attempts to force ASYNC into WSGI, and in some respects WebSockets through forcing raw fd access have not been practical. WSGI simply is not a good vehicle for it. Long term it is going to be much better to have new APIs for new WebSocket and HTTP/2 support. This is an interesting point and I?d like to try to get you to elaborate if possible. It?s my genuinely held belief that WSGI in its current form is likely going to be largely abandoned unless it becomes possible to combine it with a Python event loop of some kind. This applies even to plain HTTP/1.1 requests, which are still well-served by allowing the application process to take advantage of concurrent programming techniques without blocking the server waiting for the response. It may be that you fundamentally disagree with me here: is that the case? The other interpretation I can see of this comment is that you?d rather we did not call a new, async-friendly HTTP/X API WSGI, but instead gave it some other name (ASGI is taken, so?fast-WSGI? ;) ). That is also totally reasonable: as I said above, I am not concerned about whether we call the work done by this SIG WSGI or not. > The only even partly graceful path is perhaps first ignoring WebSockets and HTTP/2 and coming up with a more rich higher level abstraction for the complete Python web application entry point itself. So the idea above of a higher level object which defines hooks for startup/shutdown, passing configuration and also perhaps the querying of what protocols are supported by the application and even optionally what specific URL endpoints those protocols are active on. You could even have a application say where static file assets live so the server could host them itself via any more optimal methods than the application itself could use. I?d like to draw application and server authors to this point you?ve raised. Do people believe, in general, that there is some advantage in a meta-gateway interface that allows registration of more tightly-scoped gateway interfaces, such as WSGI and a websocket specific interface? Or would you resist implementing such a thing? It would be a waste of time to build such a thing if no-one wants it, but if there?s interest in implementing with and playing with it, I think it?s a reasonable thing to have. > 1. An optionally updated WSGI specification labelled as WSGI 1.1. This has got nothing really to do with the initiative to have a way to handle WebSockets and HTTP/2. It would simply to be integrate changes which were raised the last time the WSGI specification was updated, but which were passed over because a PEP was in the end rushed through just to deal with Python 3, ignoring other concerns. There are only a few changes which this would cover. > > As I note above, this is optional. But if we are going to close out WSGI and not develop it further, would be nice to fix up some of the last problems with it. On a personal level, if the updated WSGI specification did nothing more than codify current WSGI practice that would be fine, but otherwise if we were intending to consider WSGI basically ?done? I don?t really see the advantage in revving the specification. If the view is that WSGI as-is will have one more change and then we?ll start looking to other approaches (be those other standardised gateway interfaces or less-standard all-inclusive frameworks that bundle their own servers), it?ll be hard to sell anyone on taking up the newly changed WSGI instead of investing time moving to the new world. > 2. Develop a higher level abstraction for what is a Python web application. Thus hooks for startup/shutdown, passing configuration from the server, or querying back configuration from the application pertaining to supported protocols, along with what sub URLs protocols are supported on, and where static file assets may be that application may want the server to handle if that would be more performant. > > I believe that such a new high level abstraction will provide a better framework to hang things off when we introduce new protocols. I can get behind this idea, though I view it as strictly optional and if no-one wants to implement it I think we should save ourselves the work! > 3. Separate WebSocket API. > > Basically ignore existing WSGI specification completely. Come up with the best API one can for WebSocket interaction at the server level. This should not just be exposing a socket, but be a higher level abstraction involving passing of actual WebSocket messages. > > By using higher level abstraction it allows a server to implement the details using whatever mechanisms best fit that server implementation. > > 4. Separate HTTP/2 API. > > Again, ignore existing WSGI specification complete. Come up with the best API one can for dealing with HTTP/2. > > For (3) and (4) lets do these as being our holy grail. Rather than compromise by trying to work with WSGI, lets first come up with what would be our ideal. Then lets see how that can fit within existing servers, possibly integrated via the richer application abstraction of (2). This seems like a reasonable approach: if the rest of the community is interested in it, I?d be happy to go along with it. > It isn?t clear what you expect this PEP to include, but trying to push for a PEP so quickly is unrealistic. There is likely going to need to be a fair bit of discussion and with the fact that people have real jobs, or other obligations, history has shown that rushing to a PEP just disenfranchises people and they will not contribute due to the inability to do so in too short a time frame. I apologise if I was unclear, but I am not pushing for a PEP anytime before the end of calendar year 2016. What I?m pushing for right now is to get people talking with the idea that we will keep taking steps forward. Sometime later this month or early next month I intend to stand up a porto-PEP (or more) that do nothing more than enumerate the goals of the work. That?ll give us a document to refer to going forward, but still give us time to work on concrete implementation and real problems. I am happy for this to take as long as it takes, but I?m also going to put light pressure on to keep moving forward, lest we get bogged down in discussion forever and produce nothing. Thanks so much for your feedback Graham! Cory -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From cory at lukasa.co.uk Tue Jan 5 06:26:04 2016 From: cory at lukasa.co.uk (Cory Benfield) Date: Tue, 5 Jan 2016 11:26:04 +0000 Subject: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest References: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> Message-ID: 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 WebSockets, don?t start with design decisions anchored in CGI. Figure out what a simple and flexible API for these new protocols would be, specify it, implement it, and make sure it degrades gracefully to HTTP/1. You may be able to channel most of the communication through a single generator, but it?s unclear to me that this will be the most convenient design. If you want to improve WSGI, here?s a list of mistakes or shortcomings in PEP 3333 that you can take a stab at. There?s a general theme: for a specification that looks at the future, I believe that making modern PaaS-based deployments secure by default matters more than not implementing anything beyond what?s available in legacy CGI-based deployments. 1. WSGI is prone to header injection vulnerabilities issues by design due to the conversion of HTTP headers to CGI-style environment variables: if the server doesn?t specifically prevent it, X-Foo and X_Foo both become HTTP_X_Foo. I don?t believe it?s a good choice to destructively encode headers, expect applications to undo the damage somehow, and introduce security vulnerabilities in the process. If mimicking CGI is still considered a must-have ? 1% of current Python web programmers may have heard about it, most of them from PEP 3333 ? then that burden should be pushed onto the server, not the application. 2. More generally, I fail to see how mixing HTTP headers, server-related inputs, and environment variables in a dict adds values. It prevents iterating on each collection separately. It only makes sense if not offering more features than CGI is a design goal; in that case, this discussion doesn?t serve a purpose anyway. It would be nicer and possibly more secure if the application received separately: a. Configuration information, which servers could read from environment variables by default for backwards compatibility, but could also get through more secure channels and restrict to what the application needs in order to better isolate it from the entire OS. b. Server APIs mandated by the spec, per request. c. HTTP headers, per request. 3. Stop pretending that HTTP is a unicode protocol, or at least stop ignoring reality when doing so. WSGI enforces ISO-8859-1-decoded str objects in the environ, which is just wrong. It?s all the more a surprising choice since this change was driven by Python 3, that UTF-8 is the correct choice, and that Python 3 defaults to UTF-8. Django has to re-encode and re-decode before doing anything with HTTP headers: https://github.com/django/django/blob/d5b90c8e120687863c1d41cf92a4cdb11413ad7f/django/core/handlers/wsgi.py#L231-L253 4. Normalize the way to tell the application about the original protocol, IP address and port. When dev and ops responsibilities are separate, this is clearly an ops responsibility, but due to the lack of standardization devs end up dealing with this problem in custom middleware, when they do it at all. Everyone keeps getting it wrong, which introduces security vulnerabilities. Also it always breaks silently on infrastructure changes. 5. Improve request / response length handling and connection closure. Armin and Graham have talked about in the past and know the topic better than I do. There?s also a rejected PEP by Armin which made sense to me. As you can see from these comments, I don?t quite share the design choices that led to WSGI as it currently stands. I think it will be easier to build a new standard than evolve the current one. I hope this helps! Aymeric -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From graham.dumpleton at gmail.com Tue Jan 5 06:31:22 2016 From: graham.dumpleton at gmail.com (Graham Dumpleton) Date: Tue, 5 Jan 2016 22:31:22 +1100 Subject: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest In-Reply-To: References: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> Message-ID: <32B5F7C6-CF71-4CB5-8342-92D1813A6A16@gmail.com> > 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.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 unfortunately personal commitments made it impossible for Rob to keep pushing that attempt forward. >> >> Although you call this round 2, it isn?t really. Robert?s effort was not the first time someone has pushed a WSGI 2.0 variant. So this is more like being about round 5 or 6. >> >> In part because of those repeated attempts by people to propose something and label it as WSGI 2.0, I am very cool on reusing the WSGI 2.0 moniker. You will find little or no mention of ?WSGI 2.0? as a label in: >> >> https://github.com/python-web-sig/wsgi-ng >> >> That is probably somewhat due to my grumbling about the use of ?WSGI 2.0? back then. >> >> Time has moved on and so the bad feelings and memories associated with the ?WSGI 2.0? label due to early failed efforts have faded, but I would still suggest avoiding the label ?WSGI 2.0? if at all possible. > > Thanks for that feedback. Consider WSGI 2.0 a catch-all name for the purposes of this specific discussion (the ?what do we want WSGI to be going forward? one). As you?ve suggested here, it?s entirely possible that the result of this discussion will be several PEPs/APIs, or none at all, and it?s entirely possible that none of them would be called WSGI 2.0. > >> My general feeling is that if any proposed changes to the existing WSGI (PEP 3333) specification cannot be technically implemented on all existing WSGI server/adapter implementations that any new specification should not still be called WSGI. >> >> In other words, even if many of these implementations may not be used much any more, it must be able to work, without needing to mark things as optional, on CGI, FASTCGI, SCGI, mod_wsgi, gunicorn, uWSGI, Waitress, etc etc. >> >> This is purely to avoid the confusion whereby implementations cannot or choose not to implement any new specification. The last thing any WSGI server author wants is having to deal with a constant stream of questions and bug reports about not supporting an updated specification where technically it was never going to be possible. We have some obligation not to inflict this on what are, in nearly all cases, volunteers in the Open Source world who work on these things in their spare time and who are not doing it as part of their paid employment. > > Can I clarify this requirement a bit? Are you wanting to say that any future version of WSGI must be entirely compatible with PEP 3333: that is, may not introduce optional features or change existing behaviour, only clarify? Please don?t mistake this for me challenging the idea: I?m wanting to get a good understanding of what you?re suggesting with this, not agreeing or disagreeing at this stage. I am saying that any update to the WSGI specification should still be able to be implemented using any of the existing technologies that can already implement WSGI. I would see it as just causing problems to bring out an updated WSGI specification which couldn?t be implemented on top of CGI, FASTCGI, SCGI or even mod_wsgi. Further, it does really still need to be compatible with the existing specifications/applications. Changes I am talking about are clarifications or suggesting better ways of doing stuff like wsgi.file_wrapper to avoid known problems or to eliminate the use of assumptions about how something works. If a framework or application is made dependent on some new aspect of the WSGI specification which has no fallback because the specification was changed to not really be compatible with prior versions in some way then it is me as the author of a WSGI server who would have to endure the constant questions of why that framework or application doesn?t now work on mod_wsgi if the changes couldn?t be supported. People will not care what version of WSGI the framework or application adhered to. Their attitude will be that it supports WSGI and since mod_wsgi says it supports WSGI it must work, but since it doesn?t mod_wsgi must be broken. They will ignore version vagaries. So I am being selfish in not wanting to have to put up with more users complaining about stuff. :-) As for optional stuff, if they are truly extensions and can work through stuffing things in the WSGI environ dictionary, we already have a process for providing those which doesn?t require changes to the WSGI specification. http://wsgi.readthedocs.org/en/latest/specifications.html This keeps them separate. They don?t need to be part of the WSGI specification itself and it is probably better kept that way. This has always been the case but for whatever reason people have always tried to make some of these things part of the core WSGI specification itself even if it wasn?t necessary. >> 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 with no code changes to mod_wsgi. > > Agreed. If all we want is to keep the request/response cycle intact, then WSGI supports H2 already. One possibility that has already been suggested here would be to define a HTTP/2 extension to WSGI, advertised in the environ dict, that allows the application to signal pushes to the server. This would be a fairly simple extension to write and implement. Sorry to be cynical. Many people have said that changes in the past related to WSGI will 'be a fairly simple extension to write and implement?. Dig deeper and it never turns out to be the case. :-) Such an extension presumes you actually have a tightly integrated HTTP/2 server which itself which can maintain a map of resources to push when getting certain requests and also maintain what may have already been sent for a session. Even getting to that point is going to be non trivial, even if an extension may be simple for somehow notifying what the additional resources to supply should be. Right now I would say that with mod_h2 in Apache in would be plain impossible as it doesn?t I believe even support the idea of pushing resources at this point. Even then it would most likely be a huge undertaking to get it to work for mod_wsgi daemon mode as the web application runs in a separate process to where HTTP/2 is handled. If you believe though it is as simple as an extra item in the environ dictionary, then it can be handled as a separate extension specification per the URL above. >> They are therefore two different APIs and so why WebSocket should be dealt with in a separate specification and not carry the WSGI label at all. A specific WSGI server could still support the new WebSocket API, but purely because it decides to support both in the same process. Not because the WebSocket API makes use of the WSGI specification. > > That?s reasonable: I?d be happy to have websocket support either be a WSGI extension or, as you suggest here, a wholly new API. One difficulty with creating a new API from whole cloth is encouraging server authors to support it, but it?s certainly possible to do. I?d like to hear back from the uWSGI, gunicorn, and Twisted folks in addition to yourself about whether they?d be interested in implementing such a non-WSGI API. The only prior proposals related to a WebSocket extension have all amounted to shoving a fd in the environ dictionary and letting higher layers deal with it. As I have mentioned this isn?t really an option if you want WebSockets to work on different server architectures which involve multiple processes and internal communications. I don?t see that you have a choice but to have a purpose built API. Servers will then have leeway to handle that internal so it works with whatever internal interprocess communications mechanisms they may use. If people think though that everything can be achieved purely by shoving in a fd, then again sounds like something that can be dealt with as an extension specification outside of the WSGI specification. You will not see implementations for mod_wsgi, CGI, FASTCGI or SCGI though if things go down that path. Granted that nothing will likely change for the flup after for CGI, FASTCGI and SCGI anyway. >>> - Graceful incremental adoption path - no upgrade-all-components requirement baked into the design. >> >> It is hard to see what you expectations are here. >> >> Prior attempts to force ASYNC into WSGI, and in some respects WebSockets through forcing raw fd access have not been practical. WSGI simply is not a good vehicle for it. Long term it is going to be much better to have new APIs for new WebSocket and HTTP/2 support. > > This is an interesting point and I?d like to try to get you to elaborate if possible. I have noted why shoving a fd in for WebSockets will not work across server implementations. As to ASYNC, the stumbling block when using a callback based event system was always related to the fact that reads on wsgi.input are blocking. People tried all sorts of convoluted things to work around that and all that happened was that it turned WSGI into something quite different which couldn?t be compatible with existing synchronous applications and where WSGI middleware couldn?t be reused. Why still call something WSGI when it was very different and not compatible. > It?s my genuinely held belief that WSGI in its current form is likely going to be largely abandoned unless it becomes possible to combine it with a Python event loop of some kind. This applies even to plain HTTP/1.1 requests, which are still well-served by allowing the application process to take advantage of concurrent programming techniques without blocking the server waiting for the response. Like Python 2, WSGI in its current form will be around for a very long time. It will not be abandoned, but it will also not evolve, but that really isn?t an issue. > It may be that you fundamentally disagree with me here: is that the case? The other interpretation I can see of this comment is that you?d rather we did not call a new, async-friendly HTTP/X API WSGI, but instead gave it some other name (ASGI is taken, so?fast-WSGI? ;) ). That is also totally reasonable: as I said above, I am not concerned about whether we call the work done by this SIG WSGI or not. I definitely wouldn?t call it FAST-WSGI. :-) >> The only even partly graceful path is perhaps first ignoring WebSockets and HTTP/2 and coming up with a more rich higher level abstraction for the complete Python web application entry point itself. So the idea above of a higher level object which defines hooks for startup/shutdown, passing configuration and also perhaps the querying of what protocols are supported by the application and even optionally what specific URL endpoints those protocols are active on. You could even have a application say where static file assets live so the server could host them itself via any more optimal methods than the application itself could use. > > I?d like to draw application and server authors to this point you?ve raised. Do people believe, in general, that there is some advantage in a meta-gateway interface that allows registration of more tightly-scoped gateway interfaces, such as WSGI and a websocket specific interface? Or would you resist implementing such a thing? It would be a waste of time to build such a thing if no-one wants it, but if there?s interest in implementing with and playing with it, I think it?s a reasonable thing to have. Personally I see the adoption of a higher level abstraction for what is an application as being almost mandatory. I think the thinking people have is the wrong way around. People are thinking, how do I add all this new stuff into WSGI. I see it as being better that you introduce the higher level abstraction for applications which was always missing and then have WSGI protocol support a pluggable protocol which can be associated with it. Other new protocols could also plugin with their own APIs and would sit side by side with WSGI and so not be a child of WSGI. You could even have one of the plugins be a ASYNC replacement for WSGI if you really wanted that. The abstraction for the application wouldn?t care. The last thing I want to see happen is that the concept of a better abstraction for what an application is being ignored again. All that results in is all the WSGI servers going off and implementing their own way of handling the entry point for an application. As a result we now have the concept of WSGI script files, WSGI modules, callable code snippets, Paste ini configurations and possibly others for handling what the application is contained by or set up using, plus each server having specific callback hooks for startup and shutdown actions. All these server specific hooks and mechanisms just causes server lock in at a different level. I hate to think how many people out there can no longer move away from uWSGI because they have bought into all the uWSGI unique internal APIs. That approach has slowly been killing one of the benefits of WSGI which was portability. We need to start having a common abstraction for some of these hooks which servers are implementing differently if we are to avoid the bad old days where people can?t migrate between servers because they are dependent on server specific APIs. >> 1. An optionally updated WSGI specification labelled as WSGI 1.1. This has got nothing really to do with the initiative to have a way to handle WebSockets and HTTP/2. It would simply to be integrate changes which were raised the last time the WSGI specification was updated, but which were passed over because a PEP was in the end rushed through just to deal with Python 3, ignoring other concerns. There are only a few changes which this would cover. >> >> As I note above, this is optional. But if we are going to close out WSGI and not develop it further, would be nice to fix up some of the last problems with it. > > On a personal level, if the updated WSGI specification did nothing more than codify current WSGI practice that would be fine, but otherwise if we were intending to consider WSGI basically ?done? I don?t really see the advantage in revving the specification. If the view is that WSGI as-is will have one more change and then we?ll start looking to other approaches (be those other standardised gateway interfaces or less-standard all-inclusive frameworks that bundle their own servers), it?ll be hard to sell anyone on taking up the newly changed WSGI instead of investing time moving to the new world. As I said, like Python 2, WSGI is not going to go away soon. >> 2. Develop a higher level abstraction for what is a Python web application. Thus hooks for startup/shutdown, passing configuration from the server, or querying back configuration from the application pertaining to supported protocols, along with what sub URLs protocols are supported on, and where static file assets may be that application may want the server to handle if that would be more performant. >> >> I believe that such a new high level abstraction will provide a better framework to hang things off when we introduce new protocols. > > I can get behind this idea, though I view it as strictly optional and if no-one wants to implement it I think we should save ourselves the work! I guess no one is going to understand what benefit I see in this without actually implementing a proof of concept and illustrate how relatively simple an abstraction it is that I am really talking about. :-) >> 3. Separate WebSocket API. >> >> Basically ignore existing WSGI specification completely. Come up with the best API one can for WebSocket interaction at the server level. This should not just be exposing a socket, but be a higher level abstraction involving passing of actual WebSocket messages. >> >> By using higher level abstraction it allows a server to implement the details using whatever mechanisms best fit that server implementation. >> >> 4. Separate HTTP/2 API. >> >> Again, ignore existing WSGI specification complete. Come up with the best API one can for dealing with HTTP/2. >> >> For (3) and (4) lets do these as being our holy grail. Rather than compromise by trying to work with WSGI, lets first come up with what would be our ideal. Then lets see how that can fit within existing servers, possibly integrated via the richer application abstraction of (2). > > This seems like a reasonable approach: if the rest of the community is interested in it, I?d be happy to go along with it. > >> It isn?t clear what you expect this PEP to include, but trying to push for a PEP so quickly is unrealistic. There is likely going to need to be a fair bit of discussion and with the fact that people have real jobs, or other obligations, history has shown that rushing to a PEP just disenfranchises people and they will not contribute due to the inability to do so in too short a time frame. > > I apologise if I was unclear, but I am not pushing for a PEP anytime before the end of calendar year 2016. What I?m pushing for right now is to get people talking with the idea that we will keep taking steps forward. Sometime later this month or early next month I intend to stand up a porto-PEP (or more) that do nothing more than enumerate the goals of the work. That?ll give us a document to refer to going forward, but still give us time to work on concrete implementation and real problems. > > I am happy for this to take as long as it takes, but I?m also going to put light pressure on to keep moving forward, lest we get bogged down in discussion forever and produce nothing. > > Thanks so much for your feedback Graham! Graham -------------- next part -------------- An HTML attachment was scrubbed... URL: From armin.ronacher at active-4.com Tue Jan 5 06:50:41 2016 From: armin.ronacher at active-4.com (Armin Ronacher) Date: Tue, 5 Jan 2016 12:50:41 +0100 Subject: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest In-Reply-To: References: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> Message-ID: <568BAE11.30800@active-4.com> 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 HTTP headers to CGI-style environment > variables: if the server doesn?t specifically prevent it, X-Foo and > X_Foo both become HTTP_X_Foo. I don?t believe it?s a good choice to > destructively encode headers, expect applications to undo the damage > somehow, and introduce security vulnerabilities in the process. If > mimicking CGI is still considered a must-have ? 1% of current Python web > programmers may have heard about it, most of them from PEP 3333 ? then > that burden should be pushed onto the server, not the application. Headers always will have to be encoded destructively if you want any form of generic processing. We need header joining, we need to normalize the keys already at least to the extend of the HTTP specification. I'm happy to not perform the conversion of dashes to underscores but you will work in environments where this conversion was already done so the spec will need to deal with that case anyways. The WSGI spec currently also does not sufficiently explain how to join headers. In particular the cookie header was written without header joining in mind which is why it needs to be joined differently than all other headers. Header joining also comes up as a big topic in HTTP 2 so the spec will need to cover this. > 2. More generally, I fail to see how mixing HTTP headers, > server-related inputs, and environment variables in a dict adds > values. It prevents iterating on each collection separately. It only > makes sense if not offering more features than CGI is a design goal; > in that case, this discussion doesn?t serve a purpose anyway. It > would be nicer and possibly more secure if the application received > separately: I think this is largely a nice to have, not something that has any overall benefits. I rather just clean up the actual stupid things such as CONTENT_TYPE and CONTENT_LENGTH which cause a lot more real world friction than just the names of keys in general. This really should not turn into meaningless bikeshedding about what information should be called. Also consider how much code out there already assumes CGI/WSGI variables so any move off that really should have good reasons or we all will just waste enormous amounts just to transpose between the two representations. > a. Configuration information, which servers could read from > environment variables by default for backwards compatibility, but could > also get through more secure channels and restrict to what the > application needs in order to better isolate it from the entire OS. What WSGI traditionally lacked was a setup phase where data could be passed to the application that was server specific but not request bound. For instance there is no reason an application cannot get hold of wsgi.errors before a request comes in. I would like to see this fixed in a new specification. > 3. Stop pretending that HTTP is a unicode protocol, or at least stop > ignoring reality when doing so. WSGI enforces ISO-8859-1-decoded str > objects in the environ, which is just wrong. It?s all the more a > surprising choice since this change was driven by Python 3, that UTF-8 > is the correct choice, and that Python 3 defaults to UTF-8. Django has > to re-encode and re-decode before doing anything with HTTP headers: I agree with this but you will have to have that fight with others. I said many times before that values should never have been unicode values in the first place but certain decisions in the Python 3 standard library at the time prevented that. In particular until 3.2 or so it was impossible to parse byte URLs. > 5. Improve request / response length handling and connection closure. > Armin and Graham have talked about in the past and know the topic > better than I do. There?s also a rejected PEP by Armin which made > sense to me. I think last time I discussed that with Graham it was not clear what the solution is in the context of WSGI. The idea that there is a content-length is laughable in the context of a real application where the server is performing conversions on the input and output stream. We would need many more than just one content length and an automatically terminated input stream. However at that point you will quickly realize that you can't have it both ways and you either have a WSGI like protocol, or raw access to sockets but certainly not both. This topic has caused a lot of bikeshedding in the past and I fail to see how it will be differently this time. My current thinking is that the most realistic approach to most of those problems will be the concept of framing on both the input and output side. That's somewhat compatible with both chunked transports well as websockets. But if we do go down this road we will most likely have to standardize on a library that implements WSGI as the complexity of dealing with this sort of stuff is significantly higher than what we had to do in the past. Regards, Armin From graham.dumpleton at gmail.com Tue Jan 5 07:02:05 2016 From: graham.dumpleton at gmail.com (Graham Dumpleton) Date: Tue, 5 Jan 2016 23:02:05 +1100 Subject: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest In-Reply-To: References: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> Message-ID: <71CDDD53-C725-4103-954B-1576B165F9C0@gmail.com> > 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. 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 WebSockets, don?t start with design decisions anchored in CGI. Figure out what a simple and flexible API for these new protocols would be, specify it, implement it, and make sure it degrades gracefully to HTTP/1. You may be able to channel most of the communication through a single generator, but it?s unclear to me that this will be the most convenient design. >> >> If you want to improve WSGI, here?s a list of mistakes or shortcomings in PEP 3333 that you can take a stab at. There?s a general theme: for a specification that looks at the future, I believe that making modern PaaS-based deployments secure by default matters more than not implementing anything beyond what?s available in legacy CGI-based deployments. >> >> 1. WSGI is prone to header injection vulnerabilities issues by design due to the conversion of HTTP headers to CGI-style environment variables: if the server doesn?t specifically prevent it, X-Foo and X_Foo both become HTTP_X_Foo. I don?t believe it?s a good choice to destructively encode headers, expect applications to undo the damage somehow, and introduce security vulnerabilities in the process. If mimicking CGI is still considered a must-have ? 1% of current Python web programmers may have heard about it, most of them from PEP 3333 ? then that burden should be pushed onto the server, not the application. > > FWIW, Apache 2.4 will discard headers which would use underscore, as well as many other characters. Basically it probably only accepts alphanumeric and ?-? in original name. > > In mod_wsgi, it does the same thing, even for Apache 2.2 where it wasn?t done. > > So with mod_wsgi at least you are safe. Or at least if not still using some ancient mod_wsgi version. (Death to LTS Linux versions and out of date packages) :-) > > The nginx server if used as a front end and where it is populating CGI like variables for passing to a builtin module such as uWSGI will also I believe discard headers which don?t match that requirement as well. > > I can?t remember if gunicorn was updated to do something similar, or whether when uWSGI isn?t used behind nginx via its uwsgi protocol, but instead listens publicly via HTTP whether it does it either. I should clarify a point here. Apache 2.4 will discard the headers at the point of converting them to a CGI like environment when a handler asks for a CGI like set of variables. Raw headers will always be passed through as they were. Graham -------------- next part -------------- An HTML attachment was scrubbed... URL: From graham.dumpleton at gmail.com Tue Jan 5 06:57:57 2016 From: graham.dumpleton at gmail.com (Graham Dumpleton) Date: Tue, 5 Jan 2016 22:57:57 +1100 Subject: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest In-Reply-To: References: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> Message-ID: > 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 convictions as Graham Dumpleton. If you want to support HTTP/2 and WebSockets, don?t start with design decisions anchored in CGI. Figure out what a simple and flexible API for these new protocols would be, specify it, implement it, and make sure it degrades gracefully to HTTP/1. You may be able to channel most of the communication through a single generator, but it?s unclear to me that this will be the most convenient design. > > If you want to improve WSGI, here?s a list of mistakes or shortcomings in PEP 3333 that you can take a stab at. There?s a general theme: for a specification that looks at the future, I believe that making modern PaaS-based deployments secure by default matters more than not implementing anything beyond what?s available in legacy CGI-based deployments. > > 1. WSGI is prone to header injection vulnerabilities issues by design due to the conversion of HTTP headers to CGI-style environment variables: if the server doesn?t specifically prevent it, X-Foo and X_Foo both become HTTP_X_Foo. I don?t believe it?s a good choice to destructively encode headers, expect applications to undo the damage somehow, and introduce security vulnerabilities in the process. If mimicking CGI is still considered a must-have ? 1% of current Python web programmers may have heard about it, most of them from PEP 3333 ? then that burden should be pushed onto the server, not the application. FWIW, Apache 2.4 will discard headers which would use underscore, as well as many other characters. Basically it probably only accepts alphanumeric and ?-? in original name. In mod_wsgi, it does the same thing, even for Apache 2.2 where it wasn?t done. So with mod_wsgi at least you are safe. Or at least if not still using some ancient mod_wsgi version. (Death to LTS Linux versions and out of date packages) :-) The nginx server if used as a front end and where it is populating CGI like variables for passing to a builtin module such as uWSGI will also I believe discard headers which don?t match that requirement as well. I can?t remember if gunicorn was updated to do something similar, or whether when uWSGI isn?t used behind nginx via its uwsgi protocol, but instead listens publicly via HTTP whether it does it either. > 2. More generally, I fail to see how mixing HTTP headers, server-related inputs, and environment variables in a dict adds values. It prevents iterating on each collection separately. It only makes sense if not offering more features than CGI is a design goal; in that case, this discussion doesn?t serve a purpose anyway. It would be nicer and possibly more secure if the application received separately: > > a. Configuration information, which servers could read from environment variables by default for backwards compatibility, but could also get through more secure channels and restrict to what the application needs in order to better isolate it from the entire OS. I have always had a bit of a beef with the way that the use of environment variables for configuration was promoted by the 12 factor manifesto. It grew out of how a specific hosting service did things and ignored that various web servers used configuration files instead or did things in other ways. Of course the hosting service made it difficult to impossible to use some of those traditional web servers, so they were safe in their narrow view of things. Anyway, if environment variables were used where appropriate and with an intermediate mapping layer within Python web applications that would have been fine. The problem was that you started to see direct lookup of environment variables deep in code bases. So people wedded themselves to use of environment variables. The more sensible thing to do would have been to use an intermediate Python module/package providing an abstraction layer for getting configuration. Code would then use that. The configuration layer could then look up environment variables or use other means to get configuration, such as from more traditional configuration files, or pulling it done from configuration servers. As far as I know there is no good Python package out there which serves as such a intermediary configuration system which could be plugged into any application and which doesn?t carry a huge amount of baggage. Would love to hear about one if it exists. > b. Server APIs mandated by the spec, per request. > c. HTTP headers, per request. > > 3. Stop pretending that HTTP is a unicode protocol, or at least stop ignoring reality when doing so. WSGI enforces ISO-8859-1-decoded str objects in the environ, which is just wrong. It?s all the more a surprising choice since this change was driven by Python 3, that UTF-8 is the correct choice, and that Python 3 defaults to UTF-8. Django has to re-encode and re-decode before doing anything with HTTP headers: https://github.com/django/django/blob/d5b90c8e120687863c1d41cf92a4cdb11413ad7f/django/core/handlers/wsgi.py#L231-L253 WSGI uses ISO-8859-1 with raw bytes because there is no guarantee about what the encoding might be for certain inbound headers due to clients ignoring the ASCII requirement and using what they please. A header value may well be UTF-8 these days, but technically it could also be some obscure Japanese encoding. Ultimately there was no way the WSGI server could know for sure what the encoding of some header values could be. The only place that knew this for sure was the web application itself. This is why it ended up as ISO-8859-1 encoded raw bytes. There would be quite a lot of discussion about this topic back in the Web-SIG archives somewhere. > 4. Normalize the way to tell the application about the original protocol, IP address and port. When dev and ops responsibilities are separate, this is clearly an ops responsibility, but due to the lack of standardization devs end up dealing with this problem in custom middleware, when they do it at all. Everyone keeps getting it wrong, which introduces security vulnerabilities. Also it always breaks silently on infrastructure changes. FWIW, I came to the conclusion that it is the responsibility of the WSGI server to translate any proxy forwarding headers. As you say, if you leave it up to WSGI applications or middleware it becomes a mess and is usually wrong. If you dig into the mod_wsgi code I have all these capabilities now where you can tell mod_wsgi what are the trusted proxy headers from your proxy and also what are trusted proxy IP addresses or address ranges. With that mod_wsgi will then update various stuff that goes into the WSGI environ and deletes all the headers which weren?t marked as trusted so that WSGI middleware or applications then don?t incorrectly use them. I talked a bit about this in a blog post: http://blog.dscpl.com.au/2015/06/proxying-to-python-web-application.html Unfortunately I haven?t updated it to support the new ?Forwarded? header yet, which I should do. Common to a common understanding of what should be done in this space and have all WSGI servers provide the same functionality would be nice. > 5. Improve request / response length handling and connection closure. Armin and Graham have talked about in the past and know the topic better than I do. There?s also a rejected PEP by Armin which made sense to me. > > As you can see from these comments, I don?t quite share the design choices that led to WSGI as it currently stands. I think it will be easier to build a new standard than evolve the current one. > > I hope this helps! > > Aymeric > _______________________________________________ > Web-SIG mailing list > Web-SIG at python.org > Web SIG: http://www.python.org/sigs/web-sig > Unsubscribe: https://mail.python.org/mailman/options/web-sig/graham.dumpleton%40gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From L.Plant.98 at cantab.net Tue Jan 5 07:09:59 2016 From: L.Plant.98 at cantab.net (Luke Plant) Date: Tue, 5 Jan 2016 12:09:59 +0000 Subject: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest In-Reply-To: References: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> Message-ID: <568BB297.5060906@cantab.net> 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 made things harder for us. We would much rather have dealt with raw streams of bytes and done all HTTP parsing ourselves. Like Graham said, for HTTP/2 let's ignore the history of WSGI and start from scratch with a API that actually serves us well. Regards, Luke On 05/01/16 11:26, 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 convictions as Graham Dumpleton. If you want to support HTTP/2 and WebSockets, don?t start with design decisions anchored in CGI. Figure out what a simple and flexible API for these new protocols would be, specify it, implement it, and make sure it degrades gracefully to HTTP/1. You may be able to channel most of the communication through a single generator, but it?s unclear to me that this will be the most convenient design. > > If you want to improve WSGI, here?s a list of mistakes or shortcomings in PEP 3333 that you can take a stab at. There?s a general theme: for a specification that looks at the future, I believe that making modern PaaS-based deployments secure by default matters more than not implementing anything beyond what?s available in legacy CGI-based deployments. > > 1. WSGI is prone to header injection vulnerabilities issues by design due to the conversion of HTTP headers to CGI-style environment variables: if the server doesn?t specifically prevent it, X-Foo and X_Foo both become HTTP_X_Foo. I don?t believe it?s a good choice to destructively encode headers, expect applications to undo the damage somehow, and introduce security vulnerabilities in the process. If mimicking CGI is still considered a must-have ? 1% of current Python web programmers may have heard about it, most of them from PEP 3333 ? then that burden should be pushed onto the server, not the application. > > 2. More generally, I fail to see how mixing HTTP headers, server-related inputs, and environment variables in a dict adds values. It prevents iterating on each collection separately. It only makes sense if not offering more features than CGI is a design goal; in that case, this discussion doesn?t serve a purpose anyway. It would be nicer and possibly more secure if the application received separately: > > a. Configuration information, which servers could read from environment variables by default for backwards compatibility, but could also get through more secure channels and restrict to what the application needs in order to better isolate it from the entire OS. > b. Server APIs mandated by the spec, per request. > c. HTTP headers, per request. > > 3. Stop pretending that HTTP is a unicode protocol, or at least stop ignoring reality when doing so. WSGI enforces ISO-8859-1-decoded str objects in the environ, which is just wrong. It?s all the more a surprising choice since this change was driven by Python 3, that UTF-8 is the correct choice, and that Python 3 defaults to UTF-8. Django has to re-encode and re-decode before doing anything with HTTP headers: https://github.com/django/django/blob/d5b90c8e120687863c1d41cf92a4cdb11413ad7f/django/core/handlers/wsgi.py#L231-L253 > > 4. Normalize the way to tell the application about the original protocol, IP address and port. When dev and ops responsibilities are separate, this is clearly an ops responsibility, but due to the lack of standardization devs end up dealing with this problem in custom middleware, when they do it at all. Everyone keeps getting it wrong, which introduces security vulnerabilities. Also it always breaks silently on infrastructure changes. > > 5. Improve request / response length handling and connection closure. Armin and Graham have talked about in the past and know the topic better than I do. There?s also a rejected PEP by Armin which made sense to me. > > As you can see from these comments, I don?t quite share the design choices that led to WSGI as it currently stands. I think it will be easier to build a new standard than evolve the current one. > > I hope this helps! > > Aymeric > > > _______________________________________________ > Web-SIG mailing list > Web-SIG at python.org > Web SIG: http://www.python.org/sigs/web-sig > Unsubscribe: https://mail.python.org/mailman/options/web-sig/l.plant.98%40cantab.net -- "Trouble: Luck can't last a lifetime, unless you die young." (despair.com) Luke Plant || http://lukeplant.me.uk/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From armin.ronacher at active-4.com Tue Jan 5 07:14:28 2016 From: armin.ronacher at active-4.com (Armin Ronacher) Date: Tue, 5 Jan 2016 13:14:28 +0100 Subject: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest In-Reply-To: <568BB297.5060906@cantab.net> References: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> <568BB297.5060906@cantab.net> Message-ID: <568BB3A4.6060602@active-4.com> 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 - and semi-broken unicode > handling) only made things harder for us. We would much rather have > dealt with raw streams of bytes and done all HTTP parsing ourselves. > > Like Graham said, for HTTP/2 let's ignore the history of WSGI and start > from scratch with a API that actually serves us well. Alright. I bite: if it would not be done that way you had different problems. In particular a problem that comes up very often is that people want the PATH_INFO and SCRIPT_NAME to not be encoded. That however completely breaks any form of routing you would want to do the moment they contain unicode characters. I keep having the argument about PATH_INFO and the header semantics constantly with people and i'm absolutely convinced (from the theory behind it as well as playing around with ideas for PEP 444 a few years ago) that it only gets worse the moment you leave the WSGI territory too far. Likewise I wonder how many people that ask for more low level access concerned themselves with chunked requests/responses, transport encodings and all the complexity that servers do for you. Yes, quite a bit of this is broken in WSGI but would have been trivial to fix without throwing the whole specification into the toilette :) Regards, Armin From chris.dent at gmail.com Tue Jan 5 08:09:33 2016 From: chris.dent at gmail.com (chris.dent at gmail.com) Date: Tue, 5 Jan 2016 13:09:33 +0000 (GMT) Subject: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest In-Reply-To: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> References: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> Message-ID: 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 something-else-that-is-not-WSGI should be prepared that addresses modern protocols and programming paradigms. ---- I should disclaim myself by saying that I entered enter web programming prior to the existence of Perl's CGI.pm, so I have a biased mental model about how the web? ought to work that is not well aligned with current practices. The experience greatly informs my thinking on this stuff, not necessarily in a good way. To me the best thing about WSGI, at least in the early days, was how it created an accessible environment for doing web stuff. It was so successful that many other languages felt left out and made their own similar interfaces. Like most successful technologies what made it a success was not the capabilities it provided but the constraints it imposed. To the application developer WSGI is relatively simple. For old school web stuff this works great: get some headers, get some request body, do some work, send some headers, send a response body. That's nice. If you're really feeling fancy you can nest another app in the "do some work" part. That's nice too. There's a temptation with the advent of new technologies and practices to forget the value of constraints and want to provide knobs for all the cool stuff. While I think we need to address the new use cases, we need to be careful to keep it tidy. Keeping things tidy is going to be hard. The request-then-response handling in most of WSGI is tidy because it models itself as a _gateway_; there's a clear boundary. To get benefits from HTTP/2, WebSockets and async programming models the gateway model isn't going to apply. So what to do? I think we need to do two separate things. One is to fix WSGI in some lightweight fashion. The other is to create something new that supports the new stuff but learns from what WSGI has done well (perhaps more in terms of constraints and social context than specific techniques). 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 access the raw un-decoded request URI. This is so I can reconstruct a realistic `PATH_INFO` that has not been subjected to destructive handling by the server (e.g. apache messing with `%2F`) before continuing on to a route dispatcher. * More consistent guidelines on string handling in headers. I'm aware of the discussion around ISO-8859-1 and I think it is just wrong. At the level of my simple application the header values should either be strings (unicode) or UTF-8 encoded bytes. Nothing else. If somebody sends the wrong thing it is their fault, not mine, they should get the pain not me. I realize that this is not entirely a WSGI issue, but it is something I'd like WSGI to help me with. For WSGI, that's probably enough (for me). It has been and will continue to be a very useful tool for many years to come. For "simple" web apps it is _great_ and we're still going to want and need those for a long time. For applications that want to take advantage of asynchrony, we should make something new, probably coroutine-based. I'm insufficiently up on the state of the art these days to go into too much detail but some things I think worth considering are: * Corey gave a presentation at PyconUK about layering tools like an onion. Requests is the canonical example: requests over urllib3 over http libraries over socket libraries. I suspect a modern web services interface is going to need to provide ways to escape down to lower layers to satisfy all use cases but will need to have a fairly simple top layer to have any adoption. This is something that will need to built into the specification otherwise each implementation will come up with its own way and portability and server independence that was key to WSGI's success will not be there. * Avoid complexity with regard to byte and string handling by being Python 3 only. This also avoids complexity with regards to asycnio. It's basically a statement of "if you want to do the new stuff, you got to use the new stuff". I think that's a fair requirement. * I like, very much, that the interface to WSGI is a callable with a very simple signature and response. I'd be disappointed if the signature of the new thing was something other than primitives. Thanks for getting this ball rolling, again. It can be challenging when it has been visited so many times. I think making a clean break to create something new, while still acknowledging the continued usefulness of the old, is the way to go. -- Chris Dent http://burningchrome.com/ [...] From bchesneau at gmail.com Tue Jan 5 08:13:17 2016 From: bchesneau at gmail.com (Benoit Chesneau) Date: Tue, 05 Jan 2016 13:13:17 +0000 Subject: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest In-Reply-To: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> References: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> Message-ID: 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 the way HTTP2 has been designed it can be considered as an extension of HTTP 1.x, keeping the API fixing the following the connections latency and server resource usages. Grosso modo, the specifications can be split in 3 keys point - binary protocol - connections multiplexing, handling more than one 1 request / sockets - server PUSH to somehow "pre-send" data on request to reduce the latency Header formats which are btw US-ASCII in the HTTP spec now, could be already solved if only the frameworks could comply with the spec instead of trying to impose their own rules. Websockets or async things are outside the spec. All the points above are server side. Behind that the application is actually doing the same stateless request/response path. Framing/Decoding is the responsability of the server and should be hidden to the application. The only addition on the application side is the possibility to push. 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) - tell to the application the request id it is actually answering when receiving the data (it will be the the responsability of the application to handle it, asynchronously or not, using asyncio or not, greenlets, threads, whatever). The server by itself will only process callbacks like it is now. - expose an API to handle the PUSH api . mostly a way to buffer it on the server so it can be sent ASAP to the remote client Besides that I think WSGI 2 is missing the following: - an UPGRADE api, allowing an application to actually take the client socket control and do anything with it. In gunicorn it is handled by providing the raw socket in the environ and tell to gunicorn it can now ignore this socket: https://github.com/benoitc/gunicorn/blob/master/examples/websocket/websocket.py#L115 This is useful if an app wants to handle websockets, provides a W3C PUSH api, ... - a clear standard to provide to the application the raw URI. Again Gunicorn is providing it via the environnement using the `RAW_URI` setting. - a better way to tell the application it is actually responding (or want to answer) with chunked encoding data or stream data. Note that actually there is nothing stopping a WSGI server to handle them. Gunicorn is actually streaming any data and decode chunks on the fly. Also it is encoding for the application if the header is present. Using the FileWrapper api it works quite well. Maybe though we could improve it by providing a Stream object to distinct it from a File. So for example, the server don't have to check if it can use sendfile over it or not, which proved to be annoying across the different python version (also not efficient). It could also be used to add on server side some stuff like zero-copy and so on. Also I think a new spec must make it clear that the server should not have to be aware about the way the application is handling the request and respond to them ie asynchronously or not, using threads or not. The protocol/api should be stateless. And the application must maintains it own state without any expectation on the way the server maintain it. By that I mean that lot of people are surprised to not be able to share a pool between all the requests in gunicorn because they don't use a thread-safe (and process safe) pool. This should be part of the expectation given by the spec imo. Maybe as an extra, we should define more clearly what is a WSGI middleware. Any feedback is welcome. - beno?t. On Mon, Jan 4, 2016 at 1: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 attempted to do this > last year with Rob Collins leading the charge, but unfortunately personal > commitments made it impossible for Rob to keep pushing that attempt forward. > > Since then, the need for a revision of WSGI has become even more apparent. > Casual discussion on the web has indicated that application developers are > uncomfortable with the limitations of WSGI. These limitations are providing > an incentive for both application developers and server developers to take > an end-run around WSGI in an attempt to get a framework that is more > suitable for the modern web. A great example of the result of WSGI?s > deficiencies is Andrew Godwin?s channels work[0] for Django, which > represents a paradigm shift in application development that takes it far > away from what WSGI is today. > > For this reason, I think we need to try again to get WSGI 2.0 off the > ground. But I don?t believe we can do this without getting broad consensus > from the developer community that a revision to WSGI is needed, and without > understanding what developers need from a new revision of WSGI. This should > take into account the prior discussions we?d had on this thread: however, > I?m also going to actively solicit feedback from some of the more notable > WSGI implementers, to ensure that whatever comes out of this SIG is > something that they would actually use. > > This WG already had a list of requirements, which are as follows: > > - Support servers speaking HTTP/1.x, HTTP/2 and Websockets (potentially > all on a single port). > - Support graceful degradation for applications that can use HTTP/2 but > still support HTTP/1.x requests. > - Graceful incremental adoption path - no upgrade-all-components > requirement baked into the design. > - Support Python 2.7 and 3.x (where x is not yet discussed) > - Support the existing ecosystem of containers (such as mod_wsgi) with the > new API. We want a clean, fast and approachable API, and we want to ensure > that its no less friendly to work with than WSGI, for all that it will > expose much more functionality. > - Apps need to be able to tell what protocol is in use, and what optional > features are available. For instance, HTTP/2 PUSH PROMISE is an optional > feature that can be disabled by clients. Websockets needs to expose a > socket like object, and so on. > - Support websockets > - Support HTTP/2 > - Support HTTP/1.x (which may be just 'point at PEP-3333?.) > - Continue to support lightweight shims being built on top such as > https://github.com/Pylons/webob/blob/master/webob/request.py > > I believe that all of these requirements are up for grabs, and subject to > change and consensus discussion. In this thread, then, I?d like to hear > from people about these requirements and others. What do you believe WSGI > 2.0 should do? Just as importantly, what do you believe it should not do? > What prior art should we take into account? Should we bother revising WSGI > at all, or should we let the wider application ecosystem pursue its own > solutions ? la Django's channels? Should we simply adopt Andrew Godwin?s > ASGI draft[1] on which channels is based and call *that* WSGI 2.0? > > Right now I want this to be very open. I?d like people to come up with a > broad statement listing what they believe should and should not be present > in WSGI. This first stage of the work is very general: I just want to get a > feeling for what the community believes is important. Once we?re done with > that, if the consensus is that this work is worth pursuing, I?ll come up > with an initial draft that we can start making concrete changes to. > > In the short term, I?m going to keep this consultation open for **at least > two weeks**: that is, I will not start working on an initial draft PEP > until at least the **18th of January**. If you believe there are > application or server developers that should be involved in this > discussion, please reach out to them and point them to this list. I > personally have CC?d some people that I believe need to be involved in the > discussion, but please reach out to others as well. > > I?d really love to come to the end of 2016 with a solid direction for the > future of web programming in Python. I?m looking forward to working with > you all on achieving that. > > Thanks, > > Cory > > > [0]: https://channels.readthedocs.org/en/latest/ > [1]: https://channels.readthedocs.org/en/latest/asgi.html > _______________________________________________ > Web-SIG mailing list > Web-SIG at python.org > Web SIG: http://www.python.org/sigs/web-sig > Unsubscribe: > https://mail.python.org/mailman/options/web-sig/bchesneau%40gmail.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From graham.dumpleton at gmail.com Tue Jan 5 17:19:15 2016 From: graham.dumpleton at gmail.com (Graham Dumpleton) Date: Wed, 6 Jan 2016 09:19:15 +1100 Subject: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest In-Reply-To: References: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> Message-ID: <3576FCA3-00F9-431B-9D6C-D99ED9C5E984@gmail.com> > On 6 Jan 2016, at 12:09 AM, chris.dent at 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 access the raw un-decoded request URI. This is > so I can reconstruct a realistic `PATH_INFO` that has not been > subjected to destructive handling by the server (e.g. apache > messing with `%2F`) before continuing on to a route dispatcher. This is already available in some servers by way of the REQUEST_URI value. This is the original first line of any HTTP request and can be split apart to get the path. The problem is that you cannot easily use it unless you want to replicate normalisations that the underlying server may do. The key problem is working out where SCRIPT_NAME ends and PATH_INFO starts with the original path given in REQUEST_URI. Sure if you only deal with a web application mounted at the root of the host it is easier because SCRIPT_NAME would be empty, but when mounted at a sub URL it gets trickier. This is because a web server will eliminate things like repeating slashes in the part of the path that may match the mount point (sub url) for the web application. The sub url here could be dictated by what is defined in a configuration file, or could instead be due to matching against a file system path. Further, the web server will eliminate attempts at relative directory traversal using ?..? and ?.?. So an original path may be something like: /a/b//c/../d/.//e/../f/g/h If the mount point was ?/a/b/d?, then that is what gets passed through SCRIPT_NAME. Now if you instead go to the raw path you would need to replicate all the normalisations. Only then could you maybe based on length of SCRIPT_NAME, number of component parts, or actual components in the path, try and calculate where SCRIPT_NAME ended and PATH_INFO started in the raw path. This will still all fail if a web server does internal rewrites though, as the final SCRIPT_NAME may not even match the raw path, although at that point URL reconstruction can be a problem as well if what the application is given by way of the rewrite isn?t a public path. I have only looked at SCRIPT_NAME. Even in PATH_INFO servers will apply same sort of normalisations. So even this isn?t so simple to do properly if you want to go back and do it yourself using the raw path. I have never seen anyone trying to extract repeating slashes intact out of a raw path even attempt to do it properly. They tend to assume that the raw path is pure and doesn?t have stuff in it which needs to be normalised and that rewrites aren?t occurring. As a result they assume that they can just strip number of characters off raw path based on length of SCRIPT_NAME passed through. This will be fragile though if the raw path isn?t pure. Graham -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.dent at gmail.com Tue Jan 5 17:27:54 2016 From: chris.dent at gmail.com (chris.dent at gmail.com) Date: Tue, 5 Jan 2016 22:27:54 +0000 (GMT) Subject: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest In-Reply-To: <3576FCA3-00F9-431B-9D6C-D99ED9C5E984@gmail.com> References: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> <3576FCA3-00F9-431B-9D6C-D99ED9C5E984@gmail.com> Message-ID: On Wed, 6 Jan 2016, Graham Dumpleton wrote: > >> On 6 Jan 2016, at 12:09 AM, chris.dent at 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 access the raw un-decoded request URI. This is >> so I can reconstruct a realistic `PATH_INFO` that has not been >> subjected to destructive handling by the server (e.g. apache >> messing with `%2F`) before continuing on to a route dispatcher. > > This is already available in some servers by way of the REQUEST_URI value. Yes, and in others (as mentioned by Benoit) as RAW_URI. One ("consistent") way would be better. [Lots of good information about the challenges associated with using that information to do anything useful, deleted.] What I've done in one app is this: https://github.com/tiddlyweb/tiddlyweb/blob/cc6b67d2855ea4d8d908f1a3e58db0dce7e8d138/tiddlyweb/web/serve.py#L119 Despite the fact that that is not strictly correct, it does mostly work for the situation described in the comment and the context of that app. One of the things I want from a light rev of WSGI is not to have to jump through those hoops. It may be that's not feasible but I reckon we're at the wishing stage of the discussion. -- Chris Dent http://burningchrome.com/ [...] From graham.dumpleton at gmail.com Tue Jan 5 17:37:34 2016 From: graham.dumpleton at gmail.com (Graham Dumpleton) Date: Wed, 6 Jan 2016 09:37:34 +1100 Subject: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest In-Reply-To: <3576FCA3-00F9-431B-9D6C-D99ED9C5E984@gmail.com> References: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> <3576FCA3-00F9-431B-9D6C-D99ED9C5E984@gmail.com> Message-ID: <764F92B7-4C45-4AA4-A505-A2A825D1235E@gmail.com> > On 6 Jan 2016, at 9:19 AM, Graham Dumpleton wrote: > >> On 6 Jan 2016, at 12:09 AM, chris.dent at 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 access the raw un-decoded request URI. This is >> so I can reconstruct a realistic `PATH_INFO` that has not been >> subjected to destructive handling by the server (e.g. apache >> messing with `%2F`) before continuing on to a route dispatcher. > > This is already available in some servers by way of the REQUEST_URI value. > > This is the original first line of any HTTP request and can be split apart to get the path. Whoops. My foggy memory. REQUEST_URI is only raw path part, not the whole request line with method, protocol and path. Graham -------------- next part -------------- An HTML attachment was scrubbed... URL: From graham.dumpleton at gmail.com Tue Jan 5 17:50:21 2016 From: graham.dumpleton at gmail.com (Graham Dumpleton) Date: Wed, 6 Jan 2016 09:50:21 +1100 Subject: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest In-Reply-To: References: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> <3576FCA3-00F9-431B-9D6C-D99ED9C5E984@gmail.com> Message-ID: <9E1A7398-5C42-4BA5-B979-53002BE1405D@gmail.com> > On 6 Jan 2016, at 9:27 AM, chris.dent at gmail.com wrote: > > On Wed, 6 Jan 2016, Graham Dumpleton wrote: > >> >>> On 6 Jan 2016, at 12:09 AM, chris.dent at 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 access the raw un-decoded request URI. This is >>> so I can reconstruct a realistic `PATH_INFO` that has not been >>> subjected to destructive handling by the server (e.g. apache >>> messing with `%2F`) before continuing on to a route dispatcher. >> >> This is already available in some servers by way of the REQUEST_URI value. > > Yes, and in others (as mentioned by Benoit) as RAW_URI. One > ("consistent") way would be better. > > [Lots of good information about the challenges associated with using > that information to do anything useful, deleted.] > > What I've done in one app is this: > https://github.com/tiddlyweb/tiddlyweb/blob/cc6b67d2855ea4d8d908f1a3e58db0dce7e8d138/tiddlyweb/web/serve.py#L119 > > Despite the fact that that is not strictly correct, it does mostly work > for the situation described in the comment and the context of that > app. One of the things I want from a light rev of WSGI is not to have > to jump through those hoops. > > It may be that's not feasible but I reckon we're at the wishing > stage of the discussion. Yeah, that code would have problems. One other thing just remembered is that technically it is allowed that the path part of the request line can actually be a URI. GET http://hostname/a/b/c HTTP/1.0 This would yield: REQUEST_URI: 'http://hostname/a/b/c' SCRIPT_NAME: ?' PATH_INFO: '/a/b/c? Obviously I didn?t even mention the % encoding issues as part of SCRIPT_NAME part as you are obviously aware of those being an issue in PATH_INFO at least. Lots of fun. Graham -------------- next part -------------- An HTML attachment was scrubbed... URL: From bchesneau at gmail.com Wed Jan 6 04:13:01 2016 From: bchesneau at gmail.com (Benoit Chesneau) Date: Wed, 06 Jan 2016 09:13:01 +0000 Subject: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest In-Reply-To: <62e8abdf-5d44-49d1-b034-c0b923bc80be@googlegroups.com> References: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> <62e8abdf-5d44-49d1-b034-c0b923bc80be@googlegroups.com> Message-ID: On Tue, Jan 5, 2016 at 3:17 PM Aymeric Augustin < aymeric.augustin.2003 at 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 frameworks could comply with the spec instead of >> trying to impose their own rules. >> > > That's just a detail, but either I misunderstood you or you blamed the > wrong side here. > > Non-ASCII data in request headers isn't a problem created by frameworks, > it's a problem created by (possibly non compliant) user-agents. > I had in mind this ticket: https://github.com/benoitc/gunicorn/issues/1151 As of today, because some applications are still sending response in a a non compliant way we are trying to recode the headers on the server side so we can send them. Today like in apache 2 (and I think nginx) we now just ignore headers that can't be encoded in us-ascii. If all applications/framework would give us the headers as Latin1 it wouldn't be a major problem, but that's not the case. > > If future-WSGI guaranteed that HTTP header values provided in environ only > contain ASCI, fameworks would be happy. Servers would likely have to > respond 400 to requests containing non-ASCII headers, which would likely be > considered a problematic backwards-incompatibility. It would go against the > IETF principle of being tolerant in what a system accepts. > We should also update the spec to reflect the latest changes in the HTTP specs to force applications to send to the gateway US-ASCII headers. > > If future-WSGI provided header values as bytes, frameworks would be happy > as well. That would be my preference, because the application is in the > best position to pick a charset for decoding the values (that would be > UTF-8 in general). > > If future-WSGI insists on decoding header values with an arbitrary > encoding, I believe it should do so with UTF-8 rather than ISO-8859-1. "The > server is decoding with ISO-8859-1 so the application can reencode to get > the raw bytes" never sounded like a compelling argument to me. It will > still be wrong in theory, but it will generally give the right results in > practice. > Hmm but, actually the HTTP spec insist that headers are neither utf-8, neither latin1 (iso8859-1) but US-ASCII: https://github.com/benoitc/gunicorn/issues/1151#issuecomment-158884740 so native strings or bytes are fine for me until we make sure that we are sending and receiving US-ASCII. > Best regards, > > > -- > Aymeric. > > PS: if you find Django trying to impose its own rules, I'll do my best to > correct that. As much as I can speak for the Django team, this isn't our > intent. Please flag such cases so we can make sure there's no > misunderstanding. Thanks! > > Thanks! I will if needed :) - beno?t -------------- next part -------------- An HTML attachment was scrubbed... URL: From graham.dumpleton at gmail.com Wed Jan 6 04:29:27 2016 From: graham.dumpleton at gmail.com (Graham Dumpleton) Date: Wed, 6 Jan 2016 20:29:27 +1100 Subject: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest In-Reply-To: References: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> Message-ID: > 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 already get: SERVER_PROTOCOL: 'HTTP/1.1? Under HTTP/2 when I tested some time back, I recollect it came through as one would assume would be expected: SERVER_PROTOCOL: ?HTTP/2? Is there any reason that this existing CGI variable wouldn?t be sufficient for this purpose? Graham -------------- next part -------------- An HTML attachment was scrubbed... URL: From bchesneau at gmail.com Wed Jan 6 04:29:27 2016 From: bchesneau at gmail.com (Benoit Chesneau) Date: Wed, 06 Jan 2016 09:29:27 +0000 Subject: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest In-Reply-To: <12706115-6740-4E03-A1CA-12678F1700CB@polytechnique.org> References: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> <62e8abdf-5d44-49d1-b034-c0b923bc80be@googlegroups.com> <12706115-6740-4E03-A1CA-12678F1700CB@polytechnique.org> Message-ID: On Wed, Jan 6, 2016 at 10:19 AM Aymeric Augustin < aymeric.augustin at 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 stronger requirements. > > In general this is a bit of a mess due to differences between what the RFC > 2616 says and what browsers do in practice. That?s why I believe the > pragmatic solution is to exchange bytes. (This isn?t a major issue in the > grand scheme of things anyway.) > > Best regards, > > -- > Aymeric. > > Since sockets are only accepting bytes in python 3.x, having everything as bytes would also allow the server to process the response more easily... - beno?t -------------- next part -------------- An HTML attachment was scrubbed... URL: From bchesneau at gmail.com Wed Jan 6 04:31:24 2016 From: bchesneau at gmail.com (Benoit Chesneau) Date: Wed, 06 Jan 2016 09:31:24 +0000 Subject: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest In-Reply-To: References: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> Message-ID: 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 true env) > > > In CGI implementations you would for HTTP/1.1 already get: > > SERVER_PROTOCOL: 'HTTP/1.1? > > Under HTTP/2 when I tested some time back, I recollect it came through as > one would assume would be expected: > > SERVER_PROTOCOL: ?HTTP/2? > > Is there any reason that this existing CGI variable wouldn?t be sufficient > for this purpose? > > Graham > True. I don't think there is a need for another env. The current way also work for the future :) - beno?t -------------- next part -------------- An HTML attachment was scrubbed... URL: From graham.dumpleton at gmail.com Wed Jan 6 04:48:01 2016 From: graham.dumpleton at gmail.com (Graham Dumpleton) Date: Wed, 6 Jan 2016 20:48:01 +1100 Subject: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest In-Reply-To: <32B5F7C6-CF71-4CB5-8342-92D1813A6A16@gmail.com> References: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> <32B5F7C6-CF71-4CB5-8342-92D1813A6A16@gmail.com> Message-ID: <3C1C3DD2-B116-4DE0-87BE-269567D9A7E2@gmail.com> > 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 with no code changes to mod_wsgi. >> >> Agreed. If all we want is to keep the request/response cycle intact, then WSGI supports H2 already. One possibility that has already been suggested here would be to define a HTTP/2 extension to WSGI, advertised in the environ dict, that allows the application to signal pushes to the server. This would be a fairly simple extension to write and implement. > > Sorry to be cynical. Many people have said that changes in the past related to WSGI will 'be a fairly simple extension to write and implement?. Dig deeper and it never turns out to be the case. :-) > > Such an extension presumes you actually have a tightly integrated HTTP/2 server which itself which can maintain a map of resources to push when getting certain requests and also maintain what may have already been sent for a session. Even getting to that point is going to be non trivial, even if an extension may be simple for somehow notifying what the additional resources to supply should be. > > Right now I would say that with mod_h2 in Apache in would be plain impossible as it doesn?t I believe even support the idea of pushing resources at this point. Even then it would most likely be a huge undertaking to get it to work for mod_wsgi daemon mode as the web application runs in a separate process to where HTTP/2 is handled. > > If you believe though it is as simple as an extra item in the environ dictionary, then it can be handled as a separate extension specification per the URL above. A side discussion on Twitter has noted that this exists: https://w3c.github.io/preload/ This is already implemented by mod_h2, nghttp2 and H20 at least. This is not my area so I don?t know for sure whether this fits the bill as to what is being described as ?pushing?. If as I understand it, this allows a WSGI application to return a Link header and mod_h2 in Apache then uses HTTP/2 push to deliver up those resources straight away. If I am misunderstanding this, please let me know. The only problem I do see with this right now if it does what is required, is that in mod_wsgi daemon mode, except for select headers such as Set-Cookie and WWW-Authenticate, response headers of the same name will be joined together. What I don?t know is if mod_h2/nghttp2 will handle where the value of a Link header is joined. It is probably going to be safer if I modify mod_wsgi and add Link to the white list of headers which aren?t joined together. If this does solve the push issue, what is there in HTTP/2 then that one couldn?t do via the existing WSGI interface? Graham -------------- next part -------------- An HTML attachment was scrubbed... URL: From cory at lukasa.co.uk Wed Jan 6 06:19:38 2016 From: cory at lukasa.co.uk (Cory Benfield) Date: Wed, 6 Jan 2016 11:19:38 +0000 Subject: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest In-Reply-To: <3C1C3DD2-B116-4DE0-87BE-269567D9A7E2@gmail.com> References: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> <32B5F7C6-CF71-4CB5-8342-92D1813A6A16@gmail.com> <3C1C3DD2-B116-4DE0-87BE-269567D9A7E2@gmail.com> Message-ID: <195C17FE-2338-4749-B074-B8B7AB9B2DBE@lukasa.co.uk> > 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 communications channels like Websockets, which you?ve already expressed a desire to expose in a different API. =) Pushing via Link headers is not ideal because it delays the push until after the headers are ready to go, and there?s a tricky ordering concern here (RFC 7540 points out that any PUSH_PROMISE frames should be sent before the response headers and body are sent, which means that we temporarily block the response that is ready to go from WSGI. This is a minor concern, but worth noting.) However, I?m happy to say that Pushing via Link headers is the way to go if we?d rather not specify a WSGI-specific API for it. Cory -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From cory at lukasa.co.uk Wed Jan 6 06:22:13 2016 From: cory at lukasa.co.uk (Cory Benfield) Date: Wed, 6 Jan 2016 11:22:13 +0000 Subject: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest In-Reply-To: <12706115-6740-4E03-A1CA-12678F1700CB@polytechnique.org> References: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> <62e8abdf-5d44-49d1-b034-c0b923bc80be@googlegroups.com> <12706115-6740-4E03-A1CA-12678F1700CB@polytechnique.org> Message-ID: <077EE020-8C66-4F65-BA33-4625582400C1@lukasa.co.uk> > 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 general this is a bit of a mess due to differences between what the RFC 2616 says and what browsers do in practice. That?s why I believe the pragmatic solution is to exchange bytes. (This isn?t a major issue in the grand scheme of things anyway.) > > Best regards, > 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 to me that the correct method of communicating field values would have been byte strings. Cory -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From hawkowl at atleastfornow.net Wed Jan 6 06:34:16 2016 From: hawkowl at atleastfornow.net (Amber "Hawkie" Brown) Date: Wed, 6 Jan 2016 19:34:16 +0800 Subject: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest In-Reply-To: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> References: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> Message-ID: <9441571E-76CB-4673-8B7A-37604E480277@atleastfornow.net> > 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 attempted to do this last year with Rob Collins leading the charge, but unfortunately personal commitments made it impossible for Rob to keep pushing that attempt forward. > > Since then, the need for a revision of WSGI has become even more apparent. Casual discussion on the web has indicated that application developers are uncomfortable with the limitations of WSGI. These limitations are providing an incentive for both application developers and server developers to take an end-run around WSGI in an attempt to get a framework that is more suitable for the modern web. A great example of the result of WSGI?s deficiencies is Andrew Godwin?s channels work[0] for Django, which represents a paradigm shift in application development that takes it far away from what WSGI is today. > > For this reason, I think we need to try again to get WSGI 2.0 off the ground. But I don?t believe we can do this without getting broad consensus from the developer community that a revision to WSGI is needed, and without understanding what developers need from a new revision of WSGI. This should take into account the prior discussions we?d had on this thread: however, I?m also going to actively solicit feedback from some of the more notable WSGI implementers, to ensure that whatever comes out of this SIG is something that they would actually use. > > This WG already had a list of requirements, which are as follows: > > - Support servers speaking HTTP/1.x, HTTP/2 and Websockets (potentially all on a single port). > - Support graceful degradation for applications that can use HTTP/2 but still support HTTP/1.x requests. > - Graceful incremental adoption path - no upgrade-all-components requirement baked into the design. > - Support Python 2.7 and 3.x (where x is not yet discussed) > - Support the existing ecosystem of containers (such as mod_wsgi) with the new API. We want a clean, fast and approachable API, and we want to ensure that its no less friendly to work with than WSGI, for all that it will expose much more functionality. > - Apps need to be able to tell what protocol is in use, and what optional features are available. For instance, HTTP/2 PUSH PROMISE is an optional feature that can be disabled by clients. Websockets needs to expose a socket like object, and so on. > - Support websockets > - Support HTTP/2 > - Support HTTP/1.x (which may be just 'point at PEP-3333?.) > - Continue to support lightweight shims being built on top such as https://github.com/Pylons/webob/blob/master/webob/request.py > > I believe that all of these requirements are up for grabs, and subject to change and consensus discussion. In this thread, then, I?d like to hear from people about these requirements and others. What do you believe WSGI 2.0 should do? Just as importantly, what do you believe it should not do? What prior art should we take into account? Should we bother revising WSGI at all, or should we let the wider application ecosystem pursue its own solutions ? la Django's channels? Should we simply adopt Andrew Godwin?s ASGI draft[1] on which channels is based and call *that* WSGI 2.0? > > Right now I want this to be very open. I?d like people to come up with a broad statement listing what they believe should and should not be present in WSGI. This first stage of the work is very general: I just want to get a feeling for what the community believes is important. Once we?re done with that, if the consensus is that this work is worth pursuing, I?ll come up with an initial draft that we can start making concrete changes to. > > In the short term, I?m going to keep this consultation open for **at least two weeks**: that is, I will not start working on an initial draft PEP until at least the **18th of January**. If you believe there are application or server developers that should be involved in this discussion, please reach out to them and point them to this list. I personally have CC?d some people that I believe need to be involved in the discussion, but please reach out to others as well. > > I?d really love to come to the end of 2016 with a solid direction for the future of web programming in Python. I?m looking forward to working with you all on achieving that. > > Thanks, > > Cory > > > [0]: https://channels.readthedocs.org/en/latest/ > [1]: https://channels.readthedocs.org/en/latest/asgi.html Hi all! Due to some dubious life choices, I've decided to take part in this discussion! I have very much a vested interest in async making sense in a new WSGI, and personally would go so far to say that a WSGI revision that does not include asynchronous support is a WSGI revision not worth having. But, I am also not sure if it should be a WSGI revision -- as Graham has mentioned, such a radical revision that (I personally) believe is required is likely to go poorly if we call it WSGI, because now we have all this "WSGI" stuff that doesn't actually speak WSGI 2. I'm looking forward to future developments, and hopefully we can finally unify the synchronous and asynchronous worlds of Python web programming. - Amber Brown -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From bchesneau at gmail.com Wed Jan 6 07:12:53 2016 From: bchesneau at gmail.com (Benoit Chesneau) Date: Wed, 06 Jan 2016 12:12:53 +0000 Subject: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest In-Reply-To: <9441571E-76CB-4673-8B7A-37604E480277@atleastfornow.net> References: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> <9441571E-76CB-4673-8B7A-37604E480277@atleastfornow.net> Message-ID: 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 On Wed, 6 Jan 2016 at 12:52, Amber "Hawkie" Brown wrote: > > > 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 attempted to do > this last year with Rob Collins leading the charge, but unfortunately > personal commitments made it impossible for Rob to keep pushing that > attempt forward. > > > > Since then, the need for a revision of WSGI has become even more > apparent. Casual discussion on the web has indicated that application > developers are uncomfortable with the limitations of WSGI. These > limitations are providing an incentive for both application developers and > server developers to take an end-run around WSGI in an attempt to get a > framework that is more suitable for the modern web. A great example of the > result of WSGI?s deficiencies is Andrew Godwin?s channels work[0] for > Django, which represents a paradigm shift in application development that > takes it far away from what WSGI is today. > > > > For this reason, I think we need to try again to get WSGI 2.0 off the > ground. But I don?t believe we can do this without getting broad consensus > from the developer community that a revision to WSGI is needed, and without > understanding what developers need from a new revision of WSGI. This should > take into account the prior discussions we?d had on this thread: however, > I?m also going to actively solicit feedback from some of the more notable > WSGI implementers, to ensure that whatever comes out of this SIG is > something that they would actually use. > > > > This WG already had a list of requirements, which are as follows: > > > > - Support servers speaking HTTP/1.x, HTTP/2 and Websockets (potentially > all on a single port). > > - Support graceful degradation for applications that can use HTTP/2 but > still support HTTP/1.x requests. > > - Graceful incremental adoption path - no upgrade-all-components > requirement baked into the design. > > - Support Python 2.7 and 3.x (where x is not yet discussed) > > - Support the existing ecosystem of containers (such as mod_wsgi) with > the new API. We want a clean, fast and approachable API, and we want to > ensure that its no less friendly to work with than WSGI, for all that it > will expose much more functionality. > > - Apps need to be able to tell what protocol is in use, and what > optional features are available. For instance, HTTP/2 PUSH PROMISE is an > optional feature that can be disabled by clients. Websockets needs to > expose a socket like object, and so on. > > - Support websockets > > - Support HTTP/2 > > - Support HTTP/1.x (which may be just 'point at PEP-3333?.) > > - Continue to support lightweight shims being built on top such as > https://github.com/Pylons/webob/blob/master/webob/request.py > > > > I believe that all of these requirements are up for grabs, and subject > to change and consensus discussion. In this thread, then, I?d like to hear > from people about these requirements and others. What do you believe WSGI > 2.0 should do? Just as importantly, what do you believe it should not do? > What prior art should we take into account? Should we bother revising WSGI > at all, or should we let the wider application ecosystem pursue its own > solutions ? la Django's channels? Should we simply adopt Andrew Godwin?s > ASGI draft[1] on which channels is based and call *that* WSGI 2.0? > > > > Right now I want this to be very open. I?d like people to come up with a > broad statement listing what they believe should and should not be present > in WSGI. This first stage of the work is very general: I just want to get a > feeling for what the community believes is important. Once we?re done with > that, if the consensus is that this work is worth pursuing, I?ll come up > with an initial draft that we can start making concrete changes to. > > > > In the short term, I?m going to keep this consultation open for **at > least two weeks**: that is, I will not start working on an initial draft > PEP until at least the **18th of January**. If you believe there are > application or server developers that should be involved in this > discussion, please reach out to them and point them to this list. I > personally have CC?d some people that I believe need to be involved in the > discussion, but please reach out to others as well. > > > > I?d really love to come to the end of 2016 with a solid direction for > the future of web programming in Python. I?m looking forward to working > with you all on achieving that. > > > > Thanks, > > > > Cory > > > > > > [0]: https://channels.readthedocs.org/en/latest/ > > [1]: https://channels.readthedocs.org/en/latest/asgi.html > > Hi all! Due to some dubious life choices, I've decided to take part in > this discussion! > > I have very much a vested interest in async making sense in a new WSGI, > and personally would go so far to say that a WSGI revision that does not > include asynchronous support is a WSGI revision not worth having. But, I am > also not sure if it should be a WSGI revision -- as Graham has mentioned, > such a radical revision that (I personally) believe is required is likely > to go poorly if we call it WSGI, because now we have all this "WSGI" stuff > that doesn't actually speak WSGI 2. > > I'm looking forward to future developments, and hopefully we can finally > unify the synchronous and asynchronous worlds of Python web programming. > > - Amber Brown > > _______________________________________________ > Web-SIG mailing list > Web-SIG at python.org > Web SIG: http://www.python.org/sigs/web-sig > Unsubscribe: > https://mail.python.org/mailman/options/web-sig/bchesneau%40gmail.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.svetlov at gmail.com Wed Jan 6 07:34:01 2016 From: andrew.svetlov at gmail.com (Andrew Svetlov) Date: Wed, 6 Jan 2016 14:34:01 +0200 Subject: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest In-Reply-To: <9441571E-76CB-4673-8B7A-37604E480277@atleastfornow.net> References: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> <9441571E-76CB-4673-8B7A-37604E480277@atleastfornow.net> Message-ID: 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 PEP, Guido promotes it and tornado supports asyncio-based code as well. In this case "async WSGI" cannot be implemented in Python 2 --- asyncio itself is Python 3.3+ only. trollius is not "asyncio compatible library for python 2" -- it's a port with slightly different API. Supporting both asyncio and trollius in a non-trivial third-party library makes a mess. That's why we decided don't make python2 compatible aiohttp implementation. Having both synchronous and asyncio API in the same WSGI standard is also impractical. There are several tries to make WSGI-based frameworks asynchronous. The only real successful approach is combination of gunicorn, gevent/eventlet and total sockets monkeypatching. I don't want to encourage the way -- but it don't need WSGI protocol changing. Monkeypatching just doing own dirty work. As aiohttp author I can see several approaches to make adapters for running flask, pyramid, django in asyncio way. The most of them uses aiohttp as a tool for bringing asynchronous into well-known synchronous framework. I can state it just doesn't work well. The result is too fragile: yes, it is asynchronous but has many subtle limitations which may break a program easy. It's impossible to write web framework which is synchronous and asynchronous at the same time. asyncio poisons any code that it touches, everything tends to became asynchronous too. aiohttp is a quite successful asyncio library, it doesn't need WSGI standard at all and works with raw sockets. The same is true for tornado and twisted. I very doubt aiohttp can get benefits from new WSGI. Please keep it simple and small. Async web developers need totally different standard not compatible with old good WSGI (if they need a standard at all at current stage). From alan at xhaus.com Wed Jan 6 07:49:56 2016 From: alan at xhaus.com (Alan Kennedy) Date: Wed, 6 Jan 2016 12:49:56 +0000 Subject: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest In-Reply-To: <077EE020-8C66-4F65-BA33-4625582400C1@lukasa.co.uk> References: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> <62e8abdf-5d44-49d1-b034-c0b923bc80be@googlegroups.com> <12706115-6740-4E03-A1CA-12678F1700CB@polytechnique.org> <077EE020-8C66-4F65-BA33-4625582400C1@lukasa.co.uk> Message-ID: [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 to me that the correct method of communicating field values would have been byte strings. I think it's worth pointing out that the original intention of specifying iso-8859-1 encoding was the request components *would* be presented to the application as bytes. WSGI was designed to work on python 2, where bytes and strings were stored in the same datatype. In cpythons UCS-2 encoding, where every character takes two bytes, only the lower byte would contain a value if the character was from the iso-8859-1 character set. Moreover, encoding and decoding such "byte strings" from iso-8859-1 would not change any values, i.e. iso-8859-1 was chosen because encoding and decoding from it was an identity transform. The same considerations applied to Jython 2.x (which uses UTF-16) and Ironpython 2.x (also UTF-16 I think), but which both had to the same bytes/strings duality problem. If python 2.x had had a bytes type, then that's what would have been used. This would also have made more explicit that it is the applications job to decode the bytes into whatever encoding it thinks is appropriate (i.e. essentially what it has guessed, in the real world). The WSGI servers job is to give the original bytes from the request to the WSGI application *unchanged*. The concluding message in the original discussion of encodings is here, if anyone is interested. https://mail.python.org/pipermail/web-sig/2004-September/000860.html Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hawkowl at atleastfornow.net Wed Jan 6 07:51:08 2016 From: hawkowl at atleastfornow.net (Amber "Hawkie" Brown) Date: Wed, 6 Jan 2016 20:51:08 +0800 Subject: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest In-Reply-To: References: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> <9441571E-76CB-4673-8B7A-37604E480277@atleastfornow.net> Message-ID: <2F913A5B-12B5-49D1-9BAA-040DF0D4C991@atleastfornow.net> > 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, and all. There is no reason that such an approach could not work for all three, and any other library that uses an event loop. And I'm not going to be playing Twisted favouritism here (I'm a core contributor and release manager, and one of the main forces behind Twisted's Python 3 porting), because the ideal case is each working using their own APIs, on top of any three, via shared event loops and better interop. > Let's assume we are talking about asyncio way -- it's standardized by > PEP, Guido promotes it and tornado supports asyncio-based code as > well. > > In this case "async WSGI" cannot be implemented in Python 2 --- > asyncio itself is Python 3.3+ only. > trollius is not "asyncio compatible library for python 2" -- it's a > port with slightly different API. Supporting both asyncio and trollius > in a non-trivial third-party library makes a mess. > That's why we decided don't make python2 compatible aiohttp implementation. Async WSGI can be perfectly implemented in both Tornado and Twisted, and it is possible to write 2/3 compatible (if not fully idiomatic) asyncio+trollius. Autobahn is one such library that is compatible with Twisted, Trollius, and asyncio, in one codebase. > Having both synchronous and asyncio API in the same WSGI standard is > also impractical. > There are several tries to make WSGI-based frameworks asynchronous. > The only real successful approach is combination of gunicorn, > gevent/eventlet and total sockets monkeypatching. I don't want to > encourage the way -- but it don't need WSGI protocol changing. > Monkeypatching just doing own dirty work. I believe it is possible, and I think it will work out quite well - synchronous code can call functions with results as easily as asynchronous code. > As aiohttp author I can see several approaches to make adapters for > running flask, pyramid, django in asyncio way. The most of them uses > aiohttp as a tool for bringing asynchronous into well-known > synchronous framework. > > I can state it just doesn't work well. The result is too fragile: yes, > it is asynchronous but has many subtle limitations which may break a > program easy. > It's impossible to write web framework which is synchronous and > asynchronous at the same time. > asyncio poisons any code that it touches, everything tends to became > asynchronous too. My personal experiments in this area have lead to a fully asynchronous Django core, with semi-async ORM -- I go into it in my Django Under The Hood talk (available at https://opbeat.com/events/duth/ ). And yes, everything needs to be asynchronous, or ran in a thread. Cooperative multitasking systems only work when everything cooperates. > aiohttp is a quite successful asyncio library, it doesn't need WSGI > standard at all and works with raw sockets. > The same is true for tornado and twisted. > > I very doubt aiohttp can get benefits from new WSGI. > Please keep it simple and small. > Async web developers need totally different standard not compatible > with old good WSGI (if they need a standard at all at current stage). I don't think WSGI as it is now with added async magic is what I'd propose, since it won't work. What we do need in the async world is a standard API that means that "parsing HTTP", and "doing web logic" are not intermingled. There is currently no way of running a Twisted Web server on top of asyncio, even though it is entirely technically possible -- if aiohttp were to gain this theoretical standard support (which I'm nicknaming "Albany"), then it would mean a Twisted Web service could run on top of aiohttp, or an asyncio-using service could run on top of Twisted. The things for this to become a reality are: - Twisted needs to gain an asyncio reactor in core, and asyncio needs a way of piggy backing on Twisted's reactors - Such a standard calling interface needs to be created. Secondly, there is the issue of running async code in, say, a nginx worker -- which requires something like crochet, which is more or less a well-working hack (which runs a new Twisted reactor in a thread). For long-living Twisted, asyncio, or Tornado services to interact with standalone web servers like nginx or Apache, some sort of gateway protocol needs to exist, that means that you can run an asyncio-API-using service, in a Twisted container, which gets web requests parsed by nginx. I am not sure if aiohttp can get any benefits from it, but Twisted could get some fantastic benefits, as well as any web framework (such a calling convention could mean Tornado could rip out all their ioloop stuff). This would also theoretically work well for Django (as ASGI works along the same lines, from my reading) and for any framework that wants to go from synchronous to asynchronous (which, honestly, is fairly easy, if you have proper separation of concerns). - Amber Brown -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From nd at perlig.de Wed Jan 6 13:41:55 2016 From: nd at perlig.de (=?utf-8?q?Andr=C3=A9_Malo?=) Date: Wed, 6 Jan 2016 19:41:55 +0100 Subject: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest In-Reply-To: References: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> Message-ID: <201601061941.55978@news.perlig.de> * 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 CGI implementations you would for HTTP/1.1 already get: > > SERVER_PROTOCOL: 'HTTP/1.1? > > Under HTTP/2 when I tested some time back, I recollect it came through as > one would assume would be expected: > > SERVER_PROTOCOL: ?HTTP/2? > > Is there any reason that this existing CGI variable wouldn?t be > sufficient for this purpose? The CGI spec. Although only informational, the definition of SERVER_PROTOCOL is kinda weird. https://www.ietf.org/rfc/rfc3875 Cheers, -- "Solides und umfangreiches Buch" -- aus einer Rezension From graham.dumpleton at gmail.com Wed Jan 6 15:06:44 2016 From: graham.dumpleton at gmail.com (Graham Dumpleton) Date: Thu, 7 Jan 2016 07:06:44 +1100 Subject: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest In-Reply-To: <195C17FE-2338-4749-B074-B8B7AB9B2DBE@lukasa.co.uk> References: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> <32B5F7C6-CF71-4CB5-8342-92D1813A6A16@gmail.com> <3C1C3DD2-B116-4DE0-87BE-269567D9A7E2@gmail.com> <195C17FE-2338-4749-B074-B8B7AB9B2DBE@lukasa.co.uk> Message-ID: <853EE82E-854F-42DA-9610-A582657B1EDB@gmail.com> > 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 WSGI with the possible exception of long-running bi-directional communications channels like Websockets, which you?ve already expressed a desire to expose in a different API. =) Can you elaborate more on the ?plenty? part. This was the issue in the past. People appeared to want access to everything. Thus why the belief you may as well allow them a separate API purpose built for it. Maybe people are becoming more realistic in expectations now as to what they really need for a typical web application as HTTP/2 is better understood. > Pushing via Link headers is not ideal because it delays the push until after the headers are ready to go, and there?s a tricky ordering concern here (RFC 7540 points out that any PUSH_PROMISE frames should be sent before the response headers and body are sent, which means that we temporarily block the response that is ready to go from WSGI. This is a minor concern, but worth noting.) > > However, I?m happy to say that Pushing via Link headers is the way to go if we?d rather not specify a WSGI-specific API for it. It appears that Link could at least be a fallback. The idea of a separate callable to push resources in WSGI environ could still be dealt with as an extension specification and so not need changes to the WSGI specification itself. Worst case is all that callable does is add Link headers to the response. This would likely have to be the case in Apache with mod_h2 as wouldn?t expect handlers to have direct access to an API to do it any other way, plus in mod_wsgi daemon mode is in the wrong process to access any API. With the possibility that Link header would be a mechanism for use by such a callable, then any calling arguments for the callable should perhaps be modelled on what is possible via the Link header. I could be talking nonsense on that point as I have no idea how server push works in HTTP/2 protocol. Graham From gdamjan at gmail.com Wed Jan 6 21:03:00 2016 From: gdamjan at gmail.com (Damjan Georgievski) Date: Thu, 7 Jan 2016 03:03:00 +0100 Subject: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest In-Reply-To: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> References: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> Message-ID: > 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 sending a specially crafted response header. I'm suspicious we'll need any special WSGI support for that. Let's first see what nginx does about it. -- damjan From cory at lukasa.co.uk Thu Jan 7 05:58:51 2016 From: cory at lukasa.co.uk (Cory Benfield) Date: Thu, 7 Jan 2016 10:58:51 +0000 Subject: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest In-Reply-To: <853EE82E-854F-42DA-9610-A582657B1EDB@gmail.com> References: <7ED6F528-54C9-43FA-A800-0045D21CE485@lukasa.co.uk> <32B5F7C6-CF71-4CB5-8342-92D1813A6A16@gmail.com> <3C1C3DD2-B116-4DE0-87BE-269567D9A7E2@gmail.com> <195C17FE-2338-4749-B074-B8B7AB9B2DBE@lukasa.co.uk> <853EE82E-854F-42DA-9610-A582657B1EDB@gmail.com> Message-ID: <44C7B726-A074-4F65-8586-B73BF37B7E8F@lukasa.co.uk> > 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 interface? >> >> Well, plenty, but none that we?d *want* to expose via WSGI with the possible exception of long-running bi-directional communications channels like Websockets, which you?ve already expressed a desire to expose in a different API. =) > > Can you elaborate more on the ?plenty? part. > > This was the issue in the past. People appeared to want access to everything. Thus why the belief you may as well allow them a separate API purpose built for it. Maybe people are becoming more realistic in expectations now as to what they really need for a typical web application as HTTP/2 is better understood. Sure. =) HTTP/2 has the following extra things that a user may want control over: - Preventing headers being added to the compression context. Good servers will automatically do this for things like Set-Cookie, but an application may have special knowledge about a header being security-relevant. There is no way to signal this in WSGI. - Forcing certain headers to be added to the compression context. The flip side of the first part is that an application may know that a header is likely to be repeatedly re-used, despite being something that would ordinarily vary, and it may want to pass this knowledge to the server. - Server push before the complete set of response headers are ready (i.e. before the original response body is rendered). - Long-running bi-directional communications channels, like Websockets. - Signaling information about client priority to the application so it can allocate resources effectively. - Signaling information about flow control to the application so it can allocate resources effectively. (Both of these two could *maybe* be done using generators with WSGI, but it would be imperfect.) - Controlling flow control windows for large responses (e.g. deliberately shrinking or widening them). - Controlling flow control widows for connections as a whole. - Graceful connection shutdown (emitting GOAWAY but continuing to process the outstanding requests/responses). - Efficient stream cancellation (e.g. sending RST_STREAM for unwanted/invalid requests without tearing down the connection, likely related to the previous point) HTTP/2 is a very featureful protocol which complex applications could really take advantage of. Worth remembering. >> Pushing via Link headers is not ideal because it delays the push until after the headers are ready to go, and there?s a tricky ordering concern here (RFC 7540 points out that any PUSH_PROMISE frames should be sent before the response headers and body are sent, which means that we temporarily block the response that is ready to go from WSGI. This is a minor concern, but worth noting.) >> >> However, I?m happy to say that Pushing via Link headers is the way to go if we?d rather not specify a WSGI-specific API for it. > > > It appears that Link could at least be a fallback. > > The idea of a separate callable to push resources in WSGI environ could still be dealt with as an extension specification and so not need changes to the WSGI specification itself. Worst case is all that callable does is add Link headers to the response. This would likely have to be the case in Apache with mod_h2 as wouldn?t expect handlers to have direct access to an API to do it any other way, plus in mod_wsgi daemon mode is in the wrong process to access any API. Yup, this is definitely an option. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From cory at lukasa.co.uk Tue Jan 19 11:55:14 2016 From: cory at lukasa.co.uk (Cory Benfield) Date: Tue, 19 Jan 2016 16:55:14 +0000 Subject: [Web-SIG] Collating follow-up on the future of WSGI Message-ID: <71B64498-C7AA-493D-BB9B-74264A145A11@lukasa.co.uk> 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 the tone of the discussion so positive. On an topic like this one it can get tricky and emotionally charged very easily, and you did a great job of avoiding that problem. I spent a few hours this morning going over your feedback and trying to extract some common threads. Altogether I believe that most participants were mostly in agreement over the direction we should take, with a few outliers in each case. I?d like to summarise what I believe were the big take-aways from that discussion to confirm that I?ve understood everyone. I?d also like the members of this SIG to take this opportunity to discuss these proposals more concretely. Rather than expressing our sentiments about WSGI and its future more generally, I want people to critique and offer opinions on *these specific proposals*. The goal here is to get an understanding of whether these are worth doing, how we need to prioritise the work, and whether there?s anything we?re missing. The below is formatted in restructured text for clarity, because it?s quite a lot of information. Concrete Proposals ================== WSGI ---- Overall, there was strong and fairly unanimous sentiment that WSGI itself should more or less be left alone. Minor adjustments would be valuable, and we should pursue them, but the contributors do not believe that making a substantial revision to WSGI would be adviseable. I therefore propose we revise the WSGI specification to WSGI 1.1 and then consider it "final". The following points were raised for revising WSGI. Asynchronous WSGI ~~~~~~~~~~~~~~~~~ This was generally regarded as too substantial a change to shoehorn into WSGI. Benoit proposed that we could achieve this change by adding a correlator to WSGI. This would allow servers to associate a given call to ``write()`` with a specific request/response (most useful in HTTP/2 where this could correspond to a stream ID). This would then allow WSGI to transition to a purely callback-based model that could in principle cohabitate with an async protocol in Python. This proposal is worth highlighting not becuase I think we should pursue it with our revision of WSGI, but because it's worth considering for any future specification we come up with. Note also that Graham pointed out that this would require some careful rethinking of reads from ``wsgi.input``. Server Push ~~~~~~~~~~~ We can support HTTP/2 server push using Link headers. This could optionally be supplemented by defining a WSGI extension that provides a callable for doing server push, which would be a mild improvement over the Link header approach. A simple proposal for how to do this can easily be implemented without revising the WSGI specification, and may not even need to be enshrined in a PEP. However, if we revise the WSGI PEP we may want to provide a small section that indicates how to add these headers. 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, therefore, this idea is unworkable. 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 client, or for the application to request it from the server. This seemed to be a low priority work item, but if we can make this enhancement easily then it's worth considering. Bytes and Unicode ~~~~~~~~~~~~~~~~~ Several contributors expressed dissatisfaction for PEP-3333's approach to headers (namely, Latin-1-encoded Unicode strings), and expressed a preference for using bytestrings. If we attempt this change, we have a backward-compatibility concern, so we may have to live with this decision. Regardless, this should be taken as a warning sign for any other specification we attempt: more on that later. 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 alternative name for this was RAW_URI. Header Joining and Name Normalization ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Armin pointed out that PEP-3333 does not mention what should happen to normalize header names and to join header fields that appear multiple times in a header block. CGI does not appear to proscribe a behaviour here either. A revision of PEP-3333 should cover how header names get normalised (where the answer is basically "like CGI"), and how servers should join headers together (and logically, how applications can split them). Mostly this is simply codifying existing practice. 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 string. Servers are required to police that logic. This is codifying existing practice, and would also make CONTENT_LENGTH purely advisory. File Wrapper ~~~~~~~~~~~~ Graham identified two specific problems with ``wsgi.file_wrapper``: specifically, the bad example (which doesn't close the file descriptor properly), and the larger problem about the overly general specification of the ``file_wrapper`` as he's blogged about in the past. In general, we may want to identify ``file_wrapper`` as a point of contention, and consider more fundamental revisions to this under-used part of the WSGI specification. We may also want to consider simply dropping it entirely, or pulling it out to an extension specification rather than leaving it in WSGI 1.1. Websockets and HTTP/2 --------------------- Here, the consensus seemed to be that we should investigate whether we can come up with WSGI-equivalent APIs for Websockets and HTTP/2. The goal here would be to allow servers that are interested in offering richer APIs than WSGI can provide would be able to do so. This is particularly valuable for HTTP/2, which can function totally fine when used with WSGI but which can have much richer functionality made available to the application via a different API if that application requires it. As a SIG we should begin to consider what these APIs should look like. We should also bear in mind the more advanced asynchronous interfaces (see below), and ensure that we can easily proxy these APIs to the more advanced ones, as we can with WSGI to ASGI. Meta API ~~~~~~~~ Graham suggested, along with these more advanced APIs, that we may want a meta-API or API discovery API that would allow servers to target a single entry point which then provides access to the callables for WSGI, the Websockets API, and the HTTP/2 API. We should bear this idea in mind, but I don't believe we should worry too much about whether we actually build it or not at this time: it can definitely follow the prototyping work on the HTTP/2 specific APIs. Asynchronous Python ------------------- There was an overall positive reaction to introducing *something* that fills the WSGI role for applications that use asynchronous Python frameworks. Exactly how this would look is unclear at this stage, and this should be thought of as a long-term goal for this SIG. Amber Brown is clearly working on an idea, and we also have Andrew's work on ASGI, either of which could be used as a basis for a future PEP. There was, however, a clear consensus that this should be a clean break from WSGI: while a server implementing this specification should be able to call into WSGI applications with a small shim, there is no requirement that an *application* using this specification should be callable from a WSGI server. We should absolutely bear this in mind, and we should encourage specification work to be done here when things are ready, but this is definitely not going to happen as quickly as the other ideas above. Please let me know what you think of this set of proposals. If everything is in good shape, I?ll begin working on some of these items, hopefully with the help of some of the other members of this SIG! Cory -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From graham.dumpleton at gmail.com Tue Jan 19 16:24:58 2016 From: graham.dumpleton at gmail.com (Graham Dumpleton) Date: Wed, 20 Jan 2016 07:24:58 +1000 Subject: [Web-SIG] Collating follow-up on the future of WSGI In-Reply-To: <71B64498-C7AA-493D-BB9B-74264A145A11@lukasa.co.uk> References: <71B64498-C7AA-493D-BB9B-74264A145A11@lukasa.co.uk> Message-ID: <02E13BAB-6593-41C4-BA41-50FC0FC8CDA0@gmail.com> > 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 string. Servers are required to police that logic. This is codifying existing practice, and would also make CONTENT_LENGTH purely advisory. Clarification on this point as maybe I didn?t explain well enough what I was suggesting. It isn?t that want an empty string to be returned immediately if an attempt is made to read more than CONTENT_LENGTH, but that it is permissible that a WSGI server CAN actually return more than what CONTENT_LENGTH states. This would occur for example with chunked request content where CONTENT_LENGTH would actually be 0 (not present). Or, with compressed request content which is decompressed by the underlying web server. Thus the actual amount of data available to read would be greater in length than the original non zero CONTENT_LENGTH. A WSGI application wishing to support these situations would, instead of reading up to CONTENT_LENGTH, would read in data until it is returned an empty string, indicating end of input. The complication comes in that PEP 333 simply said you can?t read more than CONTENT_LENGTH. It didn?t really provide a guarantee that if you did you got an empty string back. In PEP 3333, a guarantee was added that when you had read all input you would get an empty string. There was no version change for WSGI in PEP 3333, ie., wsgi.version, so you don?t really have a proper way of knowing for sure that a WSGI server will work that way so WSGI applications still tend to be written to only read up to CONTENT_LENGTH. An updated WSGI 1.1, so wsgi.version would be updated, would provide a means of being able to know if empty string is guaranteed, but also the additional new change that you can read past CONTENT_LENGTH and still get data, with input eventually terminated by empty string. I have at least one blog post about this some where so I will try and find it. Travelling this morning though so no more time to try and find it right now. Graham -------------- next part -------------- An HTML attachment was scrubbed... URL: From bchesneau at gmail.com Tue Jan 19 16:43:02 2016 From: bchesneau at gmail.com (Benoit Chesneau) Date: Tue, 19 Jan 2016 21:43:02 +0000 Subject: [Web-SIG] Collating follow-up on the future of WSGI In-Reply-To: <71B64498-C7AA-493D-BB9B-74264A145A11@lukasa.co.uk> References: <71B64498-C7AA-493D-BB9B-74264A145A11@lukasa.co.uk> Message-ID: 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, therefore, this idea is unworkable. > > Well it does work. This is how websockets works in gunicorn. Escape is not the right term anyway. Think it as a socket *upgrade*. And then you would wonder why it would be unworkable. After all this is how SSL sockets works, so is the protocol negotiation in http2 ... There is nothing magic there until you try to over engineer the stuff. Upgrading a sockets means that you tell to the server to forget it. This is how most concurrent servers work today. - benoit -------------- next part -------------- An HTML attachment was scrubbed... URL: From graham.dumpleton at gmail.com Tue Jan 19 16:49:13 2016 From: graham.dumpleton at gmail.com (Graham Dumpleton) Date: Wed, 20 Jan 2016 07:49:13 +1000 Subject: [Web-SIG] Collating follow-up on the future of WSGI In-Reply-To: References: <71B64498-C7AA-493D-BB9B-74264A145A11@lukasa.co.uk> Message-ID: <486E34C8-FB7C-452E-813B-26E82FA722AB@gmail.com> > 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 like servers would not be capable of achieving this. I think, therefore, this idea is unworkable. > > > Well it does work. This is how websockets works in gunicorn. Escape is not the right term anyway. Think it as a socket upgrade. And then you would wonder why it would be unworkable. After all this is how SSL sockets works, so is the protocol negotiation in http2 ... > > There is nothing magic there until you try to over engineer the stuff. Upgrading a sockets means that you tell to the server to forget it. This is how most concurrent servers work today. The problem was that it would only work in a WSGI server where the original request was accepted on a socket in the same process as the WSGI application is running. It cannot work where where the WSGI application is behind a bridging protocol. So it can?t work for CGI, SCGI, FASTCGI, mod_wsgi daemon mode and possibly other implementations. So the ?unworkable? is coming from that you couldn?t universally implement it across all current WSGI implementations. For that reason, having it as part of core WSGI is debatable as it would have to be marked as optional. At that point better as a separate WSGI extension outside of the WSGI PEP if you did at least want to standardise such an approach across those WSGI servers that may be able to support it. Graham -------------- next part -------------- An HTML attachment was scrubbed... URL: From bchesneau at gmail.com Tue Jan 19 17:29:04 2016 From: bchesneau at gmail.com (Benoit Chesneau) Date: Tue, 19 Jan 2016 22:29:04 +0000 Subject: [Web-SIG] Collating follow-up on the future of WSGI In-Reply-To: <486E34C8-FB7C-452E-813B-26E82FA722AB@gmail.com> References: <71B64498-C7AA-493D-BB9B-74264A145A11@lukasa.co.uk> <486E34C8-FB7C-452E-813B-26E82FA722AB@gmail.com> Message-ID: On Tue, Jan 19, 2016 at 10:49 PM Graham Dumpleton < graham.dumpleton at 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 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, therefore, this idea is unworkable. >> >> > Well it does work. This is how websockets works in gunicorn. Escape is > not the right term anyway. Think it as a socket *upgrade*. And then you > would wonder why it would be unworkable. After all this is how SSL sockets > works, so is the protocol negotiation in http2 ... > > There is nothing magic there until you try to over engineer the stuff. > Upgrading a sockets means that you tell to the server to forget it. This is > how most concurrent servers work today. > > > The problem was that it would only work in a WSGI server where the > original request was accepted on a socket in the same process as the WSGI > application is running. It cannot work where where the WSGI application is > behind a bridging protocol. > > So it can?t work for CGI, SCGI, FASTCGI, mod_wsgi daemon mode and possibly > other implementations. > uh? But we don't care about bridging protocols. In WSGI (the gateway), the server accept the socket and anyway pass it to the application via actually a wrapper. Then expect a response from the application. Upgrading a socket would simply mean that the server will forget it (and then consider its job done) once it got an appropriate response from the application. How this is unworkable? - benoit -------------- next part -------------- An HTML attachment was scrubbed... URL: From graham.dumpleton at gmail.com Tue Jan 19 17:34:12 2016 From: graham.dumpleton at gmail.com (Graham Dumpleton) Date: Wed, 20 Jan 2016 08:34:12 +1000 Subject: [Web-SIG] Collating follow-up on the future of WSGI In-Reply-To: References: <71B64498-C7AA-493D-BB9B-74264A145A11@lukasa.co.uk> <486E34C8-FB7C-452E-813B-26E82FA722AB@gmail.com> Message-ID: <72170AB9-AD64-42F9-8EA7-8F314646546E@gmail.com> > 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. 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, therefore, this idea is unworkable. >> >> >> Well it does work. This is how websockets works in gunicorn. Escape is not the right term anyway. Think it as a socket upgrade. And then you would wonder why it would be unworkable. After all this is how SSL sockets works, so is the protocol negotiation in http2 ... >> >> There is nothing magic there until you try to over engineer the stuff. Upgrading a sockets means that you tell to the server to forget it. This is how most concurrent servers work today. > > The problem was that it would only work in a WSGI server where the original request was accepted on a socket in the same process as the WSGI application is running. It cannot work where where the WSGI application is behind a bridging protocol. > > So it can?t work for CGI, SCGI, FASTCGI, mod_wsgi daemon mode and possibly other implementations. > > uh? But we don't care about bridging protocols. In WSGI (the gateway), the server accept the socket and anyway pass it to the application via actually a wrapper. Then expect a response from the application. > > Upgrading a socket would simply mean that the server will forget it (and then consider its job done) once it got an appropriate response from the application. How this is unworkable? Bridging protocols such as FASTCGI do not provide an ability to upgrade the connection end to end. That is, yes you could pass the raw socket to the WSGI application when behind FASTCGI, but you are passing it a socket from same process where data being received (and expected to be sent), is using FASTGCI message frames. It is not a raw HTTP socket connection. There is no way to send a message back to the front end side of the bridged connection where the raw HTTP socket is, to tell the client side of the FASTCGI implementation to stop treating it as a FASTCGI connection to backend process and then suddenly start acting as a raw socket pass through. Graham -------------- next part -------------- An HTML attachment was scrubbed... URL: From bchesneau at gmail.com Tue Jan 19 17:40:46 2016 From: bchesneau at gmail.com (Benoit Chesneau) Date: Tue, 19 Jan 2016 22:40:46 +0000 Subject: [Web-SIG] Collating follow-up on the future of WSGI In-Reply-To: <72170AB9-AD64-42F9-8EA7-8F314646546E@gmail.com> References: <71B64498-C7AA-493D-BB9B-74264A145A11@lukasa.co.uk> <486E34C8-FB7C-452E-813B-26E82FA722AB@gmail.com> <72170AB9-AD64-42F9-8EA7-8F314646546E@gmail.com> Message-ID: On Tue, Jan 19, 2016 at 11:34 PM Graham Dumpleton < graham.dumpleton at 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.dumpleton at 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 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, therefore, this idea is unworkable. >>> >>> >> Well it does work. This is how websockets works in gunicorn. Escape is >> not the right term anyway. Think it as a socket *upgrade*. And then you >> would wonder why it would be unworkable. After all this is how SSL sockets >> works, so is the protocol negotiation in http2 ... >> >> There is nothing magic there until you try to over engineer the stuff. >> Upgrading a sockets means that you tell to the server to forget it. This is >> how most concurrent servers work today. >> >> >> The problem was that it would only work in a WSGI server where the >> original request was accepted on a socket in the same process as the WSGI >> application is running. It cannot work where where the WSGI application is >> behind a bridging protocol. >> > >> So it can?t work for CGI, SCGI, FASTCGI, mod_wsgi daemon mode and >> possibly other implementations. >> > > uh? But we don't care about bridging protocols. In WSGI (the gateway), the > server accept the socket and anyway pass it to the application via actually > a wrapper. Then expect a response from the application. > > Upgrading a socket would simply mean that the server will forget it (and > then consider its job done) once it got an appropriate response from the > application. How this is unworkable? > > > Bridging protocols such as FASTCGI do not provide an ability to upgrade > the connection end to end. > > That is, yes you could pass the raw socket to the WSGI application when > behind FASTCGI, but you are passing it a socket from same process where > data being received (and expected to be sent), is using FASTGCI message > frames. It is not a raw HTTP socket connection. > > There is no way to send a message back to the front end side of the > bridged connection where the raw HTTP socket is, to tell the client side of > the FASTCGI implementation to stop treating it as a FASTCGI connection to > backend process and then suddenly start acting as a raw socket pass through. > > But how it is related to the WSGI protocol? It is expected that the wsgi server accept on a socket (directly or behind a proxy) and provide enough to the application so they can read and write. Upgrading or escaping in WSGI/Server sense would mean that it would skip the dialog with the application once the application told it to do. For the rest, the application would do what it want on the socket, even giving it to another process/thread. - benoit -------------- next part -------------- An HTML attachment was scrubbed... URL: From robertc at robertcollins.net Tue Jan 19 17:56:25 2016 From: robertc at robertcollins.net (Robert Collins) Date: Wed, 20 Jan 2016 11:56:25 +1300 Subject: [Web-SIG] Collating follow-up on the future of WSGI In-Reply-To: <71B64498-C7AA-493D-BB9B-74264A145A11@lukasa.co.uk> References: <71B64498-C7AA-493D-BB9B-74264A145A11@lukasa.co.uk> Message-ID: 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 really engaging reading. I also want to thank you all for keeping the tone of the discussion so positive. On an topic like this one it can get tricky and emotionally charged very easily, and you did a great job of avoiding that problem. > > I spent a few hours this morning going over your feedback and trying to extract some common threads. Altogether I believe that most participants were mostly in agreement over the direction we should take, with a few outliers in each case. I?d like to summarise what I believe were the big take-aways from that discussion to confirm that I?ve understood everyone. > > I?d also like the members of this SIG to take this opportunity to discuss these proposals more concretely. Rather than expressing our sentiments about WSGI and its future more generally, I want people to critique and offer opinions on *these specific proposals*. The goal here is to get an understanding of whether these are worth doing, how we need to prioritise the work, and whether there?s anything we?re missing. > > The below is formatted in restructured text for clarity, because it?s quite a lot of information. > > > Concrete Proposals > ================== > > WSGI > ---- > > Overall, there was strong and fairly unanimous sentiment that WSGI itself should more or less be left alone. Minor adjustments would be valuable, and we should pursue them, but the contributors do not believe that making a substantial revision to WSGI would be adviseable. > > I therefore propose we revise the WSGI specification to WSGI 1.1 and then consider it "final". The following points were raised for revising WSGI. Sure. > Asynchronous WSGI > ~~~~~~~~~~~~~~~~~ > > This was generally regarded as too substantial a change to shoehorn into WSGI. > > Benoit proposed that we could achieve this change by adding a correlator to WSGI. This would allow servers to associate a given call to ``write()`` with a specific request/response (most useful in HTTP/2 where this could correspond to a stream ID). This would then allow WSGI to transition to a purely callback-based model that could in principle cohabitate with an async protocol in Python. Uh, WSGI doesn't need to be involved in this. Servers can already pass arbitrary objects as write, permitting any correlation they want. I'd want to see something very specific to consider the impact in terms of WSGI, or WSGI-NG or whatever we do in future. > This proposal is worth highlighting not becuase I think we should pursue it with our revision of WSGI, but because it's worth considering for any future specification we come up with. Note also that Graham pointed out that this would require some careful rethinking of reads from ``wsgi.input``. > Server Push > ~~~~~~~~~~~ > > We can support HTTP/2 server push using Link headers. This could optionally be supplemented by defining a WSGI extension that provides a callable for doing server push, which would be a mild improvement over the Link header approach. A simple proposal for how to do this can easily be implemented without revising the WSGI specification, and may not even need to be enshrined in a PEP. However, if we revise the WSGI PEP we may want to provide a small section that indicates how to add these headers. Since the point of WSGI is interop, we should document the expected interop fashion for this, whatever it is. > 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, therefore, this idea is unworkable. I thin Benoit is making assumptions about what a 'server' is that are not implied by WSGI - and this is leading to some confusion. Servers are not necessarily Python processes :). > 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 client, or for the application to request it from the server. > > This seemed to be a low priority work item, but if we can make this enhancement easily then it's worth considering. I'm very much against this. I think its an abstraction violation. It makes as much sense as exposing the guts of HTTP/2 framing to an application. A way of doing Trailers would make sense. > Bytes and Unicode > ~~~~~~~~~~~~~~~~~ > > Several contributors expressed dissatisfaction for PEP-3333's approach to headers (namely, Latin-1-encoded Unicode strings), and expressed a preference for using bytestrings. If we attempt this change, we have a backward-compatibility concern, so we may have to live with this decision. > > Regardless, this should be taken as a warning sign for any other specification we attempt: more on that later. > > 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 alternative name for this was RAW_URI. If its reasonable available to e.g. Apache modules, I could see doing this. That said, why have two? Why not require that URI be the 'RAW' URI? I don't see the benefit in having two separate variables. > 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 string. Servers are required to police that logic. This is codifying existing practice, and would also make CONTENT_LENGTH purely advisory. I don't understand this being a work item. PEP-3333 already has all this in it: - e.g. "A server should return empty bytestrings from any attempt to read from an empty or exhausted input stream. " > Websockets and HTTP/2 > --------------------- > > Here, the consensus seemed to be that we should investigate whether we can come up with WSGI-equivalent APIs for Websockets and HTTP/2. The goal here would be to allow servers that are interested in offering richer APIs than WSGI can provide would be able to do so. > > This is particularly valuable for HTTP/2, which can function totally fine when used with WSGI but which can have much richer functionality made available to the application via a different API if that application requires it. > > As a SIG we should begin to consider what these APIs should look like. We should also bear in mind the more advanced asynchronous interfaces (see below), and ensure that we can easily proxy these APIs to the more advanced ones, as we can with WSGI to ASGI. I don't see this belonging in a WSGI 1.1. In a '2.0' or a -NG or some other differentiated thing, sure. > Meta API > ~~~~~~~~ > > Graham suggested, along with these more advanced APIs, that we may want a meta-API or API discovery API that would allow servers to target a single entry point which then provides access to the callables for WSGI, the Websockets API, and the HTTP/2 API. We should bear this idea in mind, but I don't believe we should worry too much about whether we actually build it or not at this time: it can definitely follow the prototyping work on the HTTP/2 specific APIs. Yeah, I'm not clear on what Graham wants here. Its not a lack I've felt so far :). > Asynchronous Python > ------------------- > > There was an overall positive reaction to introducing *something* that fills the WSGI role for applications that use asynchronous Python frameworks. > > Exactly how this would look is unclear at this stage, and this should be thought of as a long-term goal for this SIG. Amber Brown is clearly working on an idea, and we also have Andrew's work on ASGI, either of which could be used as a basis for a future PEP. Guido also had some commentary on this a year or so back, IIRC. -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud From bchesneau at gmail.com Tue Jan 19 18:04:49 2016 From: bchesneau at gmail.com (Benoit Chesneau) Date: Tue, 19 Jan 2016 23:04:49 +0000 Subject: [Web-SIG] Collating follow-up on the future of WSGI In-Reply-To: References: <71B64498-C7AA-493D-BB9B-74264A145A11@lukasa.co.uk> Message-ID: 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 it ended up at about 50 pages of information that > was really engaging reading. I also want to thank you all for keeping the > tone of the discussion so positive. On an topic like this one it can get > tricky and emotionally charged very easily, and you did a great job of > avoiding that problem. > > > > I spent a few hours this morning going over your feedback and trying to > extract some common threads. Altogether I believe that most participants > were mostly in agreement over the direction we should take, with a few > outliers in each case. I?d like to summarise what I believe were the big > take-aways from that discussion to confirm that I?ve understood everyone. > > > > I?d also like the members of this SIG to take this opportunity to > discuss these proposals more concretely. Rather than expressing our > sentiments about WSGI and its future more generally, I want people to > critique and offer opinions on *these specific proposals*. The goal here is > to get an understanding of whether these are worth doing, how we need to > prioritise the work, and whether there?s anything we?re missing. > > > > The below is formatted in restructured text for clarity, because it?s > quite a lot of information. > > > > > > Concrete Proposals > > ================== > > > > WSGI > > ---- > > > > Overall, there was strong and fairly unanimous sentiment that WSGI > itself should more or less be left alone. Minor adjustments would be > valuable, and we should pursue them, but the contributors do not believe > that making a substantial revision to WSGI would be adviseable. > > > > I therefore propose we revise the WSGI specification to WSGI 1.1 and > then consider it "final". The following points were raised for revising > WSGI. > > Sure. > > > Asynchronous WSGI > > ~~~~~~~~~~~~~~~~~ > > > > This was generally regarded as too substantial a change to shoehorn into > WSGI. > > > > Benoit proposed that we could achieve this change by adding a correlator > to WSGI. This would allow servers to associate a given call to ``write()`` > with a specific request/response (most useful in HTTP/2 where this could > correspond to a stream ID). This would then allow WSGI to transition to a > purely callback-based model that could in principle cohabitate with an > async protocol in Python. > > Uh, WSGI doesn't need to be involved in this. Servers can already pass > arbitrary objects as write, permitting any correlation they want. I'd > want to see something very specific to consider the impact in terms of > WSGI, or WSGI-NG or whatever we do in future. > > > This proposal is worth highlighting not becuase I think we should pursue > it with our revision of WSGI, but because it's worth considering for any > future specification we come up with. Note also that Graham pointed out > that this would require some careful rethinking of reads from > ``wsgi.input``. > > > > > Server Push > > ~~~~~~~~~~~ > > > > We can support HTTP/2 server push using Link headers. This could > optionally be supplemented by defining a WSGI extension that provides a > callable for doing server push, which would be a mild improvement over the > Link header approach. A simple proposal for how to do this can easily be > implemented without revising the WSGI specification, and may not even need > to be enshrined in a PEP. However, if we revise the WSGI PEP we may want to > provide a small section that indicates how to add these headers. > > Since the point of WSGI is interop, we should document the expected > interop fashion for this, whatever it is. > > > 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, therefore, this idea is unworkable. > > I thin Benoit is making assumptions about what a 'server' is that are > not implied by WSGI - and this is leading to some confusion. Servers > are not necessarily Python processes :). > > 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 application is running. And then nothing stop to give the socket away to the application and tell to the server to stop to communicate with it. - benoit -------------- next part -------------- An HTML attachment was scrubbed... URL: From robertc at robertcollins.net Tue Jan 19 19:57:56 2016 From: robertc at robertcollins.net (Robert Collins) Date: Wed, 20 Jan 2016 13:57:56 +1300 Subject: [Web-SIG] Collating follow-up on the future of WSGI In-Reply-To: References: <71B64498-C7AA-493D-BB9B-74264A145A11@lukasa.co.uk> Message-ID: 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 application is running. And then nothing stop to give the > socket away to the application and tell to the server to stop to communicate > with it. What socket? Data could be being passed by shm, for instance. -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud From graham.dumpleton at gmail.com Wed Jan 20 01:04:48 2016 From: graham.dumpleton at gmail.com (Graham Dumpleton) Date: Wed, 20 Jan 2016 16:04:48 +1000 Subject: [Web-SIG] Collating follow-up on the future of WSGI In-Reply-To: References: <71B64498-C7AA-493D-BB9B-74264A145A11@lukasa.co.uk> Message-ID: <608B387B-B500-4A73-917B-899D287FA85E@gmail.com> > 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 client, or for the application to request it from the server. >> >> This seemed to be a low priority work item, but if we can make this enhancement easily then it's worth considering. > > I'm very much against this. I think its an abstraction violation. It > makes as much sense as exposing the guts of HTTP/2 framing to an > application. A way of doing Trailers would make sense. I would agree in as much that what is stated here is confusing. There are two concerns. Chunked request content, and use of chunking on response content. For chunked request content it can?t currently be done by PEP 3333. This is what the separate issue about reading more than CONTENT_LENGTH is about. For chunked request content, a WSGI application would never see raw chunked stream as it would be de-chunked by the web server. 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. BTW, this reminds me of another area of the WSGI PEP which is broken which I have talked about before in: http://blog.dscpl.com.au/2009/10/wsgi-issues-with-http-head-requests.html There might be another post about it. Basically the PEP is wrong is saying a WSGI server is allowed to construct a Content-Length header where it identifies the response as a list containing one string. Doing so can break the supposed equivalence in headers between GET and HEAD. So another issue that would be cleaned up in any 1.1 final version of the specification. Graham -------------- next part -------------- An HTML attachment was scrubbed... URL: From graham.dumpleton at gmail.com Wed Jan 20 01:09:38 2016 From: graham.dumpleton at gmail.com (Graham Dumpleton) Date: Wed, 20 Jan 2016 16:09:38 +1000 Subject: [Web-SIG] Collating follow-up on the future of WSGI In-Reply-To: References: <71B64498-C7AA-493D-BB9B-74264A145A11@lukasa.co.uk> Message-ID: <0E333A03-568A-48FC-A85C-C3CF12DC4D4C@gmail.com> > 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 sort of wrapping done in the same thread/process >> where the python application is running. And then nothing stop to give the >> socket away to the application and tell to the server to stop to communicate >> with it. > > What socket? > > Data could be being passed by shm, for instance. Exactly. You aren?t guaranteed that from the HTTP client to the WSGI server consists only of use of socket connections with HTTP running over it. Intermediary hops to could use non socket communication mechanisms, or instead of using HTTP on a proxy connection, use an alternate protocol such as CGI, SCGI, FASTCGI or some internal WSGI server specific protocol. There are enough of these already that a requirement in the WSGI specification to provide a socket which had the original unmodified HTTP request coming over it is not possible. It has to be optional and being optional it doesn?t really even need to be in the WSGI specification PEP but can be a separate WSGI extension specification. Graham From graham.dumpleton at gmail.com Wed Jan 20 01:21:45 2016 From: graham.dumpleton at gmail.com (Graham Dumpleton) Date: Wed, 20 Jan 2016 16:21:45 +1000 Subject: [Web-SIG] Collating follow-up on the future of WSGI In-Reply-To: References: <71B64498-C7AA-493D-BB9B-74264A145A11@lukasa.co.uk> Message-ID: <8CE639FC-4BC8-4AEA-B58F-93722970FAAC@gmail.com> > 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 alternative name for this was RAW_URI. > > If its reasonable available to e.g. Apache modules, I could see doing > this. That said, why have two? Why not require that URI be the 'RAW' > URI? I don't see the benefit in having two separate variables. The history on this one was that Apache and anything that copied what Apache did always provided this as REQUEST_URI. It has some de-facto standing therefore as meant it was also always present in many CGI, SCGI, FASTCGI environments as a result. When Gunicorn decided to add the equivalent, they chose not to use what Apache has always used and chose a different name. It isn?t an issue therefore of allowing both, it makes more sense only to note use of REQUEST_URI as it has longer standing. If adopted, Gunicorn would need to use REQUEST_URI, but only Gunicorn would have to continue to use RAW_URI to support people who wrote WSGI applications which were only looking for what Gunicorn used and didn?t know there was another convention for it. As to the comment: Why not require that URI be the ?RAW? URI? am not sure what you ?UR? you are talking about, if you are talking about some other existing variables in the WSGI specification. Graham -------------- next part -------------- An HTML attachment was scrubbed... URL: From cory at lukasa.co.uk Wed Jan 20 05:53:01 2016 From: cory at lukasa.co.uk (Cory Benfield) Date: Wed, 20 Jan 2016 10:53:01 +0000 Subject: [Web-SIG] Collating follow-up on the future of WSGI In-Reply-To: <608B387B-B500-4A73-917B-899D287FA85E@gmail.com> References: <71B64498-C7AA-493D-BB9B-74264A145A11@lukasa.co.uk> <608B387B-B500-4A73-917B-899D287FA85E@gmail.com> Message-ID: <39063AAF-DAA8-46F4-A2BA-55936E10D339@lukasa.co.uk> > 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 between ?at liberty to? and ?required to?. Certain behaviours that make sense with chunked transfer encoding do not make sense without it: for example, streaming API endpoints that return events as they arrive. Sending this kind of response with a HTTP/1.0-style content-length absent response (framed by connection termination) is utterly confusing, especially as some APIs consider the chunk framing to be semantic. This can and does bite people, because while all major production WSGI servers use chunked transfer encoding in this situation, not all WSGI implementations do: in fact, wsgiref does not. This means that if an application has a production design requirement to use chunked transfer encoding in its responses it cannot rely on the server actually providing it. I see two solutions to this problem: we could mandate that HTTP/1.1 responses that have no content length must be chunked, rather than falling back to HTTP/1.0 style connection-termination-framed responses, or we could have servers stuff something in the environ dictionary that can be checked by applications. Or, I suppose, we can conclude that this problem is not large enough, and that it?s ?caveat developer?. That, however, was my concern regard chunked responses. Cory -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From nd at perlig.de Wed Jan 20 06:25:40 2016 From: nd at perlig.de (=?utf-8?q?Andr=C3=A9_Malo?=) Date: Wed, 20 Jan 2016 12:25:40 +0100 Subject: [Web-SIG] Collating follow-up on the future of WSGI In-Reply-To: <39063AAF-DAA8-46F4-A2BA-55936E10D339@lukasa.co.uk> References: <71B64498-C7AA-493D-BB9B-74264A145A11@lukasa.co.uk> <608B387B-B500-4A73-917B-899D287FA85E@gmail.com> <39063AAF-DAA8-46F4-A2BA-55936E10D339@lukasa.co.uk> Message-ID: <201601201225.40397@news.perlig.de> * 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. > > My specific concern is the distinction between ?at liberty to? and > ?required to?. Certain behaviours that make sense with chunked transfer > encoding do not make sense without it: for example, streaming API endpoints > that return events as they arrive. Sending this kind of response with a > HTTP/1.0-style content-length absent response (framed by connection > termination) is utterly confusing, especially as some APIs consider the > chunk framing to be semantic. 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. > This can and does bite people, because while all major production WSGI > servers use chunked transfer encoding in this situation, not all WSGI > implementations do: in fact, wsgiref does not. This means that if an > application has a production design requirement to use chunked transfer > encoding in its responses it cannot rely on the server actually providing > it. > > I see two solutions to this problem: we could mandate that HTTP/1.1 > responses that have no content length must be chunked, rather than falling > back to HTTP/1.0 style connection-termination-framed responses, or we could > have servers stuff something in the environ dictionary that can be checked > by applications. Or, I suppose, we can conclude that this problem is not > large enough, and that it?s ?caveat developer?. WSGI is a gateway working with the representation layer. I think, it should not concern itself with underlying transport issues that much. 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 like this would be my suggestion for a future WSGI spec. Cheers, nd [1] https://tools.ietf.org/html/rfc7230#section-3.3.1 -- If God intended people to be naked, they would be born that way. -- Oscar Wilde From graham.dumpleton at gmail.com Wed Jan 20 07:03:19 2016 From: graham.dumpleton at gmail.com (Graham Dumpleton) Date: Wed, 20 Jan 2016 23:03:19 +1100 Subject: [Web-SIG] Collating follow-up on the future of WSGI In-Reply-To: <201601201225.40397@news.perlig.de> References: <71B64498-C7AA-493D-BB9B-74264A145A11@lukasa.co.uk> <608B387B-B500-4A73-917B-899D287FA85E@gmail.com> <39063AAF-DAA8-46F4-A2BA-55936E10D339@lukasa.co.uk> <201601201225.40397@news.perlig.de> Message-ID: > 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 >>> the response. >>> >>> So I am not sure what is missing. >> >> My specific concern is the distinction between ?at liberty to? and >> ?required to?. Certain behaviours that make sense with chunked transfer >> encoding do not make sense without it: for example, streaming API endpoints >> that return events as they arrive. Bidirectional HTTP is effectively a no go. CGI, SCGI and FASTCGI implementations, mod_wsgi daemon mode and many HTTP proxies will often not actually start reading a response until they have managed to send the full content of the request. There are also various issues around buffering, especially with intermediaries. So if your expectation is that that you can send a bit of a request, have client wait for a response for that bit, then send more request, wait for more response for that part of the request and so on, it isn?t going to work for most implementations. This problem/issue and the lack of support for both way streaming has been the subjects of some RFCs. I can?t remember if this is the exact one I remember seeing before, but does appear relevant: https://www.ietf.org/rfc/rfc6202.txt Anyway, the end result as I saw it was no one could be bothered supporting proper bidirectional HTTP as getting proxies/caches changed was going to be too hard. The solution was to give up on it for HTTP/1.X and instead do it in HTTP/2 as upgrading a HTTP connection to something else generally had the effect of bypassing any intermediaries behaviour which would cause issues as then it would switch to streaming properly in both directions. So I think it is a lost cause to try and do it in HTTP/1.X and WSGI. >> Sending this kind of response with a >> HTTP/1.0-style content-length absent response (framed by connection >> termination) is utterly confusing, especially as some APIs consider the >> chunk framing to be semantic. > > 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. Yep. If framing was required you could never rely on the HTTP chunking. Framing had to be done in the actual data. >> This can and does bite people, because while all major production WSGI >> servers use chunked transfer encoding in this situation, not all WSGI >> implementations do: in fact, wsgiref does not. This means that if an >> application has a production design requirement to use chunked transfer >> encoding in its responses it cannot rely on the server actually providing >> it. >> >> I see two solutions to this problem: we could mandate that HTTP/1.1 >> responses that have no content length must be chunked, rather than falling >> back to HTTP/1.0 style connection-termination-framed responses, or we could >> have servers stuff something in the environ dictionary that can be checked >> by applications. Or, I suppose, we can conclude that this problem is not >> large enough, and that it?s ?caveat developer?. > > WSGI is a gateway working with the representation layer. I think, it should > not concern itself with underlying transport issues that much. > > 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 like this would be my > suggestion for a future WSGI spec. I am assuming here you mean that -1 means return whatever you have available, or block until you have something. Problem with that is that some implementations will use -1 as a default value to mean no argument supplied and so read all input. So that could well conflict with some implementations. Also, if it is going to block, how is it really different to reading with a block size. The whole think with chunking as noted above is that intermediates can change the chunking and so using framing of your own in the data where you know the size of each message at application layer is only way to reliability do it. So can?t see any benefit of -1 meaning give me whatever you have. In general this is where you would be better to have a proper ASYNC API. > Cheers, > nd > > [1] https://tools.ietf.org/html/rfc7230#section-3.3.1 > -- > If God intended people to be naked, they would be born that way. > -- Oscar Wilde > _______________________________________________ > Web-SIG mailing list > Web-SIG at python.org > Web SIG: http://www.python.org/sigs/web-sig > Unsubscribe: https://mail.python.org/mailman/options/web-sig/graham.dumpleton%40gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From nd at perlig.de Wed Jan 20 07:24:14 2016 From: nd at perlig.de (=?utf-8?q?Andr=C3=A9_Malo?=) Date: Wed, 20 Jan 2016 13:24:14 +0100 Subject: [Web-SIG] Collating follow-up on the future of WSGI In-Reply-To: References: <71B64498-C7AA-493D-BB9B-74264A145A11@lukasa.co.uk> <201601201225.40397@news.perlig.de> Message-ID: <201601201324.14137@news.perlig.de> * 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 like this > > would be my suggestion for a future WSGI spec. > > I am assuming here you mean that -1 means return whatever you have > available, or block until you have something. > > Problem with that is that some implementations will use -1 as a default > value to mean no argument supplied and so read all input. That was actually the idea. It has the same semantics (as in file.read(int(environ['CONTENT_LENGTH'])). Since -1 is not covered by RFC 3875, it should not break much as well (*cough*). > > So that could well conflict with some implementations. > > Also, if it is going to block, how is it really different to reading with a > block size. It's not. It's a signal, that the gateway has no idea about the size of the request body and you (as the application) should not make any assumptions. You wouldn't read(-1) a file of unknown size either. Cheers, nd -- Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook! Ook? Ook. Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook? Ook. Ook! Ook! Ook? Ook! Ook. Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook! Ook. Ook! Ook! Ook! Ook! Ook! Ook. From graham.dumpleton at gmail.com Wed Jan 20 07:37:41 2016 From: graham.dumpleton at gmail.com (Graham Dumpleton) Date: Wed, 20 Jan 2016 23:37:41 +1100 Subject: [Web-SIG] Collating follow-up on the future of WSGI In-Reply-To: <201601201324.14137@news.perlig.de> References: <71B64498-C7AA-493D-BB9B-74264A145A11@lukasa.co.uk> <201601201225.40397@news.perlig.de> <201601201324.14137@news.perlig.de> Message-ID: <3417D64B-0C24-48F8-BF08-C5FC6A06E428@gmail.com> > 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 >>> request sizes (it maps very well to file.read(size)). Something like this >>> would be my suggestion for a future WSGI spec. >> >> I am assuming here you mean that -1 means return whatever you have >> available, or block until you have something. >> >> Problem with that is that some implementations will use -1 as a default >> value to mean no argument supplied and so read all input. > > That was actually the idea. It has the same semantics (as in > file.read(int(environ['CONTENT_LENGTH'])). Since -1 is not covered by RFC > 3875, it should not break much as well (*cough*). > >> >> So that could well conflict with some implementations. >> >> Also, if it is going to block, how is it really different to reading with a >> block size. > > It's not. It's a signal, that the gateway has no idea about the size of the > request body and you (as the application) should not make any assumptions. > You wouldn't read(-1) a file of unknown size either. Okay. Didn?t read properly everything you said. I thought you were trying to give read() with -1 a special meaning only. Not that you are also suggesting CONTENT_LENGTH in WSGI environ would be -1. I can?t remember the details but I recollect when this was discussed once before that setting CONTENT_LENGTH to -1 was determined as not being a good idea. Would need to go back through the archives to find the reasons brought up. Anyway, it becomes unnecessary if you simply change things such that you should read, in chunks as necessary, until get back an empty byte string. You don?t need a special CONTENT_LENGTH value to indicate unknown length at that point. If you want to deal with partial reads of unknown length, still better to have ASYNC as then you can avoiding blocking and be doing something else at same time. Graham From cory at lukasa.co.uk Wed Jan 20 08:03:57 2016 From: cory at lukasa.co.uk (Cory Benfield) Date: Wed, 20 Jan 2016 13:03:57 +0000 Subject: [Web-SIG] Collating follow-up on the future of WSGI In-Reply-To: <201601201225.40397@news.perlig.de> References: <71B64498-C7AA-493D-BB9B-74264A145A11@lukasa.co.uk> <608B387B-B500-4A73-917B-899D287FA85E@gmail.com> <39063AAF-DAA8-46F4-A2BA-55936E10D339@lukasa.co.uk> <201601201225.40397@news.perlig.de> Message-ID: <746AC277-9A66-401F-98E1-9D4B67124D8E@lukasa.co.uk> > 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 good a reason as any to abandon that change. Cory -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From fumanchu at aminus.org Wed Jan 20 10:33:25 2016 From: fumanchu at aminus.org (Robert Brewer) Date: Wed, 20 Jan 2016 15:33:25 +0000 Subject: [Web-SIG] Collating follow-up on the future of WSGI In-Reply-To: <201601201225.40397@news.perlig.de> References: <71B64498-C7AA-493D-BB9B-74264A145A11@lukasa.co.uk> <608B387B-B500-4A73-917B-899D287FA85E@gmail.com> <39063AAF-DAA8-46F4-A2BA-55936E10D339@lukasa.co.uk>, <201601201225.40397@news.perlig.de> Message-ID: CherryPy's wsgiserver chunks the write if the application returns no Content-Length header at all (and certain other conditions don't intrude). See https://bitbucket.org/cherrypy/cherrypy/src/tip/cherrypy/wsgiserver/wsgiserver2.py?#wsgiserver2.py-928 Robert Brewer fumanchu at aminus.org ________________________________________ From: Web-SIG [web-sig-bounces+fumanchu=aminus.org at python.org] on behalf of Andr? Malo [nd at perlig.de] Sent: Wednesday, January 20, 2016 3:25 AM To: web-sig at python.org Subject: 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. > > My specific concern is the distinction between ?at liberty to? and > ?required to?. Certain behaviours that make sense with chunked transfer > encoding do not make sense without it: for example, streaming API endpoints > that return events as they arrive. Sending this kind of response with a > HTTP/1.0-style content-length absent response (framed by connection > termination) is utterly confusing, especially as some APIs consider the > chunk framing to be semantic. 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. > This can and does bite people, because while all major production WSGI > servers use chunked transfer encoding in this situation, not all WSGI > implementations do: in fact, wsgiref does not. This means that if an > application has a production design requirement to use chunked transfer > encoding in its responses it cannot rely on the server actually providing > it. > > I see two solutions to this problem: we could mandate that HTTP/1.1 > responses that have no content length must be chunked, rather than falling > back to HTTP/1.0 style connection-termination-framed responses, or we could > have servers stuff something in the environ dictionary that can be checked > by applications. Or, I suppose, we can conclude that this problem is not > large enough, and that it?s ?caveat developer?. WSGI is a gateway working with the representation layer. I think, it should not concern itself with underlying transport issues that much. 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 like this would be my suggestion for a future WSGI spec. Cheers, nd [1] https://tools.ietf.org/html/rfc7230#section-3.3.1 -- If God intended people to be naked, they would be born that way. -- Oscar Wilde _______________________________________________ Web-SIG mailing list Web-SIG at python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/fumanchu%40aminus.org From bchesneau at gmail.com Wed Jan 20 10:48:41 2016 From: bchesneau at gmail.com (Benoit Chesneau) Date: Wed, 20 Jan 2016 15:48:41 +0000 Subject: [Web-SIG] Collating follow-up on the future of WSGI In-Reply-To: References: <71B64498-C7AA-493D-BB9B-74264A145A11@lukasa.co.uk> Message-ID: 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 sort of wrapping done in the same > thread/process > > where the python application is running. And then nothing stop to give > the > > socket away to the application and tell to the server to stop to > communicate > > with it. > > What socket? > > Data could be being passed by shm, for instance. > > -Rob > > While shared memory would be quite a bad idea, then why not. I still don't see why having a way to upgrade the connection can't be done. Call it I/O resource or Socket, the issue is the same. At the end nothing stop the server to pass the control to the app. If we forget the socket (which is btw the simplest design) then the server could stop to control the I/O resource when the application ask it to do it. At some point either a garbage collection or a basic resource return/claim flow could be used to definitely free the resource. The thing behind that is that it would allow the WSGI spec to only focus on providing a strict gateway workflow without forcing the application to adopt a concurrency model aync or not. - benoit. -------------- next part -------------- An HTML attachment was scrubbed... URL: From graham.dumpleton at gmail.com Wed Jan 20 15:28:01 2016 From: graham.dumpleton at gmail.com (Graham Dumpleton) Date: Thu, 21 Jan 2016 07:28:01 +1100 Subject: [Web-SIG] Collating follow-up on the future of WSGI In-Reply-To: References: <71B64498-C7AA-493D-BB9B-74264A145A11@lukasa.co.uk> Message-ID: <1B5EC8D5-A2B1-499A-ADE3-B969EC6851A6@gmail.com> > 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 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 application is running. And then nothing stop to give the > > socket away to the application and tell to the server to stop to communicate > > with it. > > What socket? > > Data could be being passed by shm, for instance. > > -Rob > > > While shared memory would be quite a bad idea, then why not. I still don't see why having a way to upgrade the connection can't be done. > > Call it I/O resource or Socket, the issue is the same. At the end nothing stop the server to pass the control to the app. If we forget the socket (which is btw the simplest design) then the server could stop to control the I/O resource when the application ask it to do it. At some point either a garbage collection or a basic resource return/claim flow could be used to definitely free the resource. > > The thing behind that is that it would allow the WSGI spec to only focus on providing a strict gateway workflow without forcing the application to adopt a concurrency model aync or not. No one has said you cannot do it. because though it is only able to be implemented in a subset of WSGI servers/adapters, then it doesn?t seem appropriate that it be a part of the core WSGI specification. This is the role of a WSGI extension as found at: http://wsgi.readthedocs.org/en/latest/specifications.html So go talk to the authors of uWSGI, and the other couple of packages available for trying to plug these into some of the pure Python based WSGI servers and come to an agreement between yourselves as to a standard way of doing it and the extension specification can be added to the wsgi.org site. Graham -------------- next part -------------- An HTML attachment was scrubbed... URL: From bchesneau at gmail.com Wed Jan 20 17:27:57 2016 From: bchesneau at gmail.com (Benoit Chesneau) Date: Wed, 20 Jan 2016 22:27:57 +0000 Subject: [Web-SIG] Collating follow-up on the future of WSGI In-Reply-To: <1B5EC8D5-A2B1-499A-ADE3-B969EC6851A6@gmail.com> References: <71B64498-C7AA-493D-BB9B-74264A145A11@lukasa.co.uk> <1B5EC8D5-A2B1-499A-ADE3-B969EC6851A6@gmail.com> Message-ID: 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 like in smtp, imap, ... so the servers that implement a specific extension can legally published it. Would it work for you? benoit On Wed, 20 Jan 2016 at 21:28, Graham Dumpleton wrote: > > 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 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 application is running. And then nothing stop to give >> the >> > socket away to the application and tell to the server to stop to >> communicate >> > with it. >> >> What socket? >> >> Data could be being passed by shm, for instance. >> >> -Rob >> >> > While shared memory would be quite a bad idea, then why not. I still don't > see why having a way to upgrade the connection can't be done. > > Call it I/O resource or Socket, the issue is the same. At the end nothing > stop the server to pass the control to the app. If we forget the socket > (which is btw the simplest design) then the server could stop to control > the I/O resource when the application ask it to do it. At some point either > a garbage collection or a basic resource return/claim flow could be used to > definitely free the resource. > > The thing behind that is that it would allow the WSGI spec to only focus > on providing a strict gateway workflow without forcing the application to > adopt a concurrency model aync or not. > > > No one has said you cannot do it. because though it is only able to be > implemented in a subset of WSGI servers/adapters, then it doesn?t seem > appropriate that it be a part of the core WSGI specification. > > This is the role of a WSGI extension as found at: > > http://wsgi.readthedocs.org/en/latest/specifications.html > > So go talk to the authors of uWSGI, and the other couple of packages > available for trying to plug these into some of the pure Python based WSGI > servers and come to an agreement between yourselves as to a standard way of > doing it and the extension specification can be added to the wsgi.org > site. > > Graham > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robertc at robertcollins.net Wed Jan 20 17:36:50 2016 From: robertc at robertcollins.net (Robert Collins) Date: Thu, 21 Jan 2016 11:36:50 +1300 Subject: [Web-SIG] Collating follow-up on the future of WSGI In-Reply-To: References: <71B64498-C7AA-493D-BB9B-74264A145A11@lukasa.co.uk> <1B5EC8D5-A2B1-499A-ADE3-B969EC6851A6@gmail.com> Message-ID: 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 instead suggest to add a system of > capability or extension like in smtp, imap, ... so the servers that > implement a specific extension can legally published it. Would it work for > you? I don't understand this 'any server can do it' thing. nginx for example, has no actual socket per connection for the uwsgi backends: the data is multiplexed over a dedicated uwsgi framing layer, and the server is responsible for HTTP framing itself. Sure, Python servers that have done listen() and accept() do have a real socket to expose, but thats a small subset of the implementations of WSGI> -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud From graham.dumpleton at gmail.com Wed Jan 20 17:37:19 2016 From: graham.dumpleton at gmail.com (Graham Dumpleton) Date: Thu, 21 Jan 2016 09:37:19 +1100 Subject: [Web-SIG] Collating follow-up on the future of WSGI In-Reply-To: References: <71B64498-C7AA-493D-BB9B-74264A145A11@lukasa.co.uk> <1B5EC8D5-A2B1-499A-ADE3-B969EC6851A6@gmail.com> Message-ID: <45B5DFE8-7951-4B21-9EEA-B30A61BB3908@gmail.com> > 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 socket and having a separate high level API for implementing something like WebSocket this was already talked about. The suggestion was that it should not be a part of WSGI. Develop that API independently with no link to WSGI. The idea of upgrading from WSGI to a different API isn?t practical for various WSGI servers as it isn?t possible to unwind the state of the connection path created to get to point of handling the WSGI application. The better scenario is that the switch to an alternate WebSocket API is handled completely within the web server however it needs to handle it, when it needs to handle it, and not be reliant on going into a WSGI application which then says, oh, I actually need that to be WebSocket. > Now like we have wsgi.thread I would instead suggest to add a system of capability or extension like in smtp, imap, ... so the servers that implement a specific extension can legally published it. Would it work for you? Since there is nothing in WSGI environ called wsgi.thread now I have no idea what you are really suggesting here. Graham > benoit > > On Wed, 20 Jan 2016 at 21:28, Graham Dumpleton > wrote: > >> 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 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 application is running. And then nothing stop to give the >> > socket away to the application and tell to the server to stop to communicate >> > with it. >> >> What socket? >> >> Data could be being passed by shm, for instance. >> >> -Rob >> >> >> While shared memory would be quite a bad idea, then why not. I still don't see why having a way to upgrade the connection can't be done. >> >> Call it I/O resource or Socket, the issue is the same. At the end nothing stop the server to pass the control to the app. If we forget the socket (which is btw the simplest design) then the server could stop to control the I/O resource when the application ask it to do it. At some point either a garbage collection or a basic resource return/claim flow could be used to definitely free the resource. >> >> The thing behind that is that it would allow the WSGI spec to only focus on providing a strict gateway workflow without forcing the application to adopt a concurrency model aync or not. > > No one has said you cannot do it. because though it is only able to be implemented in a subset of WSGI servers/adapters, then it doesn?t seem appropriate that it be a part of the core WSGI specification. > > This is the role of a WSGI extension as found at: > > http://wsgi.readthedocs.org/en/latest/specifications.html > > So go talk to the authors of uWSGI, and the other couple of packages available for trying to plug these into some of the pure Python based WSGI servers and come to an agreement between yourselves as to a standard way of doing it and the extension specification can be added to the wsgi.org site. > > Graham > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bchesneau at gmail.com Thu Jan 21 00:12:51 2016 From: bchesneau at gmail.com (Benoit Chesneau) Date: Thu, 21 Jan 2016 05:12:51 +0000 Subject: [Web-SIG] Fwd: Collating follow-up on the future of WSGI In-Reply-To: References: <71B64498-C7AA-493D-BB9B-74264A145A11@lukasa.co.uk> <1B5EC8D5-A2B1-499A-ADE3-B969EC6851A6@gmail.com> <45B5DFE8-7951-4B21-9EEA-B30A61BB3908@gmail.com> Message-ID: ---------- Forwarded message --------- From: Benoit Chesneau Date: Thu, 21 Jan 2016 at 06:12 Subject: Re: [Web-SIG] Collating follow-up on the future of WSGI To: Graham Dumpleton 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 about providing a low level abstraction like wsgi.input but adding to it the support of output. (I was referring to wsgi.multithread...). This low level interface would allow anyone to provide its own implementation(server) or usage (application) still acting as a *gateway* . Also who are "we"? I am starting to think the discussion is already done and only obscure details like the content_length or headers encoding should be discussed. The RAW_SOCKET have been added on demand of the gunicorn users. Such thing also exist in things like cherrypy if I remember. A lot of code around have been created over it. So before deciding it's unworkable or whatever I strongly invite you to consider it as an addition to the environ. And since some servers need to pass the data differently I then suggest a Resource object on which you can read and write and eventually poll. This is not a websocket but more a proxy ressource to the client connexion. I will come back asap with a small spec. I also propose a second addition to the protocol that formalize the addition of extensions to the protocol by the servers if they want to. Having for example something like "`wsg.extensions` . Such addition would help anyone to experiment changes over the wsgi before making such changes in the specification by itself possibly. I think we have a good opportunity to extend the WSGI specification to allow the users to take over the new challenges on the web without forcing them to use a concurrency mode or skip completely the WSGI spec. The interest I see in WSGI is its simplicity and low level interface allowing users to build whatever they want over it. The different workers and their support of different concurrency models and framework in gunicorn let me think it is possible. Are the participants of this thread ready to discuss it? - beno?t On Wed, 20 Jan 2016 at 23:37, Graham Dumpleton wrote: > 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 socket and having a separate high level > API for implementing something like WebSocket this was already talked > about. The suggestion was that it should not be a part of WSGI. Develop > that API independently with no link to WSGI. The idea of upgrading from > WSGI to a different API isn?t practical for various WSGI servers as it > isn?t possible to unwind the state of the connection path created to get to > point of handling the WSGI application. The better scenario is that the > switch to an alternate WebSocket API is handled completely within the web > server however it needs to handle it, when it needs to handle it, and not > be reliant on going into a WSGI application which then says, oh, I actually > need that to be WebSocket. > > Now like we have wsgi.thread I would instead suggest to add a system of > capability or extension like in smtp, imap, ... so the servers that > implement a specific extension can legally published it. Would it work for > you? > > > Since there is nothing in WSGI environ called wsgi.thread now I have no > idea what you are really suggesting here. > > Graham > > benoit > > On Wed, 20 Jan 2016 at 21:28, Graham Dumpleton > wrote: > >> >> 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 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 application is running. And then nothing stop to give >>> the >>> > socket away to the application and tell to the server to stop to >>> communicate >>> > with it. >>> >>> What socket? >>> >>> Data could be being passed by shm, for instance. >>> >>> -Rob >>> >>> >> While shared memory would be quite a bad idea, then why not. I still >> don't see why having a way to upgrade the connection can't be done. >> >> Call it I/O resource or Socket, the issue is the same. At the end nothing >> stop the server to pass the control to the app. If we forget the socket >> (which is btw the simplest design) then the server could stop to control >> the I/O resource when the application ask it to do it. At some point either >> a garbage collection or a basic resource return/claim flow could be used to >> definitely free the resource. >> >> The thing behind that is that it would allow the WSGI spec to only focus >> on providing a strict gateway workflow without forcing the application to >> adopt a concurrency model aync or not. >> >> >> No one has said you cannot do it. because though it is only able to be >> implemented in a subset of WSGI servers/adapters, then it doesn?t seem >> appropriate that it be a part of the core WSGI specification. >> >> This is the role of a WSGI extension as found at: >> >> http://wsgi.readthedocs.org/en/latest/specifications.html >> >> So go talk to the authors of uWSGI, and the other couple of packages >> available for trying to plug these into some of the pure Python based WSGI >> servers and come to an agreement between yourselves as to a standard way of >> doing it and the extension specification can be added to the wsgi.org >> site. >> >> Graham >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From bchesneau at gmail.com Thu Jan 21 00:13:51 2016 From: bchesneau at gmail.com (Benoit Chesneau) Date: Thu, 21 Jan 2016 05:13:51 +0000 Subject: [Web-SIG] Collating follow-up on the future of WSGI In-Reply-To: <45B5DFE8-7951-4B21-9EEA-B30A61BB3908@gmail.com> References: <71B64498-C7AA-493D-BB9B-74264A145A11@lukasa.co.uk> <1B5EC8D5-A2B1-499A-ADE3-B969EC6851A6@gmail.com> <45B5DFE8-7951-4B21-9EEA-B30A61BB3908@gmail.com> Message-ID: 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 about providing a low level abstraction like wsgi.input but adding to it the support of output. (I was referring to wsgi.multithread...). This low level interface would allow anyone to provide its own implementation(server) or usage (application) still acting as a *gateway* . Also who are "we"? I am starting to think the discussion is already done and only obscure details like the content_length or headers encoding should be discussed. The RAW_SOCKET have been added on demand of the gunicorn users. Such thing also exist in things like cherrypy if I remember. A lot of code around have been created over it. So before deciding it's unworkable or whatever I strongly invite you to consider it as an addition to the environ. And since some servers need to pass the data differently I then suggest a Resource object on which you can read and write and eventually poll. This is not a websocket but more a proxy ressource to the client connexion. I will come back asap with a small spec. I also propose a second addition to the protocol that formalize the addition of extensions to the protocol by the servers if they want to. Having for example something like "`wsg.extensions` . Such addition would help anyone to experiment changes over the wsgi before making such changes in the specification by itself possibly. I think we have a good opportunity to extend the WSGI specification to allow the users to take over the new challenges on the web without forcing them to use a concurrency mode or skip completely the WSGI spec. The interest I see in WSGI is its simplicity and low level interface allowing users to build whatever they want over it. The different workers and their support of different concurrency models and framework in gunicorn let me think it is possible. Are the participants of this thread ready to discuss it? - beno?t On Wed, 20 Jan 2016 at 23:37, Graham Dumpleton wrote: > 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 socket and having a separate high level > API for implementing something like WebSocket this was already talked > about. The suggestion was that it should not be a part of WSGI. Develop > that API independently with no link to WSGI. The idea of upgrading from > WSGI to a different API isn?t practical for various WSGI servers as it > isn?t possible to unwind the state of the connection path created to get to > point of handling the WSGI application. The better scenario is that the > switch to an alternate WebSocket API is handled completely within the web > server however it needs to handle it, when it needs to handle it, and not > be reliant on going into a WSGI application which then says, oh, I actually > need that to be WebSocket. > > Now like we have wsgi.thread I would instead suggest to add a system of > capability or extension like in smtp, imap, ... so the servers that > implement a specific extension can legally published it. Would it work for > you? > > > Since there is nothing in WSGI environ called wsgi.thread now I have no > idea what you are really suggesting here. > > Graham > > benoit > > On Wed, 20 Jan 2016 at 21:28, Graham Dumpleton > wrote: > >> >> 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 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 application is running. And then nothing stop to give >>> the >>> > socket away to the application and tell to the server to stop to >>> communicate >>> > with it. >>> >>> What socket? >>> >>> Data could be being passed by shm, for instance. >>> >>> -Rob >>> >>> >> While shared memory would be quite a bad idea, then why not. I still >> don't see why having a way to upgrade the connection can't be done. >> >> Call it I/O resource or Socket, the issue is the same. At the end nothing >> stop the server to pass the control to the app. If we forget the socket >> (which is btw the simplest design) then the server could stop to control >> the I/O resource when the application ask it to do it. At some point either >> a garbage collection or a basic resource return/claim flow could be used to >> definitely free the resource. >> >> The thing behind that is that it would allow the WSGI spec to only focus >> on providing a strict gateway workflow without forcing the application to >> adopt a concurrency model aync or not. >> >> >> No one has said you cannot do it. because though it is only able to be >> implemented in a subset of WSGI servers/adapters, then it doesn?t seem >> appropriate that it be a part of the core WSGI specification. >> >> This is the role of a WSGI extension as found at: >> >> http://wsgi.readthedocs.org/en/latest/specifications.html >> >> So go talk to the authors of uWSGI, and the other couple of packages >> available for trying to plug these into some of the pure Python based WSGI >> servers and come to an agreement between yourselves as to a standard way of >> doing it and the extension specification can be added to the wsgi.org >> site. >> >> Graham >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From graham.dumpleton at gmail.com Thu Jan 21 01:24:25 2016 From: graham.dumpleton at gmail.com (Graham Dumpleton) Date: Thu, 21 Jan 2016 17:24:25 +1100 Subject: [Web-SIG] Collating follow-up on the future of WSGI In-Reply-To: References: <71B64498-C7AA-493D-BB9B-74264A145A11@lukasa.co.uk> <1B5EC8D5-A2B1-499A-ADE3-B969EC6851A6@gmail.com> <45B5DFE8-7951-4B21-9EEA-B30A61BB3908@gmail.com> Message-ID: <14CA583D-E9CD-41F4-8A57-C67CACB0B971@gmail.com> 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 appropriate WSGI environ prefix, as has been mentioned before, is what is covered by: http://wsgi.readthedocs.org/en/latest/specifications.html Being an extension means it is entirely optional for a WSGI server to try and implement it, thus allowing WSGI servers/adapters that cannot implement something to skip them. They stand as separate documents and would never become part of the core WGSI PEP. Is there an issue with doing extensions per the process, and in the WSGI environ namespace, that was outlined in that URL? You seem to be suggesting a completely new way of handling extensions and ignoring what was laid down before. So no one is saying you can?t have extensions, and that separate process gives you all the scope you need to do it. In drafting your specification just fit it reference to what is described in that URL, using ?x-wsgiorg.? prefix keys. Graham > On 21 Jan 2016, at 4:13 PM, 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 addition of an async api or an external api. I am not describing that. I am speaking about providing a low level abstraction like wsgi.input but adding to it the support of output. (I was referring to wsgi.multithread...). This low level interface would allow anyone to provide its own implementation(server) or usage (application) still acting as a *gateway* . > > Also who are "we"? I am starting to think the discussion is already done and only obscure details like the content_length or headers encoding should be discussed. The RAW_SOCKET have been added on demand of the gunicorn users. Such thing also exist in things like cherrypy if I remember. A lot of code around have been created over it. So before deciding it's unworkable or whatever I strongly invite you to consider it as an addition to the environ. And since some servers need to pass the data differently I then suggest a Resource object on which you can read and write and eventually poll. This is not a websocket but more a proxy ressource to the client connexion. I will come back asap with a small spec. > > I also propose a second addition to the protocol that formalize the addition of extensions to the protocol by the servers if they want to. Having for example something like "`wsg.extensions` . Such addition would help anyone to experiment changes over the wsgi before making such changes in the specification by itself possibly. > > I think we have a good opportunity to extend the WSGI specification to allow the users to take over the new challenges on the web without forcing them to use a concurrency mode or skip completely the WSGI spec. The interest I see in WSGI is its simplicity and low level interface allowing users to build whatever they want over it. The different workers and their support of different concurrency models and framework in gunicorn let me think it is possible. Are the participants of this thread ready to discuss it? > > - beno?t > > On Wed, 20 Jan 2016 at 23:37, Graham Dumpleton > wrote: >> 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 socket and having a separate high level API for implementing something like WebSocket this was already talked about. The suggestion was that it should not be a part of WSGI. Develop that API independently with no link to WSGI. The idea of upgrading from WSGI to a different API isn?t practical for various WSGI servers as it isn?t possible to unwind the state of the connection path created to get to point of handling the WSGI application. The better scenario is that the switch to an alternate WebSocket API is handled completely within the web server however it needs to handle it, when it needs to handle it, and not be reliant on going into a WSGI application which then says, oh, I actually need that to be WebSocket. > >> Now like we have wsgi.thread I would instead suggest to add a system of capability or extension like in smtp, imap, ... so the servers that implement a specific extension can legally published it. Would it work for you? > > Since there is nothing in WSGI environ called wsgi.thread now I have no idea what you are really suggesting here. > > Graham > >> benoit >> >> On Wed, 20 Jan 2016 at 21:28, Graham Dumpleton > wrote: >> >>> 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 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 application is running. And then nothing stop to give the >>> > socket away to the application and tell to the server to stop to communicate >>> > with it. >>> >>> What socket? >>> >>> Data could be being passed by shm, for instance. >>> >>> -Rob >>> >>> >>> While shared memory would be quite a bad idea, then why not. I still don't see why having a way to upgrade the connection can't be done. >>> >>> Call it I/O resource or Socket, the issue is the same. At the end nothing stop the server to pass the control to the app. If we forget the socket (which is btw the simplest design) then the server could stop to control the I/O resource when the application ask it to do it. At some point either a garbage collection or a basic resource return/claim flow could be used to definitely free the resource. >>> >>> The thing behind that is that it would allow the WSGI spec to only focus on providing a strict gateway workflow without forcing the application to adopt a concurrency model aync or not. >> >> No one has said you cannot do it. because though it is only able to be implemented in a subset of WSGI servers/adapters, then it doesn?t seem appropriate that it be a part of the core WSGI specification. >> >> This is the role of a WSGI extension as found at: >> >> http://wsgi.readthedocs.org/en/latest/specifications.html >> >> So go talk to the authors of uWSGI, and the other couple of packages available for trying to plug these into some of the pure Python based WSGI servers and come to an agreement between yourselves as to a standard way of doing it and the extension specification can be added to the wsgi.org site. >> >> Graham >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From bchesneau at gmail.com Thu Jan 21 01:39:51 2016 From: bchesneau at gmail.com (Benoit Chesneau) Date: Thu, 21 Jan 2016 06:39:51 +0000 Subject: [Web-SIG] Collating follow-up on the future of WSGI In-Reply-To: <14CA583D-E9CD-41F4-8A57-C67CACB0B971@gmail.com> References: <71B64498-C7AA-493D-BB9B-74264A145A11@lukasa.co.uk> <1B5EC8D5-A2B1-499A-ADE3-B969EC6851A6@gmail.com> <45B5DFE8-7951-4B21-9EEA-B30A61BB3908@gmail.com> <14CA583D-E9CD-41F4-8A57-C67CACB0B971@gmail.com> Message-ID: 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 extensions could be. Like capability field is in imap world. Also I am not trying to force anything, I want to discuss about a possible update of the wsgi spec which I thought was this thread about. What I just want to discuss is the *current* usage of some extensions that have been rapidly dismissed as unworkable. Like I said I will come with a more formal specification about them but I wanted to discuss first about and collect counter arguments which are good too. - beno?t On Thu, 21 Jan 2016 at 07:24, Graham Dumpleton wrote: > 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 appropriate WSGI environ prefix, as has been mentioned before, is > what is covered by: > > http://wsgi.readthedocs.org/en/latest/specifications.html > > Being an extension means it is entirely optional for a WSGI server to try > and implement it, thus allowing WSGI servers/adapters that cannot implement > something to skip them. They stand as separate documents and would never > become part of the core WGSI PEP. > > Is there an issue with doing extensions per the process, and in the WSGI > environ namespace, that was outlined in that URL? You seem to be suggesting > a completely new way of handling extensions and ignoring what was laid down > before. > > So no one is saying you can?t have extensions, and that separate process > gives you all the scope you need to do it. > > In drafting your specification just fit it reference to what is described > in that URL, using ?x-wsgiorg.? prefix keys. > > Graham > > > On 21 Jan 2016, at 4:13 PM, 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 addition of > an async api or an external api. I am not describing that. I am speaking > about providing a low level abstraction like wsgi.input but adding to it > the support of output. (I was referring to wsgi.multithread...). This low > level interface would allow anyone to provide its own > implementation(server) or usage (application) still acting as a *gateway* . > > Also who are "we"? I am starting to think the discussion is already done > and only obscure details like the content_length or headers encoding should > be discussed. The RAW_SOCKET have been added on demand of the gunicorn > users. Such thing also exist in things like cherrypy if I remember. A lot > of code around have been created over it. So before deciding it's > unworkable or whatever I strongly invite you to consider it as an addition > to the environ. And since some servers need to pass the data differently I > then suggest a Resource object on which you can read and write and > eventually poll. This is not a websocket but more a proxy ressource to the > client connexion. I will come back asap with a small spec. > > I also propose a second addition to the protocol that formalize the > addition of extensions to the protocol by the servers if they want to. > Having for example something like "`wsg.extensions` . Such addition would > help anyone to experiment changes over the wsgi before making such changes > in the specification by itself possibly. > > I think we have a good opportunity to extend the WSGI specification to > allow the users to take over the new challenges on the web without forcing > them to use a concurrency mode or skip completely the WSGI spec. The > interest I see in WSGI is its simplicity and low level interface allowing > users to build whatever they want over it. The different workers and their > support of different concurrency models and framework in gunicorn let me > think it is possible. Are the participants of this thread ready to discuss > it? > > - beno?t > > On Wed, 20 Jan 2016 at 23:37, Graham Dumpleton > wrote: > >> 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 socket and having a separate high level >> API for implementing something like WebSocket this was already talked >> about. The suggestion was that it should not be a part of WSGI. Develop >> that API independently with no link to WSGI. The idea of upgrading from >> WSGI to a different API isn?t practical for various WSGI servers as it >> isn?t possible to unwind the state of the connection path created to get to >> point of handling the WSGI application. The better scenario is that the >> switch to an alternate WebSocket API is handled completely within the web >> server however it needs to handle it, when it needs to handle it, and not >> be reliant on going into a WSGI application which then says, oh, I actually >> need that to be WebSocket. >> >> Now like we have wsgi.thread I would instead suggest to add a system of >> capability or extension like in smtp, imap, ... so the servers that >> implement a specific extension can legally published it. Would it work for >> you? >> >> >> Since there is nothing in WSGI environ called wsgi.thread now I have no >> idea what you are really suggesting here. >> >> Graham >> >> benoit >> >> On Wed, 20 Jan 2016 at 21:28, Graham Dumpleton < >> graham.dumpleton at gmail.com> wrote: >> >>> >>> On 21 Jan 2016, at 2:48 AM, Benoit Chesneau wrote: >>> >>> >>> >>> On Wed, Jan 20, 2016 at 1:57 AM Robert Collins < >>> robertc at robertcollins.net> 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 sort of wrapping done in the same >>>> thread/process >>>> > where the python application is running. And then nothing stop to >>>> give the >>>> > socket away to the application and tell to the server to stop to >>>> communicate >>>> > with it. >>>> >>>> What socket? >>>> >>>> Data could be being passed by shm, for instance. >>>> >>>> -Rob >>>> >>>> >>> While shared memory would be quite a bad idea, then why not. I still >>> don't see why having a way to upgrade the connection can't be done. >>> >>> Call it I/O resource or Socket, the issue is the same. At the end >>> nothing stop the server to pass the control to the app. If we forget the >>> socket (which is btw the simplest design) then the server could stop to >>> control the I/O resource when the application ask it to do it. At some >>> point either a garbage collection or a basic resource return/claim flow >>> could be used to definitely free the resource. >>> >>> The thing behind that is that it would allow the WSGI spec to only focus >>> on providing a strict gateway workflow without forcing the application to >>> adopt a concurrency model aync or not. >>> >>> >>> No one has said you cannot do it. because though it is only able to be >>> implemented in a subset of WSGI servers/adapters, then it doesn?t seem >>> appropriate that it be a part of the core WSGI specification. >>> >>> This is the role of a WSGI extension as found at: >>> >>> http://wsgi.readthedocs.org/en/latest/specifications.html >>> >>> So go talk to the authors of uWSGI, and the other couple of packages >>> available for trying to plug these into some of the pure Python based WSGI >>> servers and come to an agreement between yourselves as to a standard way of >>> doing it and the extension specification can be added to the wsgi.org >>> site. >>> >>> Graham >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cory at lukasa.co.uk Thu Jan 21 03:10:09 2016 From: cory at lukasa.co.uk (Cory Benfield) Date: Thu, 21 Jan 2016 08:10:09 +0000 Subject: [Web-SIG] Collating follow-up on the future of WSGI In-Reply-To: References: <71B64498-C7AA-493D-BB9B-74264A145A11@lukasa.co.uk> <1B5EC8D5-A2B1-499A-ADE3-B969EC6851A6@gmail.com> <45B5DFE8-7951-4B21-9EEA-B30A61BB3908@gmail.com> <14CA583D-E9CD-41F4-8A57-C67CACB0B971@gmail.com> Message-ID: <7D6DEF9F-9054-45F7-9988-10AA281D6BCB@lukasa.co.uk> > 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 it as clear as a separate namespace where to put all server extensions could be. Like capability field is in imap world. > > Also I am not trying to force anything, I want to discuss about a possible update of the wsgi spec which I thought was this thread about. What I just want to discuss is the *current* usage of some extensions that have been rapidly dismissed as unworkable. Like I said I will come with a more formal specification about them but I wanted to discuss first about and collect counter arguments which are good too. To clarify my own original message: when I described socket escape as ?unworkable?, I expressly meant within the core WSGI specification as a mandatory feature. I remain interested in seeing a proposal for a formalised specification for it as a WSGI extension, and if you?d like help in writing that proposal I?m happy to lend a hand. Cory -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From pje at telecommunity.com Sun Jan 31 19:42:20 2016 From: pje at telecommunity.com (PJ Eby) Date: Sun, 31 Jan 2016 19:42:20 -0500 Subject: [Web-SIG] Fwd: Collating follow-up on the future of WSGI In-Reply-To: References: <71B64498-C7AA-493D-BB9B-74264A145A11@lukasa.co.uk> <1B5EC8D5-A2B1-499A-ADE3-B969EC6851A6@gmail.com> <45B5DFE8-7951-4B21-9EEA-B30A61BB3908@gmail.com> Message-ID: 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 addition of > an async api or an external api. I am not describing that. I am speaking > about providing a low level abstraction like wsgi.input but adding to it the > support of output. (I was referring to wsgi.multithread...). This low level > interface would allow anyone to provide its own implementation(server) or > usage (application) still acting as a *gateway* . It sounds like you may be looking for something like this: https://gist.github.com/pjeby/62e3892cd75257518eb0 It's a proposed standard protocol for breaking out of WSGI from inside of a WSGI application, to access other protocols. It doesn't deal with the details of any particular upgraded protocol, it merely provides an "upgrade to specifed protocol" API and a way to safely pass it through arbitrary middleware. The `wsgi.upgrades` environment key is used to list available protocols. From andrew at aeracode.org Sun Jan 31 20:57:11 2016 From: andrew at aeracode.org (Andrew Godwin) Date: Sun, 31 Jan 2016 17:57:11 -0800 Subject: [Web-SIG] Fwd: Collating follow-up on the future of WSGI In-Reply-To: References: <71B64498-C7AA-493D-BB9B-74264A145A11@lukasa.co.uk> <1B5EC8D5-A2B1-499A-ADE3-B969EC6851A6@gmail.com> <45B5DFE8-7951-4B21-9EEA-B30A61BB3908@gmail.com> Message-ID: On Sun, Jan 31, 2016 at 4:42 PM, PJ Eby wrote: > 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 addition > of > > an async api or an external api. I am not describing that. I am speaking > > about providing a low level abstraction like wsgi.input but adding to it > the > > support of output. (I was referring to wsgi.multithread...). This low > level > > interface would allow anyone to provide its own implementation(server) or > > usage (application) still acting as a *gateway* . > > It sounds like you may be looking for something like this: > > https://gist.github.com/pjeby/62e3892cd75257518eb0 > > It's a proposed standard protocol for breaking out of WSGI from inside > of a WSGI application, to access other protocols. It doesn't deal > with the details of any particular upgraded protocol, it merely > provides an "upgrade to specifed protocol" API and a way to safely > pass it through arbitrary middleware. The `wsgi.upgrades` environment > key is used to list available protocols. 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. How would you see this interacting with potential asynchronous frameworks/reactors? The WebOb example only reacts to events also coming from within a WebSocket abstraction, but what if I wanted to e.g. send a message on database save? How would my application manage to trigger the WebSocket, in another thread or process, to do that? Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: