Repository navigation
Conversation
The two wrong-stream rules required a connection error without naming a type, and the client-sent rule said only to close the connection. All three now name a type, as RFC 9113 Sections 6.5 and 8.4 and RFC 9114 Sections 7.2.3 and 7.2.5 do for their own frames. No new codepoints are used. Raised by Mark Nottingham in https://lists.w3.org/Archives/Public/ietf-http-wg/2026JulSep/0194.html.
A server can send a certificate for any origin, so a bad authenticator for an origin the client never asked for closed the connection, failing all of its requests. A client now discards an authenticator it cannot validate. Section 6 is renamed Handling Certificate Failures. It states once that neither case is a stream or connection error, and keeps the SHOULD for unacceptable certificates. Raised by Mark Nottingham in https://lists.w3.org/Archives/Public/ietf-http-wg/2026JulSep/0194.html and Martin Thomson in https://lists.w3.org/Archives/Public/ietf-http-wg/2026JulSep/0292.html.
A failed validation is no longer an error, so nothing uses the error code. Its definition went with the connection error. This removes its HTTP/2 and HTTP/3 registrations and its mention in the IANA Considerations introduction. Raised by Mark Nottingham in https://lists.w3.org/Archives/Public/ietf-http-wg/2026JulSep/0194.html.
The document had no denial-of-service text, and the connection error removed for failed validations was its only related measure. The new section points to the HTTP/2 and HTTP/3 considerations and lets a client close the connection with ENHANCE_YOUR_CALM or H3_EXCESSIVE_LOAD when it receives more frames than it will process. Raised by Mark Nottingham in https://lists.w3.org/Archives/Public/ietf-http-wg/2026JulSep/0194.html and Martin Thomson in https://lists.w3.org/Archives/Public/ietf-http-wg/2026JulSep/0292.html.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
It was noted in reviews for WGLC that there were a number of cases in the existing text which indicated certs that came in but could not be validated would be connection errors, but this blast radius is probably too large given the initial connection should still be valid.
This change removes the dedicated error for certs being invalid and changes the model a little bit about what clients should do when getting bad certs. Existing errors can be used if the client decides that a bad secondary cert is worth closing the connection over, but it's no longer a requirement and not given an error code to encourage such behavior.
We're also encouraging usage of ENHANCE_YOUR_CALM and friends here for denial of service concerns.