flare.http2.server

Default-construct with :class:Http2Config defaults.

Equivalent to Http2Connection.with_config(Http2Config()); kept as a separate __init__ so callers (Http2Connection() in tests + the inline driver) work byte-for-byte without an explicit config argument.

Construct an :class:Http2Connection whose underlying :class:Connection SETTINGS are populated from config.

Validates config first (RFC 9113 / RFC 7541 bounds); raises if any field is out of range. The resulting driver's first-emitted SETTINGS frame advertises max_concurrent_streams per the config; later inbound SETTINGS from the peer can lower the negotiated values per RFC 9113 §6.5.

The HPACK dynamic-table size budget is propagated to the decoder. The allow_huffman_decode flag is plumbed into conn.hpack_decoder.allow_huffman; the allow_huffman_encode flag into conn.hpack_encoder.allow_huffman. Both default to False so the wire format stays byte-identical to the legacy default unless the user opts in.

Build a server-side :class:Http2Connection seeded for an h2c upgrade.

Per RFC 7540 §3.2 ("Starting HTTP/2 for HTTP URIs"), the original HTTP/1.1 request becomes stream id 1 (implicitly half-closed from the client side), and the HTTP2-Settings header value (the raw SETTINGS payload, base64url-decoded) is applied to the connection immediately. The server emits its initial SETTINGS frame as the server connection preface; the client's connection preface (PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n + a SETTINGS frame) still arrives over the same TCP fd and is processed by :meth:feed as usual.

Push data (bytes from the socket) into the driver.

Return all queued outbound bytes and clear the buffer.

The buffer is handed over rather than copied: it holds whatever was framed since the last drain, which for a streaming response is a window's worth of body.

Return stream ids whose request is fully buffered.

A stream already dispatched is excluded by Stream.slab_ready: emit_response moves a fully written one to CLOSED, and response_started covers a response parked in pending_body whose stream stays open until the window drains, so a WINDOW_UPDATE never re-runs the handler (RFC 9113 sec 8.1).

Pop the list of stream ids reset by the peer since the last call.

Each id corresponds to an inbound RST_STREAM frame (RFC 9113 §6.4) processed by :class:Connection.handle_frame. Used by :class:flare.http._h2_conn_handle.Http2ConnHandle to flip the matching per-stream :class:CancelCell so the in-flight handler can short-circuit cooperatively. The list is drained -- a second call returns an empty list unless a new RST_STREAM has arrived in the meantime.

Return True once the peer has sent a GOAWAY frame (RFC 9113 §6.8). The reactor checks this between dispatches to flip the per-stream cancel cells before draining the connection.

Convert stream sid into a :class:flare.http.Request.

Encode + queue the response for sid.

The connection's stream state is advanced to CLOSED after the response is queued, mirroring HTTP/1.1's per-request lifetime in the server. When resp.trailers is non-empty the response is framed as HEADERS [+ DATA] + trailing HEADERS with END_STREAM on the trailing block (the gRPC-over-HTTP/2 shape); otherwise it frames as a single buffered response.

There are still no streaming-response bodies on h2 here (one buffered DATA frame per stream). Chunked/flow-controlled h2 response bodies come with the streaming reactor wiring.

Flush response bytes parked by a closed send window.

Called after every inbound frame: a WINDOW_UPDATE is what unblocks them, and nothing else re-drives the stream.

Return stream ids of open Extended CONNECT tunnels awaiting acceptance: :method=CONNECT + :protocol=websocket, headers complete, not yet END_STREAM'd, still OPEN (RFC 8441). The :protocol marker is cleared by :meth:accept_ws_over_h2, so an accepted tunnel is not re-returned.

Accept a WebSocket Extended CONNECT tunnel on sid: emit a :status=200 HEADERS block WITHOUT END_STREAM (RFC 8441 5.2) so the stream stays open for bidirectional WS DATA. Clears the :protocol marker so the tunnel is not re-surfaced.

True while sid exists and is still OPEN (bidirectional).

The WS-over-h2 reactor path uses this to detect peer teardown (RST_STREAM / END_STREAM moves the stream off OPEN) so it can run the sidecar handler's on_close and drop the tunnel.

Move any inbound DATA accumulated for sid out of the stream record (the WS-over-h2 read path pulls client frames from here).

Queue the leading HEADERS of an incremental streaming response.

Filters hop-by-hop fields (RFC 9113 8.2.2) and encodes a no-END_STREAM HEADERS block into the outbox. The stream is left open; :meth:queue_stream_data sends the body and :meth:end_stream_response closes it (trailers captured by the caller from resp.trailers before this move).

Frame as much of body[pos:] as the send windows will take.

The point of it is what it does not copy. A body too large for the window is parked and re-pumped on every WINDOW_UPDATE, so handing the whole remainder over each time and letting queue_stream_data use a window's worth of it is quadratic in the body: at a 64 KiB window a 28 MiB response copies about 6 GB to send 28 MB. Asking the window first makes each pump cost a window, not a body.

Returns the bytes consumed, which the caller adds to its own offset. Both pump paths — a buffered response here and a streaming one in Http2ConnHandle — go through this rather than repeating it.

Frame as much of data as the send windows allow.

Emits DATA frames (each <= max_frame_size) bounded by the min of the connection and per-stream send windows, decrements both, and returns the number of bytes consumed. Returns 0 when the window is exhausted -- the caller stashes the remainder and re-pumps on the next WINDOW_UPDATE.

Close a streaming response.

Emits trailing HEADERS with END_STREAM when trailers are present, otherwise an empty DATA frame with END_STREAM, and advances the stream to CLOSED.