HTTP Requests and Responses

Why it matters

The screen shows only what the front end chose to show: "Saved" can appear although the server rejected the data. The request and the response record what really passed between client and server, so they show whether a defect is in the client, the server or both, and who must fix it.

The request: method, target, headers, body

In HTTP/1.1 (RFC 9112) a request has a fixed layout: a request line, one header field per line, an empty line, then an optional body. The request line and every header line end with a carriage return and a line feed (CRLF).

• Method: the first word names the action, such as GET to read or POST to submit data. The next lesson covers each method.
• Request target: usually the path plus an optional query string, here /api/v1/tickets?lang=ar; the host name goes separately, in the Host header.
• Protocol version: HTTP/1.1 closes the request line.
• Header fields: Name: value lines such as Host (the host the request is for), Content-Type and Content-Length (the body's format and size), Accept and Authorization. An HTTP/1.1 request must carry exactly one Host header, or the server must answer 400 Bad Request.
• Body: everything after the empty line, present only when there is data to send.

POST /api/v1/tickets?lang=ar HTTP/1.1
Host: support.example.com
Content-Type: application/json
Accept: application/json
Authorization: Bearer eyJhbGciOi...
Content-Length: 45

{"subject": "Late delivery", "orderId": 9021}

Try it: API Request Builder

The response: status line, headers, body

The server answers with the same layout; only the first line differs. The status line holds the protocol version, a three-digit status code and a reason phrase.

• Status code: the outcome as a number. Clients act on it, so it is what you assert on. The first digit gives the class: 1xx informational, 2xx success, 3xx redirection, 4xx a problem with the request, 5xx an error on the server.
• Reason phrase: text for humans, such as Created. RFC 9112 tells clients to ignore it, servers may word it differently, and HTTP/2 does not carry it, so never assert on it.
• Header fields: facts about the response, such as the body's format and size, the Location of a new resource, Set-Cookie and Cache-Control.
• Body: the requested data, a description of an error, or nothing.

Part 1:1POST Part 2:2/api/v1/tickets?lang=ar Part 3:3HTTP/1.1
Part 6:6Host: support.example.com
Content-Type: application/json
Accept: application/json
Authorization: Bearer eyJhbGciOi...
Content-Length: 45
Part 7:7
Part 8:8{"subject": "Late delivery", "orderId": 9021}

Part 3:3HTTP/1.1 Part 4:4201 Part 5:5Created
Part 6:6Date: Thu, 01 Oct 2026 09:30:00 GMT
Content-Type: application/json
Content-Length: 62
Location: /api/v1/tickets/T-1047
Part 7:7
Part 8:8{"id": "T-1047", "status": "open", "subject": "Late delivery"}

HTTP/1.1 201 Created
Date: Thu, 01 Oct 2026 09:30:00 GMT
Content-Type: application/json
Content-Length: 62
Location: /api/v1/tickets/T-1047

{"id": "T-1047", "status": "open", "subject": "Late delivery"}

Try it: HTTP Status Code Lookup

Request bodies and response bodies

RFC 9110 calls the body the content; tools say body or payload. Content-Type names its format as a media type, such as application/json for JSON, the text format many APIs use, with names and values inside braces. Content-Length gives its size in bytes, unless an HTTP/1.1 sender uses Transfer-Encoding: chunked and sends the body in pieces.

• Request bodies carry the data you create or change, so POST, PUT and PATCH requests usually have one. GET, HEAD and DELETE requests usually do not: RFC 9110 gives content in them no generally defined meaning.
• Response bodies carry what you asked for, such as JSON, HTML or a file, or a description of an error; RFC 9457 defines a standard error format, application/problem+json (sample below).
• Some responses never have a body: any response to HEAD, and every 1xx, 204 No Content and 304 Not Modified response.
• Content-Length counts bytes, not characters. In UTF-8, the usual encoding that turns web text into bytes, each English letter, digit and punctuation mark takes one byte, each Arabic letter two and each Devanagari character three: {"name": "سارة"} is 16 characters but 20 bytes.

HTTP/1.1 422 Unprocessable Content
Content-Type: application/problem+json
Content-Length: 132

{"type": "https://example.com/probs/missing-field", "title": "Missing field",
 "status": 422, "detail": "subject must not be empty"}

Try it: Content-Type Validator Try it: String Length Counter

Reading raw HTTP

Raw HTTP is the message as text, as in the samples above. In DevTools, the Network panel's Headers tab has a Raw toggle, and the request body is under Payload in Chrome or Request in Firefox. curl -v prefixes the start line and header lines it sent with > and those it received with <. Read in a fixed order:

• Start line: are the method and target the ones the test intended? In a response, take the status code, not the reason phrase.
• Headers: names are case-insensitive and the order of different fields carries no meaning, so compare names and values only.
• The empty line: before it, facts about the message; after it, the body.
• Cross-checks: the status code against the body, Content-Type against the body's real format, Content-Length against its bytes. Each part can look right alone while the combination is wrong.

Try it: HTTP Headers Parser Try it: HTTP Request Inspector

Worked example: "Saved", but the address is missing

A shopping app says "Saved" after a tester adds a delivery address, but the address list stays empty. The API documentation says the body needs city and postalCode, success returns 201 Created, and a validation error returns 422 with a problem details body. The tester repeats the step with DevTools open and copies the exchange.

• Request line and headers: as documented; Content-Type matches the JSON body and Content-Length: 42 equals its 42 bytes.
• Request body: postal_code instead of postalCode. Defect 1, in the app.
• Status line: 200 OK for a save that failed; the app trusted the 2xx and showed "Saved". Defect 2, in the API: expected 422.
• Response headers: Content-Type: text/plain for a JSON body. Defect 3, in the API: a client that follows the header may not parse the error.
• Response body: it names the missing field, which pointed to defect 1. Three defects, two owners, one exchange.

POST /api/v1/customers/58/addresses HTTP/1.1
Host: api.example.com
Content-Type: application/json
Accept: application/json
Authorization: Bearer eyJhbGciOi...
Content-Length: 42

{"city": "Riyadh", "postal_code": "12271"}

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 53

{"success": false, "error": "postalCode is required"}

Frequently asked questions

References

• RFC 9110: HTTP SemanticsIETF · 2022The meaning of HTTP methods, header fields, status codes and content negotiation, independent of the wire version.
• RFC 9112: HTTP/1.1IETF · 2022The HTTP/1.1 message syntax: request line, header fields, chunked transfer and connection handling.
• RFC 9457: Problem Details for HTTP APIsIETF · 2023The application/problem+json error format (type, title, status, detail, instance) for machine-readable API errors.
• Overview of HTTP — MDNMDN Web Docs (Mozilla)How HTTP works: a stateless client–server protocol in which the client sends a request and the server answers with a response message.