Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest
> 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 ___ 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
Re: [Web-SIG] WSGI 2.0 Round 2: requirements and call for interest
>>> **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 ___ 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
Re: [Web-SIG] REMOTE_ADDR and proxys
On 29 September 2014 23:14, Collin Anderson cmawebs...@gmail.com wrote: Thanks guys. So it sounds like it should be the responsibility of a middleware to re normalize the environment? I don't think it's always like that. The knowledge of the setup related to REMOTE_ADDR and trusted proxies is with the system admin, and he is the one setting up the WSGI server. So unless the developer implements and allows configuring the said middleware, sys-admins hands are tied to do anything about it. BTW, currently when I use nginx/uwsgi I have to configure my nginx what its trusted proxies are, and what headers (or else they use) and uwsgi luckily doesn't need additional setup when using the uwsgi protocol, it just gets the nginx REMOTE_ADDR info. -- damjan ___ 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
