Hi, Adding the HTTP WG list because they are the maintainers of HTTP/2 and HTTP/3 and this topic is beyond the remit of QUIC.
Responding in line: On Fri, Jun 12, 2026, at 04:30, Christian Huitema wrote: > Since I am the "maintainer of picoquic" quoted in the zhangph's email, > let me provide a bit more context. > > The generic behavior in parsing settings is to ignore anything that the > local implementation does not understand. RFC 9114 says that, and then > also says a bit later that some settings should not be just ignored, but > also ignored with prejudice. The prejudice applies to the 5 parameters > that are defined in HTTP2 but have no meaning in HTTP3, but as it is > written it would also apply to all new parameters that will be defined > for HTTP2 in the future but do not apply to HTTP3. That latter > requirement is, shall we say, not entirely realistic. The normative language we're talking about here is _all_ in the section that defines HTTP/3 settings. Not only that, the sentence that states "An implementation MUST ignore any parameter with an identifier it does not understand." is immediately followed by the sub-section that goes on to define settings. I think this erratum is overstretching on the the problem statement. There is very clear language about the settings values defined in the HTTP/2 spec (not extension specs) and that those have been reserved and MUST NOT be used. > > Coming back to the distinction between "ignore" and "ignore with > prejudice". The main reason for that requirement is to enforce that any > implementation that errs into reusing HTTP2 parameters for H3 will > encounter so many connection failures that it would have no choice but > to fix their code. It is a classic consequence of the "Postel was wrong" > argument: by providing stark consequences to any deviation of the > standard, we ensure that the standard remains pure. > > We have a couple of similar prohibitions in RFC9000, and we generally > adopted a "MUST ignore, MAY yell" pattern. This is a practical solution, > because if enough implementations do the "MAY" part, the deviants will > still be whacked into compliance. At the same time, we let constrained > implementations decide whether they should add code to implement the > punishment. We also make sure that these implementations will not be > bothered by over-zealous protocol verifiers. > > My position is that RFC 9114 should have adopted the "MUST ignore, MAY > yell" pattern, and that mandating all implementations to police this > kind of thing is overreach worthy of an errata. I'll have to disagree here. This specific language was intentional it was introduced in response issue 3954 [1], which was about creating consistency with the language about handing reserved frame types in 7.2.8. That language transitioned from MAY error to MUST error via issue 3993. Disagreement with the consensus of the RFC is not suitable for erratum. This erratum is focused on settings when its clear there is the same thing happening for frames. Iff there is anything to change, then there's more work than indicated in the erratum. > > As for protocol purity, I don't think that flogging these 5 specific > code points will have a big effect on the purity of the ecosystem. > Deviants have almost 2^62 potential codes to experiment with, blocking 5 > of them is not likely to make a difference. The language in RFC 9114 is intended to protect things when HTTP deployments need to translate between HTTP/2 and HTTP/3. > > And as for picoquic, we just checked in a PR to fail the connection if > the settings include one of these five codes. Turns out that we already > had a switch statement listing the code points that should not be > expected, and returning an error for the 5 contentious values costed > just 8 lines of code... Given the triviality of checking these integers, as indicated, I really don't understand the earlier argument related to constrained implementations. There are _some_ kind of checks that could require storage of information to detect a protocol violation, which might be undesirable or unimplementatable. MAY can help there and we have some cases where RFC 9114 states such. Cheers, Lucas [1] - https://github.com/quicwg/base-drafts/issues/3954 [2] - https://github.com/quicwg/base-drafts/issues/3991 > > > On 6/10/2026 6:50 PM, Lucas Pardue wrote: > > Thanks for the added context. I asked Claude Opus 4.5 to survey open source > > implementations of HTTP/3. I have not verified the full results for all > > surveyed. Take with pinch of salt. But can speak authoritative for > > Cloudflare quiche as a maintainer. > > > > 7 implementations reject 5 reserved codepoints (0x0, 0x2-0x5) - Cloudflare > > quiche, aioquic, hyperium/h3, haproxy, haskell http3, eclipse jetty, > > cowlib/cowboy > > > > 9 implementations reject 4 reserved codepoints (0x2-0x5). They all fail to > > reject 0x0. HTTP/2 itself reserves 0x0 for no use, see IANA. nghttp3, > > lsquic, msquic (.net), neqo, Google quiche, netty, ocaml-quic, libhttp.zig, > > quiver > > > > 9 implementations ignore these reserved settings. quic-go, proxygen, > > picoquic, nginx, xquic, flupke/kwik, h2o/quicly, ATS, deno > > > > I'd summarise this as an inconsistent application of the intent of RFC > > 9114. However, I don't think the fault lies solely on the RFC 9114 > > shoulders nor implementations. IANA has a reserved value for HTTP/2's 0x0, > > which cites RFC 9113 but there doesnt seem to be anything there. RFC 7540 > > seems quiet on 0x0 too. RFC 9114 explicirly reserves 0x0, it also has a > > section discussing H2 settings - A.3 - 0x0 is not mentioned there. > > > > So we are in a bit of an awkward situation that likely warrants deeper > > thinking than a spot fix in just one RFC. > > > > Cheers > > Lucas > > > > On Thu, Jun 11, 2026, at 01:38, zhangph wrote: > >>> Thank you both for the detailed analysis. > >>> > >>> > >>> > >>> I'd like to present a concrete example of the ambiguity in practice. The > >>> maintainer of picoquic (a widely-deployed HTTP/3 implementation) > >>> encountered exactly this issue when reviewing a bug report about reserved > >>> setting identifiers: > >>> > >>> > >>> > >>> https://github.com/private-octopus/picoquic/issues/2126 > >>> > >>> > >>> > >>> In response to the report, the project maintainer wrote: > >>> > >>> > >>> > >>> "The spec also says that 'An implementation MUST ignore any parameter > >>> with an identifier it does not understand.' Picoquic does not understand > >>> these parameters, so it ignores them." > >>> > >>> > >>> > >>> "The requirement to break the connection is probably a bug in RFC 9114, > >>> that should be fixed in its next revision." > >>> > >>> > >>> > >>> In other words, an experienced implementer of this RFC read the general > >>> rule in Section 7.2.4 ("MUST ignore unknown") and concluded that it > >>> applies to reserved identifiers — and further concluded that the specific > >>> requirement in Section 7.2.4.1 is itself the error. This is precisely the > >>> ambiguity I am highlighting. > >>> > >>> > >>> > >>> I agree this erratum may not warrant a technical correction. But I > >>> believe this real-world evidence supports Hold for Document Update — the > >>> current wording has led at least one prominent implementer to a > >>> reasonable but incorrect reading of the document. > >>> > >
