Anatomy of a request

An HTTP/1.1 request is plain text on the wire. Tools like curl -v let you read it directly.

Here is a complete POST with a JSON body:

POST /notes HTTP/1.1
Host: api.example.com
Content-Type: application/json
Content-Length: 24

{"title":"Learn HTTP"}

The request line comes first: method, request target, protocol version. In this case POST /notes HTTP/1.1.

Headers follow as Name: value lines. They carry context the server needs: which host you meant (Host), how the body is encoded (Content-Type), how many bytes the body contains (Content-Length).

An empty line marks the end of the headers. Everything after it is the body. Bodies are optional. GET and HEAD normally send none. POST, PUT, and PATCH usually send one.

Send the same shape from your terminal:

curl -v https://httpbin.org/post \
  -H 'Content-Type: application/json' \
  -d '{"title":"Learn HTTP"}'

In the verbose output, look for the outgoing request. You will see POST /post HTTP/1.1, your headers, the blank line, then the JSON. httpbin echoes the request back in the response body so you can verify what arrived.

HTTP/2 and HTTP/3 compress and frame messages differently on the wire. You will not always see this exact text layout in a packet capture. The concepts stay the same: method, target, headers, optional body.

Be careful with line endings. HTTP/1.1 expects \r\n between lines. Most tools handle that for you. Hand-rolling requests in a raw socket is where people get bitten.

Try this on your own project: log the raw incoming request in your dev server once, or capture one with curl -v against your API. Label the request line, each header, and the body in a comment so you can recognize the parts quickly next time.