fix: pin HTTP/1.1 defaults; enforce RFC 9530 body digest in resource role - #3
Merged
Conversation
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
1 participant
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.
Two fixes driven by downstream use against the AAuth Person Server (uvicorn/h11):
HTTP/1.1 pinned in library-constructed clients. The JDK HttpClient's default h2c upgrade makes h11-based servers reject requests (400 "Invalid HTTP request received") or silently drop POST bodies. Both library defaults —
DefaultHttpClient(JWKS/metadata fetching viaCachingJwksFetcherandMetadata.fetch*) andTokenExchange.Exchange— now setHttpClient.Version.HTTP_1_1. Caller-injected clients are untouched. Javadoc on each affected entry point states the default and why;Http11DefaultTestasserts the versions.RFC 9530 body-digest enforcement in the resource role. The signature base covers the
Content-Digestheader, not the body, so a tampered body with an intact header passed verification (this library and the Python reference behave identically at the signing layer).RequestVerifier.verifyRequestnow recomputes the digest whenever both header and body are present and fails withcontent-digest mismatchon divergence. The low-levelSignatureVerifieris unchanged for wire-format parity with Python; the intentional divergence is documented in docs/PROGRESS.md and the README. Tests cover tampered-body rejection, matching-body pass, and the unchanged body-less / no-header paths.196 tests green, coverage gates met.
🤖 Generated with Claude Code