Just to add my 2c - as another Django developer, I agree completely with
Aymeric here. My own experience was that the HTTP handling done by WSGI
(especially URL handing, HTTP header mangling, os.environ as a
destination - all due to CGI compatibility - and semi-broken unicode
handling) only made things harder for us. We would much rather have
dealt with raw streams of bytes and done all HTTP parsing ourselves.
Like Graham said, for HTTP/2 let's ignore the history of WSGI and start
from scratch with a API that actually serves us well.
Regards,
Luke
On 05/01/16 11:26, Cory Benfield 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.
2. More generally, I fail to see how mixing HTTP headers, server-related
inputs, and environment variables in a dict adds values. It prevents iterating
on each collection separately. It only makes sense if not offering more
features than CGI is a design goal; in that case, this discussion doesn’t serve
a purpose anyway. It would be nicer and possibly more secure if the application
received separately:
a. Configuration information, which servers could read from environment
variables by default for backwards compatibility, but could also get through
more secure channels and restrict to what the application needs in order to
better isolate it from the entire OS.
b. Server APIs mandated by the spec, per request.
c. HTTP headers, per request.
3. Stop pretending that HTTP is a unicode protocol, or at least stop ignoring
reality when doing so. WSGI enforces ISO-8859-1-decoded str objects in the
environ, which is just wrong. It’s all the more a surprising choice since this
change was driven by Python 3, that UTF-8 is the correct choice, and that
Python 3 defaults to UTF-8. Django has to re-encode and re-decode before doing
anything with HTTP headers:
https://github.com/django/django/blob/d5b90c8e120687863c1d41cf92a4cdb11413ad7f/django/core/handlers/wsgi.py#L231-L253
4. Normalize the way to tell the application about the original protocol, IP
address and port. When dev and ops responsibilities are separate, this is
clearly an ops responsibility, but due to the lack of standardization devs end
up dealing with this problem in custom middleware, when they do it at all.
Everyone keeps getting it wrong, which introduces security vulnerabilities.
Also it always breaks silently on infrastructure changes.
5. Improve request / response length handling and connection closure. Armin and
Graham have talked about in the past and know the topic better than I do.
There’s also a rejected PEP by Armin which made sense to me.
As you can see from these comments, I don’t quite share the design choices that
led to WSGI as it currently stands. I think it will be easier to build a new
standard than evolve the current one.
I hope this helps!
Aymeric
_______________________________________________
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/l.plant.98%40cantab.net
--
"Trouble: Luck can't last a lifetime, unless you die young."
(despair.com)
Luke Plant || http://lukeplant.me.uk/
_______________________________________________
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
