Re: draft-ietf-httpbis-header-structure: handling multiple field values

--------
In message <6121e33e-46d3-e361-9e4e-ad0158a0a8c5@gmx.de>, Julian Reschke writes
:

>The issue here is that combining
>
>   Foo: "a
>
>and
>
>   Foo: b"
>
>into
>
>   Foo: "a, b"
>
>*hides* an issue, and no failure will occur. Furthermore, we not only
>get no failure, but the resulting string may vary depending on how the
>fields were combined.
>
>I get that it's unavoidable that this *can* happen, but does this mean
>we should *disallow* failing for that input?

Yes, we should disallow it, because that would cause a valid request
to fail unless a proxy implemented a particular way is in the path.

I think we say this very clearly on page 23:

   When generating input_bytes, parsers MUST combine all lines in the
   same section (header or trailer) that case-insensitively match the
   field name into one comma-separated field-value, as per [RFC7230],
   Section 3.2.2; this assures that the entire field value is processed
   correctly.

Poul-Henning

PS: I think your example is wrong, the combined header would be:

    Foo: "a,b"

Because there is an important asymmetry in RFC7230/3.2.2.

A sender is required to know the syntax of the header is a comma
separated list, before can split the header.

A receiver on the other hand is under no such obligation, and therefore

   "…by appending each subsequent field value to
   the combined field value in order, separated by a comma."

should be interpreted narrowly:  Only a comma, not whitespace.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Tuesday, 12 May 2020 21:22:50 UTC