WEBMACHA

WebMacha HTTP/2

The client uploads 40 KB. A body follows its HEADERS frame, so that frame has no END_STREAM, and the stream is open. Three DATA frames carry the body, each at most 16 KB, the default largest frame (RFC 9113 §6.5.2). END_STREAM on the last one half-closes the stream from the client's side (RFC 9113 §5.1). Once 32 KB has landed, more than half of each window, the server gives that credit back with a WINDOW_UPDATE on the stream and one on the connection (RFC 9113 §6.9). The server decides only when the last frame lands, because creating something needs the whole body. The answer is 201 Created, with a short generated body.

The pipe

client windows
server windows

Step 0 of 23

Streams at this step
s0 connection SET 1 frames
s1 upload not open yet
Reset
Step 0 · SETTINGS · stream 0 · leaves client → server

The client sends its SETTINGS

Before any frame, the client sends the 24-octet connection preface, PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n. RFC 9113 §3.4 chose it so that a large proportion of HTTP/1.x servers and intermediaries do not process further frames. It is not a frame, so it is not drawn. Then SETTINGS states what the client will accept: frames of up to 16 384 bytes (MAX_FRAME_SIZE), 65 535 bytes per stream before the server must wait for more window (INITIAL_WINDOW_SIZE). It also turns server push off (ENABLE_PUSH 0); the hub does not model it anyway.

moment
leaves the client
sent at
0 ms
received at
21 ms
length
18 bytes
flags
none

Settings

SETTINGS_ENABLE_PUSH
0
SETTINGS_INITIAL_WINDOW_SIZE
65 535
SETTINGS_MAX_FRAME_SIZE
16 384

RFC 9113 §3.4 · RFC 9113 §6.5.2

Lifecycle

RFC 9113 §5.1
from the client's side send HEADERS send HEADERS + ES send ES recv ES RST_STREAM recv ES · RST send ES · RST idle open half-closed (local) half-closed (remote) closed

ES is END_STREAM. Select a state to read about it. RFC 9113 §5.1 also has two reserved states for server push; they are left out because push is not modelled.

Step 0 of 23: The client sends its SETTINGS