/// Absolute upper bound on transient frame buffers — a backstop against a peer that advertises
/// an absurd frame size. Independent of `HttpConfig::h2_max_frame_size` (which we advertise and
/// enforce against incoming frames); this is just the ceiling on our own decode buffer to
/// prevent runaway allocation under an adversarial peer.
pub const MAX_BUFFER_SIZE: usize = 1 << 20;
/// Baseline connection-level flow-control window — 65535 octets for both directions,
/// unchanged by SETTINGS. Used as the starting value for our send-side window (credited
/// via peer `WINDOW_UPDATE(0)`) and for our recv-side window before we emit the initial
/// raising `WINDOW_UPDATE(0)` to `h2_initial_connection_window_size`.
pub const INITIAL_CONNECTION_RECV_WINDOW: i64 = 65_535;
/// Hard ceiling on the DATA payload we'll emit in a single frame even if the peer
/// advertises a larger `MAX_FRAME_SIZE`. Bounds `body_scratch` so a permissive peer can't
/// steer us into oversized allocations; the protocol only requires we not *exceed* the
/// peer's advertised max, which starts at the spec's 16 KiB default.
pub const MAX_DATA_CHUNK_SIZE: u32 = 16_384;
/// A flow-control window MUST NOT exceed `2^31 - 1`. If a `WINDOW_UPDATE` would push it
/// past that maximum, the peer has misbehaved — we emit `FLOW_CONTROL_ERROR` at the
/// appropriate level (connection or stream).
pub const MAX_FLOW_CONTROL_WINDOW: i64 = - 1;