Re: Inviting feedback on my proposed "ASGI" spec

--===============8286749913208006668==
Content-Type: multipart/alternative; boundary=001a113cf5ac38a30c052dc9b479

--001a113cf5ac38a30c052dc9b479
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

One thing I did want to ask - is it worth still squashing everything down
to the same case? Daphne already clears out headers with _ in them to avoid
that CVE about it, and header case is never semantic, or so I thought?

Andrew

On Fri, Mar 11, 2016 at 9:56 AM, Andrew Godwin <[email protected]> wrote:

>
>
> On Fri, Mar 11, 2016 at 2:28 AM, Cory Benfield <[email protected]> wrote:
>
>>
>> On 10 Mar 2016, at 23:56, Andrew Godwin <[email protected]> wrote:
>>
>> I would indeed want to require servers to always fold headers together
>> into a comma-separated list, as that's what the RFC says, and it then me=
ans
>> applications only have to deal with one kind of multi-header!
>>
>>
>> Wellllll=E2=80=A6.kinda?
>>
>> The RFC says that multiple headers are *semantically equivalent* to the
>> joined form, but does not in any sense require that it be done. (The
>> normative language in RFC 7230 is MAY.)
>>
>> I had this discussion recently with Brian Smith: while there is only one
>> correct way to fold/unfold headers, anywhere on the spectrum between
>> completely folded and completely unfolded is a perfectly valid
>> representation of the HTTP header block. This means that there=E2=80=99s=
 no *rules*
>> about how a server is supposed to do it, at least from the IETF. ASGI is=
 of
>> course totally allowed to add its own rules, and requiring that they be
>> folded is not terrible.
>>
>> FWIW, in my experience, I=E2=80=99ve found that =E2=80=9Clist of tuples=
=E2=80=9D is really the
>> most likely to be correct way to represent a header block, because it
>> provides some assurances to the user that the header block has not been
>> aggressively transformed from how it was sent on the wire. While the
>> *rules* are that the folded representation is supposed to be semanticall=
y
>> equivalent to the unfolded representation, there is nonetheless some
>> information implicit in those headers being separate.
>>
>> My intuition when writing this kind of thing is to pass applications
>> (like Django) the most meaningful representation I can, and then allow t=
he
>> application to make its own decisions about what meaning they=E2=80=99re=
 willing to
>> lose. That=E2=80=99s why I=E2=80=99d advocate for =E2=80=9Clist of two-t=
uples of bytestrings=E2=80=9D as
>> the representation. However, I don=E2=80=99t think there=E2=80=99s anyth=
ing *wrong* with
>> forcing the headers to be joined by the server where possible: it=E2=80=
=99s just
>> not how I=E2=80=99d do it. ;)
>>
>> Set-cookie is the annoying thing here, though. That's why it's dict
>> inbound and list of tuples outbound right now, and I just don't know if =
I
>> want to make the inbound one a list of tuples too, given I do definitely
>> want to force servers to concat headers together (unless I find any
>> examples of that screwing things up)
>>
>>
>> You could make the inbound one a list of tuples but still require that
>> the servers concat headers. The rule then would be that it needs to be
>> possible for an application to say `dict(headers)` without any loss of
>> meaning.
>>
>
> Yes, I think this is a good argument - my worry has always been that the
> "no multiples" is more of a soft rule that some clients might break or so=
me
> apps might rely on the ordering/multiplicity of things, so preserving it =
is
> _probably_ helpful (and as you say, it lets the header names go back to
> bytestrings).
>
> I'll modify the spec and then update Daphne and Channels to match; I can
> leave Channels parsing both types for a bit, at least.
>
> Collin's point about http2's handling of headers is on point, too - if th=
e
> new spec is deliberately thinned down to that point but no further, it's
> probably wise to follow them since they know much more about it than I do=
.
>
> Andrew
>

