Chapter 9 ■ http Clients
156
Many HTTP servers will signal a client error unless the client supplies at least a Host header revealing which
hostname was used in the URL. The result, in its absence, is often 400 Bad Request. See the following section for more
about error codes and their meanings.
Status Codes
The response line starts with the protocol version instead of ending with it like the request line, and then it supplies a
standard status code before concluding with an informal textual description of the status for presentation to the user
or entry in a log file. When everything has gone perfectly, the status code is 200, in which case the response line often
reads as follows:
HTTP/1.1 200 OK
Because the text following the code is merely informal, a server could replace OK with Okay or Yippee or It
Worked or even with text that had been internationalized for the country in which the server was operating.
The standard—in particular, RFC 7231—specifies more than two dozen return codes for situations both general
and specific. You may consult the standard if you need to learn the complete list. In general, the 200s indicate
success, the 300s redirection, the 400s that the client request is unintelligible or illegal, and the 500s that something
unexpected has gone wrong that is entirely the server’s fault.
There are only a few that will concern you in this chapter.
• 200 OK: The request was successful. If a POST, it had its intended effect.• 301 Moved Permanently: The path, while valid, is not the canonical one for the resource in
question (though it might have been at some point in the past), and the client should instead
request the URL specified in the Location header of the response. All future requests can skip
this old URL and go straight to the new one, if the client wants to cache it.• 303 See Other: The client can learn the result of this particular, unique request by doing a
GET against the URL specified in the Location header of the response. However, any future
attempts to access this resource will need to return to this location. As you will see in
Chapter 11, this status is crucial to the design of web sites—any form submitted successfully
with POST should return 303 so that the actual page the client sees is fetched with a safe,
idempotent GET operation instead.• 304 Not Modified: The document body does not need to be included in the response because
the request headers make it clear that the client already has an up-to-date version of the
document in its cache (see the “Caching and Validation” section).• 307 Temporary Redirect: Whatever request the client has made, whether GET or POST, should
be attempted again against the different URL specified in the Location header of the response.
But any future attempts to access this resource will need to return to this location. Among
other things, this allows forms to be delivered to an alternative address in case a server is
down or unavailable.• 400 Bad Request: The request does not appear to be valid HTTP.• 403 Forbidden: No password or cookie (for both, see later in this chapter) or other identifying
data is present in the request that proves to the server that the client has permission to access it.• 404 Not Found: The path does not name an existing resource. This is probably the most
famous exception code because users never see the 200 code displayed on their screen; they
see a document instead.