Re: [Technical Errata Reported] RFC9110 (7870)

[Mark Nottingham <[e-mail]>]

REJECT.

'forward' and 'send' are defined terms in the specification, and the previous paragraph covers the 'send' -- this requirement is specific to forwarding. It's specifically there to call out the exception _only_ in the forwarding case. The existing text already specifies your option #2. 

How does the existing text not allow a message to be forwarded once the invalid field is replaced?


> On 25 Mar 2024, at 05:33, RFC Errata System <[e-mail]> wrote:
> 
> The following errata report has been submitted for RFC9110,
> "HTTP Semantics".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7870
> 
> --------------------------------------
> Type: Technical
> Reported by: Ben Kallus <[e-mail]>
> 
> Section: 8.6
> 
> Original Text
> -------------
>   Likewise, a sender MUST NOT forward a message with a Content-Length
>   header field value that does not match the ABNF above, with one
>   exception: a recipient of a Content-Length header field value
>   consisting of the same decimal value repeated as a comma-separated
>   list (e.g, "Content-Length: 42, 42") MAY either reject the message as
>   invalid or replace that invalid field value with a single instance of
>   the decimal value, since this likely indicates that a duplicate was
>   generated or combined by an upstream message processor.
> 
> Corrected Text
> --------------
>   Likewise, a sender MUST NOT send a message with a Content-Length
>   header field value that does not match the ABNF above. A
>   recipient of a Content-Length header field value consisting of
>   the same decimal value repeated as a comma-separated list (e.g,
>   "Content-Length: 42, 42") MAY either reject the message as invalid
>   or replace that invalid field value with a single instance of the
>   decimal value, since this likely indicates that a duplicate was
>   generated or combined by an upstream message processor.
> 
> Notes
> -----
> This change aims to fix 2 issues with the text:
> 
> Issue #1
> Recall the following from section 8.6:
>> Likewise, a sender MUST NOT forward a message with a Content-Length header field value that does not match the ABNF above, ...
> 
> It wasn't immediately clear to me which of these was the intended meaning:
> 1. Upon receipt of a message with an invalid Content-Length value, senders MUST NOT forward the message.
> 2. Upon receipt of a message with an invalid Content-Length value, senders MUST NOT forward the message with the invalid value intact.
> 
> Mark Nottingham confirmed on GitHub that the intended meaning is option 2:
> https://github.com/httpwg/http-core/issues/1113#issuecomment-1937914210
> 
> I propose that the word "forward" be changed to "send" to clear up the ambiguity.
> 
> Issue #2
> We've just established that the intended meaning of the first half of the sentence in question is that malformed CL header values MUST NOT be forwarded intact.
> An exception to this rule is (by definition) a situation in which invalid CL header values *are* permitted to be forwarded intact.
> The "exception" described in the text does not allow for invalid header values to be forwarded intact, so it is a misuse of the word "exception."
> 
> To clear this up, I propose that the sentence be split in two, and that the word "exception" be removed.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". (If it is spam, it 
> will be removed shortly by the RFC Production Center.) Please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> will log in to change the status and edit the report, if necessary.
> 
> --------------------------------------
> RFC9110 (draft-ietf-httpbis-semantics-19)
> --------------------------------------
> Title               : HTTP Semantics
> Publication Date    : June 2022
> Author(s)           : R. Fielding, Ed., M. Nottingham, Ed., J. Reschke, Ed.
> Category            : INTERNET STANDARD
> Source              : HTTP
> Stream              : IETF
> Verifying Party     : IESG

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