[Web-SIG] WSGI 2.0 Round 2: requirements and call for interest

[Graham Dumpleton]

> On 5 Jan 2016, at 10:57 PM, Graham Dumpleton <graham.dumpleton at gmail.com> wrote:
> 
> 
>> On 5 Jan 2016, at 10:26 PM, Cory Benfield <cory at lukasa.co.uk <mailto:cory at lukasa.co.uk>> 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: <http://mail.python.org/pipermail/web-sig/attachments/20160105/a0c86bd3/attachment.html>