HTTP responses

Parameters#

HTTP/1.1 200 OK \r\n

HTTP/1.1 404 Not Found \r\n

HTTP/1.1 503 Service Unavailable \r\n

A simple HTTP 1.1 response has this format:

HTTP-Version Status-Code Reason-Phrase CRLF

As in a request, HTTP-Version indicates the version of the HTTP protocol in use; for HTTP 1.1 this must always be the string HTTP/1.1.

Status-Code is a three-digit code that indicates the status of the client’s request. The first digit of this code is the status class, which places the status code into one of 5 categories of response ^[1]:

• 1xx Informational - the server has received the request and processing is continuing
• 2xx Success - the server has accepted and processed the request
• 3xx Redirection - further action is necessary on the client’s part to complete the request
• 4xx Client Errors - the client sent a request that was malformed or cannot be fulfilled
• 5xx Server Errors - the request was valid, but the server cannot fulfil it at present

Reason-Phrase is a short description of the status code. For example, code 200 has a reason phrase of OK; code 404 has a phrase of Not Found. A full list of reason phrases is available in Parameters, below, or in the HTTP specification.

The line ends with a carriage return—line feed pair, usually represented by \r\n.

Additional Headers

Like an HTTP request, an HTTP response may include additional headers to modify or augment the response it provides.

A full list of available headers is defined in §6.2 of the specification. The most commonly-used headers are:

• Server, which functions like a User-Agent request header for the server;
• Location, which is used on 201 and 3xx status responses to indicate a URI to redirect to; and
• ETag, which is a unique identifier for this version of the returned resource to enable clients to cache the response.

Response headers come after the status line, and as with request headers are formed as such:

Name: Value CRLF

Name provides the header name, such as ETag or Location, and Value provides the value that the server is setting for that header. The line ends with a CRLF.

A response with headers might look like this:

HTTP/1.1 201 Created \r\n
Server: WEBrick/1.3.1 \r\n
Location: https://example.com/files/129742 \r\n

Message Bodies

As with request bodies, HTTP responses may contain a message body. This provides additional data that the client will process. Notably, 200 OK responses to a well-formed GET request should always provide a message body containing the requested data. (If there is none, 204 No Content is a more appropriate response).

A message body is included after all headers and a double CRLF. As for requests, its length in bytes should be given with Content-Length header. A successful response to a GET request, therefore, might look like this:

HTTP/1.1 200 OK\r\n
Server: WEBrick/1.3.1\r\n
Content-Length: 39\r\n
ETag: 4f7e2ed02b836f60716a7a3227e2b5bda7ee12c53be282a5459d7851c2b4fdfd\r\n
\r\n
Nobody expects the Spanish Inquisition.