Hi,
On 05/01/2016 13:09, Luke Plant wrote:
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.
Alright. I bite: if it would not be done that way you had different
problems. In particular a problem that comes up very often is that
people want the PATH_INFO and SCRIPT_NAME to not be encoded. That
however completely breaks any form of routing you would want to do the
moment they contain unicode characters.
I keep having the argument about PATH_INFO and the header semantics
constantly with people and i'm absolutely convinced (from the theory
behind it as well as playing around with ideas for PEP 444 a few years
ago) that it only gets worse the moment you leave the WSGI territory too
far.
Likewise I wonder how many people that ask for more low level access
concerned themselves with chunked requests/responses, transport
encodings and all the complexity that servers do for you. Yes, quite a
bit of this is broken in WSGI but would have been trivial to fix without
throwing the whole specification into the toilette :)
Regards,
Armin
_______________________________________________
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
