Lucas’s interpretation is correct – the setting warns that messages larger than the limit *will* fail, but does not guarantee that messages below the limit will not. It’s simply a short-circuit that enables the request to be rejected before transferring the headers.
I have no particular preference in how we track it – should the document get reopened in the future, any HfDU errata will have issues opened for them. From: QUIC <quic-boun...@ietf.org> On Behalf Of Zaheduzzaman Sarker Sent: Sunday, November 6, 2022 10:29 AM To: Martin Thomson <m...@lowentropy.net> Cc: quic@ietf.org Subject: Re: [Technical Errata Reported] RFC9114 (7238) If we plan to update the document later with more explanations (reflecting on the issue resolution) then rather rejecting we can put it state = "Held for Document Update”. //Zahed On 5 Nov 2022, at 10:46, Martin Thomson <m...@lowentropy.net<mailto:m...@lowentropy.net>> wrote: Having a more of an explanation (along the lines of that Lucas provided) might be worthwhile. The only question here is how that might be tracked. I would suggest that we reject this erratum and open an issue on the spec repository. On Fri, Nov 4, 2022, at 10:14, Jaikiran Pai wrote: Hello Lucas, Thank you for that explanation. I think your explanation is correct. Your explanation makes it clear to me now what that RFC text meant to convey. I am not a native English speaker, so I don't know if there's a need to edit the RFC text to make this clearer. -Jaikiran (reporter of this errata) On 04/11/22 3:37 pm, Lucas Pardue wrote: 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, <rfc-edi...@rfc-editor.org<mailto:rfc-edi...@rfc-editor.org>> 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 <jai.forums2...@gmail.com<mailto:jai.forums2...@gmail.com>> 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
