> 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? Cheers, -- Mark Nottingham https://www.mnot.net/ -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
