On 20 January 2016 at 05:55, Cory Benfield <c...@lukasa.co.uk> 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 <rbtcoll...@hpe.com> Distinguished Technologist HP Converged Cloud _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
