Module conn 

A client connection: one HPACK context, a few streams, and flow control.

Flow control is the part that bites

An HTTP/2 receiver advertises how much it is willing to accept, and a sender that has used up that allowance simply stops. Both windows start at 65535 bytes — one for the connection, one for each stream — and neither grows unless the receiver says so with WINDOW_UPDATE.

For a client that fetches small responses this never comes up, which is exactly why it is dangerous: the netmap long-poll streams megabytes, and a client that never sends WINDOW_UPDATE receives precisely 65535 bytes and then hangs forever. It looks like the server stopped talking. It did, because we told it to.

So this connection raises the connection window immediately after the preface, advertises a large per-stream window in its SETTINGS, and returns a WINDOW_UPDATE for every byte of DATA it consumes.

Sans-io

The caller reads frame::HEADER_LEN bytes, learns the payload length, reads that, and hands the whole frame to Connection::recv. Anything that must be sent in reply is written to the caller’s buffer.

Structs

Connection

Enums

Event

What arrived.

Constants

MAX_HEADER_BLOCK

The largest header block this client will reassemble across CONTINUATION frames.

MAX_STREAMS

How many requests may be in flight at once. Registration and the map long-poll, with one spare.

RECEIVE_WINDOW

What we advertise as our per-stream receive window, and what we top the connection window up to.