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

[Julian Reschke <[e-mail]>]

On 15.05.2020 04:27, Mark Nottingham wrote:
>  ...
>> 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).
>
> Right; the "how" is in 7230 3.2.2.

You know that I know that :-). The point being, RFC 7230 doesn't say
either (except that it needs to be COMMA + optional surrounding whitespace).

>> 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.
>
> Yes. That part of the text is really an aside explaining how things work, rather than anything normative.
>
>> 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.
>
> The problem is that many recipients won't be able to. This includes not only when an intermediary combines multiple field lines into one, but also when a server or library does so (which is more common IME).

Yes.

> We already have potential inconsistency in whitespace caused by such combination. I'm reluctant to add another dimension of inconsistency (whether or not the SH^HF implementation can recognise this situation and reject early).

Understood, but I would see it this way: having *some* implementations
able to detect broken input is better than nobody detecting it, because
this way the problem might be fixed.

I'd really like to hear some more feedback on this. Note that this is
related to what we can say in draft-ietf-httpbis-semantics - is a
recipient allowed *not* to combine field lines when they are clearly in
error, such as with:

   Location: https://example.com/foo
   Location: bar

?

>> If it is really intended to forbid that it might be good to add a short
>> explanation why this is the case.
>
> Yes.
>
> Also, I think we can more clearly prohibit implementations from sending that form (although I doubt it's much of an issue in practice).

Yes, this is totally an edge case.

Best regards, Julian