Re: Last Call: <draft-ietf-httpbis-header-structure-18.txt> (Structured Field Values for HTTP) to Proposed Standard

[Julian Reschke <[e-mail]>]

Hi there,

I note that this mail was cc'd to the HTTP WG mailing list
([e-mail]), but apparently didn't make it there (see
<https://lists.w3.org/Archives/Public/ietf-http-wg/2020AprJun/>). We
really should find out what went wrong here.

(the same seems to have happened for the LC on
draft-ietf-httpbis-client-hints-13 a few days later)

I'll use that as somewhat lame excuse for a very late comment on the
document (I've been working on an implementation and this came up just
yesterday):

<https://tools.ietf.org/html/draft-ietf-httpbis-header-structure-18#section-4.2>
says:

>    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.

It doesn't require *how* to combine these values (and that's ok because
it can't).

Later on it says:

>    Strings split across multiple field lines will have unpredictable
>    results, because comma(s) and whitespace inserted upon combination
>    will become part of the string output by the parser.  Since
>    concatenation might be done by an upstream intermediary, the results
>    are not under the control of the serializer or the parser.

So there are HTTP messages that can lead to different parsing results,
depending on what intermediaries do (how *they* combine the lines), and
what the final recipient does.

That this can happen for certain inputs is a given; *this* spec can't do
anything about that as it doesn't control the other parts in the
transmission chain.

What bugs me is that we have an invalid message to start with, but the
spec apparently *requires* receivers to accept it, albeit with
potentially unpredictable results.

IMHO it would be better to allow those recipients that *can* detect the
brokenness to reject these fields.

If it is really intended to forbid that it might be good to add a short
explanation why this is the case.

Best regards, Julian