--001a113cf5ac38a30c052dc9b479
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">One thing I did want to ask - is it worth still squashing =
everything down to the same case? Daphne already clears out headers with _ =
in them to avoid that CVE about it, and header case is never semantic, or s=
o I thought?<div><br></div><div>Andrew</div></div><div class=3D"gmail_extra=
"><br><div class=3D"gmail_quote">On Fri, Mar 11, 2016 at 9:56 AM, Andrew Go=
dwin <span dir=3D"ltr">&lt;<a href=3D"mailto:[email protected]" target=3D=
"_blank">[email protected]</a>&gt;</span> wrote:<br><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D=
"gmail_quote"><span class=3D"">On Fri, Mar 11, 2016 at 2:28 AM, Cory Benfie=
ld <span dir=3D"ltr">&lt;<a href=3D"mailto:[email protected]" target=3D"_bl=
ank">[email protected]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div style=3D"word-wrap:break-word"><br><div><span><blockquote type=3D"=
cite"><div>On 10 Mar 2016, at 23:56, Andrew Godwin &lt;<a href=3D"mailto:an=
[email protected]" target=3D"_blank">[email protected]</a>&gt; wrote:</di=
v><div><div dir=3D"ltr" style=3D"font-family:Helvetica;font-size:12px;font-=
style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text=
-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div c=
lass=3D"gmail_extra"><div class=3D"gmail_quote"><div><br></div><div>I would=
 indeed want to require servers to always fold headers together into a comm=
a-separated list, as that&#39;s what the RFC says, and it then means applic=
ations only have to deal with one kind of multi-header!</div></div></div></=
div></div></blockquote><div><br></div></span><div>Wellllll=E2=80=A6.kinda?<=
/div><div><br></div><div>The RFC says that multiple headers are *semantical=
ly equivalent* to the joined form, but does not in any sense require that i=
t be done. (The normative language in RFC 7230 is MAY.)</div><div><br></div=
><div>I had this discussion recently with Brian Smith: while there is only =
one correct way to fold/unfold headers, anywhere on the spectrum between co=
mpletely folded and completely unfolded is a perfectly valid representation=
 of the HTTP header block. This means that there=E2=80=99s no *rules* about=
 how a server is supposed to do it, at least from the IETF. ASGI is of cour=
se totally allowed to add its own rules, and requiring that they be folded =
is not terrible.</div><div><br></div><div>FWIW, in my experience, I=E2=80=
=99ve found that =E2=80=9Clist of tuples=E2=80=9D is really the most likely=
 to be correct way to represent a header block, because it provides some as=
surances to the user that the header block has not been aggressively transf=
ormed from how it was sent on the wire. While the *rules* are that the fold=
ed representation is supposed to be semantically equivalent to the unfolded=
 representation, there is nonetheless some information implicit in those he=
aders being separate.</div><div><br></div><div>My intuition when writing th=
is kind of thing is to pass applications (like Django) the most meaningful =
representation I can, and then allow the application to make its own decisi=
ons about what meaning they=E2=80=99re willing to lose. That=E2=80=99s why =
I=E2=80=99d advocate for =E2=80=9Clist of two-tuples of bytestrings=E2=80=
=9D as the representation. However, I don=E2=80=99t think there=E2=80=99s a=
nything *wrong* with forcing the headers to be joined by the server where p=
ossible: it=E2=80=99s just not how I=E2=80=99d do it. ;)</div><span><br><bl=
ockquote type=3D"cite"><div><div dir=3D"ltr" style=3D"font-family:Helvetica=
;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;=
text-align:start;text-indent:0px;text-transform:none;white-space:normal;wor=
d-spacing:0px"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>S=
et-cookie is the annoying thing here, though. That&#39;s why it&#39;s dict =
inbound and list of tuples outbound right now, and I just don&#39;t know if=
 I want to make the inbound one a list of tuples too, given I do definitely=
 want to force servers to concat headers together (unless I find any exampl=
es of that screwing things up)</div></div></div></div></div></blockquote><b=
r></span></div><div>You could make the inbound one a list of tuples but sti=
ll require that the servers concat headers. The rule then would be that it =
needs to be possible for an application to say `dict(headers)` without any =
loss of meaning.</div></div></blockquote><div><br></div></span><div>Yes, I =
think this is a good argument - my worry has always been that the &quot;no =
multiples&quot; is more of a soft rule that some clients might break or som=
e apps might rely on the ordering/multiplicity of things, so preserving it =
is _probably_ helpful (and as you say, it lets the header names go back to =
bytestrings).</div><div><br></div><div>I&#39;ll modify the spec and then up=
date Daphne and Channels to match; I can leave Channels parsing both types =
for a bit, at least.</div><div><br></div><div>Collin&#39;s point about http=
2&#39;s handling of headers is on point, too - if the new spec is deliberat=
ely thinned down to that point but no further, it&#39;s probably wise to fo=
llow them since they know much more about it than I do.</div><span class=3D=
"HOEnZb"><font color=3D"#888888"><div><br></div><div>Andrew=C2=A0</div></fo=
nt></span></div></div></div>
</blockquote></div><br></div>

--001a113cf5ac38a30c052dc9b479--

--===============8286749913208006668==
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

--===============8286749913208006668==--