On 18.05.2020 08:06, Mark Nottingham wrote:
On 15 May 2020, at 6:20 pm, Julian Reschke <julian.reschke@xxxxxx> 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
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
