Read HTTP messages without guessing

Read the meaning before the serialization

An HTTP message carries control data, a field section, and optional content. A request’s control data identifies a method and target. A response’s control data identifies a status. The field section adds metadata that must be interpreted according to each field’s definition.

HTTP/1.1 writes control data and fields as text lines. HTTP/2 and HTTP/3 encode equivalent semantics in binary frames and pseudo-fields. A developer tool may present all three versions in a convenient HTTP/1.1-like view; that view is not a byte-for-byte capture of an HTTP/2 or HTTP/3 connection.

POST /notes HTTP/1.1
Host: example.invalid
Content-Type: text/plain
Content-Length: 5

hello

Expected result: the method and target are request control data, Content-Type and Content-Length describe the message content, and hello is the content. The blank line is part of HTTP/1.1 framing, not a universal HTTP semantic.

Fields need their own definitions

A field name alone does not tell you whether it is valid in requests, responses, or both, whether intermediaries can change it, or whether multiple values can be combined. Look up the field’s specification before applying a general rule.

Representation metadata such as a media type describes a selected representation. Message framing metadata describes this transfer. Those ideas can overlap in a simple response, but they are not interchangeable.

Content can be absent for different reasons

A message can lack content because the method or status defines that result, the selected representation is empty, or the framing indicates a zero-length message. Do not infer one cause merely from an empty panel in a tool. Start with the method, status, and applicable field definitions.