Re: WSGI 2.0 Round 2: requirements and call for interest
Benoit Chesneau <[email protected]> Wed, 06 Jan 2016 09:13:01 +0000
| Newsgroups | gmane.comp.python.web |
|---|---|
| Message-ID | <CAJNb-9r9hRryM_c7KENHc7G_VMWYzp7ptRQA+xfXkm=Dgs61Uw@mail.gmail.com> |
--===============5862658966092452401== Content-Type: multipart/alternative; boundary=001a11401f3c693bff0528a6c3c7 --001a11401f3c693bff0528a6c3c7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jan 5, 2016 at 3:17 PM Aymeric Augustin < aymeric.augustin.2003-o/5/jSaJEHk+NdeTPqioyti2O/[email protected]> wrote: > Hello Beno=C3=AEt, > > > Le mardi 5 janvier 2016 14:13:48 UTC+1, Benoit Chesneau a =C3=A9crit : >> >> Header formats which are btw US-ASCII in the HTTP spec now, could be >> already solved if only the frameworks could comply with the spec instead= of >> trying to impose their own rules. >> > > That's just a detail, but either I misunderstood you or you blamed the > wrong side here. > > Non-ASCII data in request headers isn't a problem created by frameworks, > it's a problem created by (possibly non compliant) user-agents. > I had in mind this ticket: https://github.com/benoitc/gunicorn/issues/1151 As of today, because some applications are still sending response in a a non compliant way we are trying to recode the headers on the server side so we can send them. Today like in apache 2 (and I think nginx) we now just ignore headers that can't be encoded in us-ascii. If all applications/framework would give us the headers as Latin1 it wouldn't be a major problem, but that's not the case. > > If future-WSGI guaranteed that HTTP header values provided in environ onl= y > contain ASCI, fameworks would be happy. Servers would likely have to > respond 400 to requests containing non-ASCII headers, which would likely = be > considered a problematic backwards-incompatibility. It would go against t= he > IETF principle of being tolerant in what a system accepts. > We should also update the spec to reflect the latest changes in the HTTP specs to force applications to send to the gateway US-ASCII headers. > > If future-WSGI provided header values as bytes, frameworks would be happy > as well. That would be my preference, because the application is in the > best position to pick a charset for decoding the values (that would be > UTF-8 in general). > > If future-WSGI insists on decoding header values with an arbitrary > encoding, I believe it should do so with UTF-8 rather than ISO-8859-1. "T= he > server is decoding with ISO-8859-1 so the application can reencode to get > the raw bytes" never sounded like a compelling argument to me. It will > still be wrong in theory, but it will generally give the right results in > practice. > Hmm but, actually the HTTP spec insist that headers are neither utf-8, neither latin1 (iso8859-1) but US-ASCII: https://github.com/benoitc/gunicorn/issues/1151#issuecomment-158884740 so native strings or bytes are fine for me until we make sure that we are sending and receiving US-ASCII. > Best regards, > > > -- > Aymeric. > > PS: if you find Django trying to impose its own rules, I'll do my best to > correct that. As much as I can speak for the Django team, this isn't our > intent. Please flag such cases so we can make sure there's no > misunderstanding. Thanks! > > Thanks! I will if needed :) - beno=C3=AEt --001a11401f3c693bff0528a6c3c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue= , Jan 5, 2016 at 3:17 PM Aymeric Augustin <<a href=3D"mailto:aymeric.aug= ustin.2003-o/5/jSaJEHk+NdeTPqioyti2O/[email protected]">aymeric.augustin.2003-o/5/jSaJEHk+NdeTPqioyti2O/[email protected]</a>&g= t; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 = .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hello Be= no=C3=AEt,</div><div dir=3D"ltr"><br><br>Le mardi 5 janvier 2016 14:13:48 U= TC+1, Benoit Chesneau a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" = style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left= :1ex"><div dir=3D"ltr">Header formats which are btw US-ASCII in the HTTP sp= ec now, could be already solved if only the frameworks could comply with th= e spec instead of trying to impose their own rules.</div></blockquote></div= ><div dir=3D"ltr"><div><br>That's just a detail, but either I misunders= tood you or you blamed the wrong side here.<br><br>Non-ASCII data in reques= t headers isn't a problem created by frameworks, it's a problem cre= ated by (possibly non compliant) user-agents.<br></div></div></blockquote><= div><br></div><div>I had in mind this ticket:</div><div><a href=3D"https://= github.com/benoitc/gunicorn/issues/1151">https://github.com/benoitc/gunicor= n/issues/1151</a><br></div><div><br></div><div>As of today, because some ap= plications are still sending response in a a non compliant way we are tryin= g to recode the headers on the server side so we can send them. Today like = in apache 2 (and I think nginx) we now just ignore headers that can't b= e encoded in us-ascii. If all applications/framework would give us the head= ers as Latin1 it wouldn't be a major problem, but that's not the ca= se.</div><div><br></div><div><br></div><div>=C2=A0</div><blockquote class= =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= ing-left:1ex"><div dir=3D"ltr"><div><br>If future-WSGI guaranteed that HTTP= header values provided in environ only contain ASCI, fameworks would be ha= ppy. Servers would likely have to=20 respond 400 to requests containing non-ASCII headers, which would likely be= considered a problematic backwards-incompatibility. It would go against th= e IETF principle of being tolerant in what a system accepts.<br></div></div= ></blockquote><div><br></div><div>We should also update the spec to reflect= the latest changes in the HTTP specs to force applications to send to the = gateway US-ASCII headers.=C2=A0</div><blockquote class=3D"gmail_quote" styl= e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div di= r=3D"ltr"><div><br>If future-WSGI provided header values as bytes, framewor= ks would be happy as well. That would be my preference, because the applica= tion is in the best position to pick a charset for decoding the values (tha= t would be UTF-8 in general).<br><br>If future-WSGI insists on decoding hea= der values with an arbitrary encoding, I believe it should do so with UTF-8= rather than ISO-8859-1. "The server is decoding with ISO-8859-1 so th= e application can reencode to get the raw bytes" never sounded like a = compelling argument to me. It will still be wrong in theory, but it will ge= nerally give the right results in practice.<br></div></div></blockquote><di= v><br></div><div>Hmm but, actually the HTTP spec insist that headers are ne= ither utf-8, neither latin1 (iso8859-1) but US-ASCII:=C2=A0</div><div><br><= /div><div><a href=3D"https://github.com/benoitc/gunicorn/issues/1151#issuec= omment-158884740">https://github.com/benoitc/gunicorn/issues/1151#issuecomm= ent-158884740</a><br></div><div>=C2=A0</div><div>so native strings or bytes= are fine for me until we make sure that we are sending and receiving US-AS= CII.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:= 0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><d= iv><br>Best regards,</div></div><div dir=3D"ltr"><div><br><br>-- <br>Aymeri= c.<br></div></div><div dir=3D"ltr"><div><br>PS: if you find Django trying t= o impose its own rules, I'll do my=20 best to correct that. As much as I can speak for the Django team, this=20 isn't our intent. Please flag such cases so we can make sure there'= s no misunderstanding. Thanks!<br><br></div></div></blockquote><div><br></d= iv><div>Thanks! I will if needed :)</div><div><br></div><div>- beno=C3=AEt<= /div></div></div> --001a11401f3c693bff0528a6c3c7-- --===============5862658966092452401== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Web-SIG mailing list [email protected] Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org --===============5862658966092452401==--