Hi,
I am going to mark this as Reject. For the second point, I think the current text is in fact clear – see it this way: message X has a Content-Length header invalid field value; it MUST NOT be forwarded except in some special case, if some processing is done beforehand. Yes, the processing removes the field invalidity, but the condition for the exception on forwarding X was verified beforehand.
Willy: this might have been a good addition to have (also based on Ben’s comments), and I hope the wg keeps it in mind. However, this sort of proposal doesn’t need to be in an erratum.
Thanks for the discussion,
Francesca
From: Willy Tarreau <w@1wt.eu>
Date: Tuesday, 26 March 2024 at 05:15
To: Mark Nottingham <mnot@mnot.net>
Cc: Ben Kallus <benjamin.p.kallus.gr@dartmouth.edu>, RFC Errata System <rfc-editor@rfc-editor.org>, Roy Fielding <fielding@gbiv.com>, Julian F. Reschke <julian.reschke@greenbytes.de>, httpbis-ads@ietf.org <httpbis-ads@ietf.org>, Tommy Pauly <tpauly@apple.com>, ietf-http-wg@w3.org <ietf-http-wg@w3.org>
Subject: Re: [Technical Errata Reported] RFC9110 (7870)
Hi Mark,
On Tue, Mar 26, 2024 at 11:12:11AM +1100, Mark Nottingham wrote:
> OK. I understand how you can read it that way, but it's quite contorted; I
> don't think the current text is unclear. Rewriting to remove the word
> 'exception' would imply that there are other situations where the message
> could be forwarded after rewriting, and that is undesirable.
This makes me think that for future versions of the spec, we should
probably keep in mind that some agents sometimes have to fix certain
parts before forwarding/processing them and that it might be useful
to orient various parts as "must not forward this or that unless fixed"
then have a special paragraph describing exactly what ought to be fixed,
i.e. how exactly to proceed to satisfy the exception that allows to
forward the message. It would more clearly an consistently differentiate
between what to check for and what to address in order for the message
to be forwarded. This would conveniently cover the various tricky parts
around duplicated C-L, T-E vs C-L, how to deal with Connection, header
folding, aggregation of multiple fields into a single one when a quote
is present, etc.
Cheers,
Willy