Re: Request for Input: WSGI 2.0

One more thing — while this isn’t a use case I have myself, some people rely on the ability to run an application at a sub-part e.g. under https://example.com/appname/. WSGI should normalize the headers involved in that case so that applications don’t have custom code for various servers. Djang

Re: Request for Input: WSGI 2.0

On Tuesday, January 5, 2016 at 10:37:32 AM UTC, Aymeric Augustin wrote: > > 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. > > Thanks Aymeric, this feedback was extremely valuable. I've forwarded i

Re: Request for Input: WSGI 2.0

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.

Re: Request for Input: WSGI 2.0

Hi Cory, I'll reply on the Web-SIG mailing list too, but as I've outlined elsewhere, 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 doe

Re: Request for Input: WSGI 2.0

Hi Cory, [Disclaimer - I don't suppose to speak for the whole community here, this is a personal opinion of how I see things] Django's wsgi handling code has remained largely unchanged for many years, so to answer the question of "what does Django itself need from new wsgi, ignoring channels", I'

Request for Input: WSGI 2.0

All, An effort has begun over in the PSF Web-SIG special interest group to come up with a new version of the WSGI specification. The goal is to develop a successor to WSGI that will be more useful in the development of modern