> On 5 Jan 2016, at 10:57 PM, Graham Dumpleton <graham.dumple...@gmail.com>
> wrote:
>
>
>> On 5 Jan 2016, at 10:26 PM, Cory Benfield <c...@lukasa.co.uk
>> <mailto:c...@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
_______________________________________________
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
