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

> On 15 May 2020, at 6:20 pm, Julian Reschke <julian.reschke@gmx.de> 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?

Cheers,


--
Mark Nottingham   https://www.mnot.net/

Received on Monday, 18 May 2020 06:06:34 UTC