HTTP/2
When the browser and STATIC negotiate h2 via client-facing TLS ALPN, STATIC runs an HTTP/2 server. It accepts concurrent streams and creates a separate Flow for each request. The origin connection is made independently through wreq; the origin may use HTTP/2 or HTTP/1.1 regardless of the browser-to-STATIC protocol.
Client streams and origin requests
The client-facing h2 server has its own concurrency and flow-control settings in the connection handler. It collects each request’s headers and bounded body, runs request stages, then picks an upstream attempt from the active profile. The profile can describe an outbound HTTP/2 plan: SETTINGS ordering and values, pseudo-header ordering, stream dependency, window and frame sizing, and related supported options.
STATIC adapts that plan to wreq::Http2Options. This describes the upstream client it controls, not the browser’s original HTTP/2 connection. Some profile values may be constrained by the transport backend. A configured HTTP/2 profile is not evidence of exact native-browser frame parity.
Buffer only when needed
For client-facing HTTP/2, the response path checks whether a document is HTML/XHTML or the request is a script/bootstrap asset:
| Response path | Body treatment | Purpose |
|---|---|---|
| HTML or bootstrap asset | Buffer within size limits, run response-body stages, then send. | Permit HTML insertion and cache-sensitive asset handling. |
| Other response | Run header stages, then stream the origin body to the client. | Avoid buffering a body that the normal stages need not modify. |
An HTML/XHTML content type can trigger buffering even when later injection does not happen; injection itself requires successful text/html, valid UTF-8, a supported content encoding, a nonempty body, and no existing bootstrap marker. Response headers are sanitized for HTTP/2 before sending. A body that exceeds the configured limit can fail rather than be quietly passed through.
Retry and special streams
For an HTTP/2 client stream, STATIC can try several h2-compatible TLS hello variants, an HTTP/1.1 variant, and a wreq fallback when eligible upstream connection attempts fail. The actual negotiated upstream protocol is recorded in Flow metadata. Extended CONNECT/WebSocket requests have a separate tunnel path and do not follow the ordinary HTML-response pipeline.
Alt-Svc handling reduces unexpected alternative transports; the config has an HTTP/3 placeholder, but this path is implemented around HTTP/1.1 and HTTP/2. See connection routing, HTTP/2 adapter, and TLS/HTTP/2 profile types.