HTTP Response

An HTTP response is the message a server sends back to a client after receiving a Request. The response carries the outcome of the requested action: a status code indicating success or failure, Headers with metadata about the response and the resource, and an optional body containing the resource data.

Usage

Every HTTP Request produces one or more responses. The server processes the request, determines the outcome, and returns a response through the same connection. Most requests produce a single final response. Some exchanges include one or more informational (1xx) responses before the final response arrives.

Responses deliver HTML pages, JSON data, images, files, redirect instructions, error messages, and every other type of content on the web. The status code tells the client what happened. The Headers tell the client how to handle the content. The body carries the content itself.

Response structure

An HTTP response message has three parts:

Status line: the HTTP version, status code, and an optional reason phrase
HTTP Headers: zero or more name-value pairs carrying metadata
Body: optional content containing the resource data or error details

A blank line (CRLF) separates the headers from the body. In HTTP/1.1, the status line and headers are plain text. In HTTP/2 and HTTP/3, the same information is encoded as binary frames.

Status line

The status line contains three elements:

HTTP/1.1 200 OK

HTTP version (HTTP/1.1): the message syntax version
Status code (200): a three-digit number indicating the outcome
Reason phrase (OK): a human-readable label with no protocol significance

The reason phrase exists for compatibility with older text-based clients. HTTP/2 and HTTP/3 omit the reason phrase entirely, transmitting only the numeric status code in the :status pseudo-header field.

Status code classes

The first digit of the status code defines the response class:

Class	Range	Meaning
1xx	100-199	Informational, processing continues
2xx	200-299	Success, request accepted
3xx	300-399	Redirection, further action needed
4xx	400-499	Client error, problem with the request
5xx	500-599	Server error, server failed to fulfill

When a client receives an unrecognized status code, the code is treated as the class default (the x00 code). A 499 is handled as a 400 Bad Request. A 599 is handled as a 500 Internal Server Error.

Informational responses

Informational (1xx) responses are interim messages sent before the final response. The server indicates the request was received and processing continues.

100 Continue

The 100 Continue flow prevents sending large request bodies to servers likely to reject them. The client sends headers with Expect: 100-continue and pauses. The server evaluates the headers and either sends 100 Continue (proceed with the body) or a final error response (stop).

Request headers

POST /upload HTTP/1.1
Host: www.example.re
Content-Type: application/pdf
Content-Length: 52428800
Expect: 100-continue

Server confirms

HTTP/1.1 100 Continue

Client sends body

Final response

HTTP/1.1 201 Created
Location: /documents/report.pdf

103 Early Hints

The 103 Early Hints response sends preliminary headers (typically Link headers with rel=preload) while the server is still generating the final response. The client starts preloading resources without waiting for the full response.

HTTP/1.1 103 Early Hints
Link: </style.css>; rel=preload; as=style
Link: </app.js>; rel=preload; as=script

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Link: </style.css>; rel=preload; as=style

<!doctype html>...

Response headers

HTTP Headers in the response carry metadata about the server, the resource, Caching instructions, security policies, and more.

Representation metadata

These headers describe the content in the body:

Content-Type: text/html; charset=utf-8
Content-Length: 4820
Content-Encoding: br
Content-Language: en

Content-Type declares the media type and character encoding. Content-Length gives the body size in bytes. Content-Encoding identifies the Compression applied (gzip, br, zstd). Content-Language identifies the natural language of the content.

Caching headers

Cache-Control: max-age=3600, public
ETag: "v42"
Last-Modified: Mon, 03 Mar 2026 10:00:00 GMT
Age: 120
Vary: Accept-Encoding

Cache-Control defines Caching rules: how long the response stays fresh, whether shared caches store the response, and when validation is required. ETag and Last-Modified provide validators for conditional requests. Age reports how long the response has been in a cache. Vary lists Request headers influencing the response, ensuring caches store separate entries for different variants.

Redirect headers

HTTP/1.1 301 Moved Permanently
Location: https://www.example.re/new-path

The Location header provides the target URL for Redirects. The status code determines the redirect type: 301 for permanent, 302 for temporary, 307 for temporary with method preservation, 308 for permanent with method preservation.

Security headers

Strict-Transport-Security: max-age=31536000
Content-Security-Policy: default-src 'self'
X-Content-Type-Options: nosniff
X-Frame-Options: DENY

Strict-Transport-Security enforces HTTPS. Content-Security-Policy restricts which resources the page loads. X-Content-Type-Options prevents MIME type sniffing. X-Frame-Options blocks embedding in frames to prevent clickjacking.

Set-Cookie: session=xyz789; Path=/; HttpOnly; Secure; SameSite=Lax

The Set-Cookie header stores a cookie on the client. The client sends the cookie back on subsequent requests in the Cookie header.

Server identification

Server: nginx/1.25
Date: Mon, 03 Mar 2026 12:00:00 GMT

The Server header identifies the server software. The Date header indicates when the response was generated.

CORS headers

