fix(relay): make h2 client startup settings explicit#1381
Open
maybeknott wants to merge 1 commit into
Open
Conversation
The Apps Script relay h2 fast path already depends on explicit client-side flow-control tuning, but those values were embedded directly in the handshake path and only covered stream and connection windows. That made the startup profile harder to audit and left max-frame and local stream-concurrency behavior implicit in the h2 crate defaults. Define a named h2 client profile for the relay connection and route h2 handshakes through a single builder helper. The profile advertises a 6 MiB initial stream window, a 15 MiB initial connection window, a 16 KiB maximum frame size, and a 1000-stream local concurrency setting. These values keep the client startup SETTINGS stable across refactors and reduce small-window churn while Apps Script envelopes are drained over the h2 connection. This does not add a new transport backend, alter ALPN policy, change retry behavior, or claim byte-for-byte browser fingerprint parity. The existing fallback model remains intact: peers that refuse h2, stalled h2 connections, and fronting-incompatibility responses still fall back to the warmed HTTP/1.1 pool. Add focused unit coverage for the h2 profile constants and document the current h2 behavior in the English and Persian guides. The documentation now describes h2 as an active fast path with explicit flow-control tuning rather than an unimplemented roadmap item.
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.
The relay already has an HTTP/2 fast path with fallback to the warmed HTTP/1.1 pool. This change makes the client-side h2 startup profile explicit instead of relying on scattered builder defaults.
The h2 client builder now uses named constants for initial stream window, initial connection window, max frame size, and advertised concurrent stream capacity. The values are browser-scale and tuned for Apps Script relay envelopes: large enough to avoid excessive WINDOW_UPDATE churn on normal response bodies, while keeping startup SETTINGS stable across future refactors.
This does not claim byte-for-byte browser fingerprint parity. TLS record packing, ALPN outcome, peer settings, and connection behavior still affect the final wire shape. The practical goal is narrower: remove anomalous small h2 defaults from the relay fast path and keep fallback behavior unchanged when h2 is refused, stalls, or is disabled through
force_http1.The guide text now reflects that HTTP/2 multiplexing is implemented as an opportunistic fast path with fallback, rather than listing it as intentionally absent.
Validation:
git diff --checkcargo test h2_client_profile --libcargo test h2_handshake_post_tls --lib