Practice: Reading a Raw HTTP Exchange

A request and its response as bytes; name each part and say which version and connection behaviour it shows.

Reading a raw exchange is how HTTP problems are confirmed, from a proxy log or curl -v. A client fetches an order from an API, and the exchange below is captured. It is illustrative.

Captured exchangetext

GET /orders/42 HTTP/1.1
Host: api.example.com
Accept: application/json
Connection: keep-alive

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 28
Keep-Alive: timeout=5

{"id":42,"status":"shipped"}

An illustrative request and response, as they travelled.

Answer four questions:

Name the request's start line parts, and the response's.
Where do the response headers end, and how does the client know where the body ends?
Which HTTP version is this, and how can you tell from the bytes alone?
What happens to the TCP connection after this response, and does that make the server remember the client for the next request?

Show the answers

Request: method GET, target /orders/42, version HTTP/1.1. Response: version HTTP/1.1, status code 200, reason OK.
At the empty line after Keep-Alive. The body is exactly Content-Length: 28 bytes, the 28 characters of the JSON.
HTTP/1.1. The start lines say so, and the message is readable text with headers on separate lines. HTTP/2 and HTTP/3 send binary frames, which a capture shows as streams, not lines.
It stays open for further requests, up to five idle seconds by the Keep-Alive header. That is connection reuse, not memory: the next request must still identify the client itself, because HTTP is stateless.

← → move through sections and cards