[Errata Rejected] RFC9110 (7870)

The following errata report has been rejected for RFC9110,
"HTTP Semantics".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7870

--------------------------------------
Status: Rejected
Type: Technical

Reported by: Ben Kallus <benjamin.p.kallus.gr@dartmouth.edu>
Date Reported: 2024-03-24
Rejected by: Francesca Palombini (IESG)

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.
 --VERIFIER NOTES-- 
Issue #1: '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.

For issue #2, this might be more than an editorial problem, but mostly I disagree about "exception" being a misuse. I agree that more extensive editorial work could be done, but that is out of scope for an erratum.

See https://mailarchive.ietf.org/arch/msg/httpbisa/wYhoNFePlmmj5g58g_70er8pTH4/

--------------------------------------
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

Received on Tuesday, 14 May 2024 08:01:53 UTC