fix: honor -pr http11 by disabling retryablehttp HTTP/2 fallback #2399
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.
Proposed changes
Closes #2240
When a user passes
-pr http11, httpx correctly configures the primary transport to disable HTTP/2 (TLSNextProto = {},GODEBUG=http2client=0). However, retryablehttp-go maintains a secondaryHTTPClient2that is always configured with native HTTP/2 support. When the primary HTTP/1.1 request encounters certain protocol-mismatch errors (e.g.malformed HTTP version "HTTP/2"), retryablehttp silently retries the request usingHTTPClient2, which speaks HTTP/2 -- completely bypassing the user's explicit protocol selection.Fix: After constructing the retryablehttp client, when
Protocol == HTTP11, setHTTPClient2 = HTTPClient. This makes the fallback path use the same HTTP/1.1-only client, so retryablehttp can never silently upgrade the protocol.Before:
-pr http11is ignored on servers that trigger retryablehttp's HTTP/2 fallback path (do.go:62-66). The request silently completes over HTTP/2 with a different transport that does not share the primary client's proxy, dialer, redirect, or TLS configuration.After:
-pr http11is strictly honored. The fallback client is the same object as the primary client, so all protocol-mismatch retries still use HTTP/1.1 with the user's configured transport settings.Proof
Full suite:
Checklist
Summary by CodeRabbit
Bug Fixes
Tests