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

[Julian Reschke <[e-mail]>]

On 18.05.2020 08:06, Mark Nottingham wrote:
>
>> On 15 May 2020, at 6:20 pm, Julian Reschke <[e-mail]> wrote:
>>>
>>>> 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
>
> I think this means adding something like this near the bottom of 4.2. Parsing Structured Fields:
>
> """
> Parsers MAY fail when processing a field value spread across multiple field lines, when one of those lines does not parse as that field. For example, a parsing handling an Example-String field that's defined as a sf-string is allowed to fail when processing this field section:
>
> Example-String: "foo
> Example-String: bar"
> """
>
> Does that do it?

Looks very good to me.

Best regards, Julian