Access-Control-Allow-Origin: https://www.example.re
Access-Control-Allow-Methods: GET, POST, DELETE
Access-Control-Max-Age: 86400

CORS headers tell the browser whether a cross-origin Request is permitted. Access-Control-Allow-Origin specifies which origins have access.

Response body

The body carries the content: an HTML page, a JSON object, an image, a file download, or an error message. The body format is declared by the Content-Type header.

Responses without a body

Some responses have no body:

204 No Content: the server processed the Request successfully but returns no content
304 Not Modified: the resource has not changed since the client's cached version
1xx informational responses: the body is deferred until the final response
Responses to HEAD requests: the server returns headers only, with no body

Body framing

In HTTP/1.1, the body length is determined by:

Content-Length: an explicit byte count
Transfer-Encoding: chunked: the body is split into sized chunks, terminated by a zero-length chunk
Connection close: the body ends when the connection closes (last resort, prevents connection reuse)

HTTP/2 and HTTP/3 frame the body as DATA frames with explicit length, eliminating the need for chunked encoding.

Trailer fields

Trailer fields are Headers sent after the body. They carry metadata generated during content transmission, such as checksums, digital signatures, or post-processing status.

In HTTP/1.1, trailers are delivered through chunked transfer encoding:

HTTP/1.1 200 OK
Transfer-Encoding: chunked
Trailer: Content-Digest

1a
{"result": "success"}
0
Content-Digest: sha-256=:abc123=:

The Trailer header announces which fields appear after the body. The zero-length chunk signals the end of the body, followed by the trailer fields.

In HTTP/2 and HTTP/3, trailers are sent as a trailing HEADERS frame after the DATA frames.

Not all headers are permitted as trailers. Headers involved in routing (Host), Authentication (Authorization), content negotiation (Accept), or caching (Cache-Control) are prohibited in trailers because they need to be available before the body is processed.

Responses across HTTP versions

HTTP/1.1

HTTP/1.1 sends responses as plain text. The status line, headers, and blank line are ASCII characters terminated by CRLF.

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 27

{"status": "operational"}

Persistent connections are the default. The connection remains open for additional request-response exchanges. The Connection: close header signals the server is closing the connection after this response.

HTTP/2

HTTP/2 encodes the same information as binary frames. There is no text-based status line. The :status pseudo-header carries the numeric status code. HPACK Compression reduces header overhead across responses on the same connection.

Multiple responses flow concurrently over a single TCP connection through multiplexed streams. A slow response on one stream does not block other streams at the HTTP layer, though TCP-level head-of-line blocking remains.

HTTP/3

HTTP/3 uses the same :status pseudo-header as HTTP/2 but runs over QUIC. QPACK replaces HPACK for header compression. Each response occupies its own QUIC stream, eliminating head-of-line blocking entirely. A lost packet on one stream does not stall other streams.

Common response patterns

HTML page

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Encoding: br
Content-Length: 4820
Cache-Control: max-age=300
ETag: "page-v7"
Vary: Accept-Encoding

<!doctype html>...

JSON API

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 256
Cache-Control: no-cache
Vary: Accept, Authorization

{"data": [...]}

Resource created

HTTP/1.1 201 Created
Location: /api/users/42
Content-Type: application/json
Content-Length: 85

{"id": 42, "name": "Jane Doe"}

The 201 status confirms the resource was created. The Location header provides the URL of the new resource.

Permanent redirect

HTTP/1.1 301 Moved Permanently
Location: https://www.example.re/new-path
Content-Length: 0

Not modified

HTTP/1.1 304 Not Modified
ETag: "css-v42"
Cache-Control: max-age=3600

No body. The client reuses the cached version.

Error response

HTTP/1.1 404 Not Found
Content-Type: text/html; charset=utf-8
Content-Length: 1024

<!doctype html>
<html>
<body>
<h1>Page not found</h1>
</body>
</html>

Error responses carry an optional body with details about the error. API endpoints often return structured error objects:

HTTP/1.1 422 Unprocessable Content
Content-Type: application/json
Content-Length: 89

{"error": "validation_failed", "fields": {"email": "invalid format"}}

Server error

HTTP/1.1 503 Service Unavailable
Retry-After: 30
Content-Length: 0

The Retry-After header tells the client how long to wait before retrying. The value 30 means 30 seconds.

SEO impact

Googlebot processes HTTP responses following the same protocol rules as browsers. The status code determines crawl and indexing behavior: 200 passes content to the indexing pipeline, 301 transfers ranking signals to the new URL, and 5xx errors cause Googlebot to reduce crawl rate. Persistent 5xx responses lead to eventual deindexing.

Takeaway

An HTTP response is the server's answer to a client Request. The status code communicates the outcome (success, redirection, client error, or server error). HTTP Headers carry caching instructions, security policies, Cookies, and representation metadata. The body delivers the content. From HTTP/1.1's text-based status line to HTTP/3's binary :status pseudo-header, the response structure remains the same: status, headers, and body.