Hi, Speaking as an individual, I think the current RFC text is correct. The problem that is being described is where 1) a client sends a message smaller than MAX_FIELD_SECTION_SIZE and might expect that to work but 2) the server is an intermediary that needs to forward the message onto another server that, for example, has a smaller value for MAX_FIELD_SECTION_SIZE preventing this.
In other words, even if the client plays by the rules of the first hop by staying under the limit, there is no guarantee that other hops that the client is not aware of won't reject the message. Cheers Lucas On Fri, 4 Nov 2022, 09:49 RFC Errata System, <[email protected]> wrote: > The following errata report has been submitted for RFC9114, > "HTTP/3". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid7238 > > -------------------------------------- > Type: Technical > Reported by: Jaikiran Pai <[email protected]> > > Section: 4.2.2 > > Original Text > ------------- > Because this limit is applied separately by each implementation that > processes the message, messages below this limit are not guaranteed > to be accepted. > > > Corrected Text > -------------- > Because this limit is applied separately by each implementation that > processes the message, messages above this limit are not guaranteed > to be accepted. > > > Notes > ----- > The section 4.2.2 specifies header size constraints and notes that > implementations can send a SETTINGS frame with a > SETTINGS_MAX_FIELD_SECTION_SIZE identifier to set a limit on the maximum > size of the message header. Since this a maximum size, the sentence that > states that intermediaries aren't guaranteed to accept a message below this > limit seems odd and I think it should instead say "above this limit". > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC9114 (draft-ietf-quic-http-34) > -------------------------------------- > Title : HTTP/3 > Publication Date : June 2022 > Author(s) : M. Bishop, Ed. > Category : PROPOSED STANDARD > Source : QUIC > Area : Transport > Stream : IETF > Verifying Party : IESG >
