HTTP Message Flow and Message Parts - Part 1 of Chapter 3 from HTTP: The Definitive Guide (5/7)
   [previous] [next] |
HTTP: The Definitive Guide, Chapter 3: HTTP Messages
Status codes
As methods tell the server what to do, status codes tell the client what happened. Status codes live in the start lines of responses. For example, in the line "HTTP/1.0 200 OK," the status code is 200.
When clients send request messages to an HTTP server, many things can happen. If you are fortunate, the request will complete successfully. You might not always be so lucky. The server may tell you that the resource you requested could not be found, that you don't have permission to access the resource, or perhaps that the resource has moved someplace else.
Status codes are returned in the start line of each response message. Both a numeric and a human-readable status are returned. The numeric code makes error processing easy for programs, while the reason phrase is easily understood by humans.
The different status codes are grouped into classes by their three-digit numeric codes. Status codes between 200 and 299 represent success. Codes between 300 and 399 indicate that the resource has been moved. Codes between 400 and 499 mean that the client did something wrong in the request. Codes between 500 and 599 mean something went awry on the server.
The status code classes are shown in Table 3-2.
Table 3-2: Status code classes
Overall range | Defined range | Category |
|---|---|---|
100-199 | 100-101 | Informational |
200-299 | 200-206 | Successful |
300-399 | 300-305 | Redirection |
400-499 | 400-415 | Client error |
500-599 | 500-505 | Server error |
Current versions of HTTP define only a few codes for each status category. As the protocol evolves, more status codes will be defined officially in the HTTP specification. If you receive a status code that you don't recognize, chances are someone has defined it as an extension to the current protocol. You should treat it as a general member of the class whose range it falls into.
For example, if you receive status code 515 (which is outside of the defined range for 5XX codes listed in Table 3-2), you should treat the response as indicating a server error, which is the general class of 5XX messages.
Table 3-3 lists some of the most common status codes that you will see. We will explain all the current HTTP status codes in detail later in this chapter.
Table 3-3: Common status codes
Status code | Reason phrase | Meaning |
|---|---|---|
200 | OK | Success! Any requested data is in the response body. |
401 | Unauthorized | You need to enter a username and password. |
404 | Not Found | The server cannot find a resource for the requested URL. |
Reason phrases
The reason phrase is the last component of the start line of the response. It provides a textual explanation of the status code. For example, in the line "HTTP/1.0 200 OK," the reason phrase is OK.
Reason phrases are paired one-to-one with status codes. The reason phrase provides a human-readable version of the status code that application developers can pass along to their users to indicate what happened during the request.
The HTTP specification does not provide any hard and fast rules for what reason phrases should look like. Later in this chapter, we list the status codes and some suggested reason phrases.
Version numbers
Version numbers appear in both request and response message start lines in the format HTTP/x.y. They provide a means for HTTP applications to tell each other what version of the protocol they conform to.
Version numbers are intended to provide applications speaking HTTP with a clue about each other's capabilities and the format of the message. An HTTP Version 1.2 application communicating with an HTTP Version 1.1 application should know that it should not use any new 1.2 features, as they likely are not implemented by the application speaking the older version of the protocol.
The version number indicates the highest version of HTTP that an application supports. In some cases this leads to confusion between applications,[2] because HTTP/1.0 applications interpret a response with HTTP/1.1 in it to indicate that the response is a 1.1 response, when in fact that's just the level of protocol used by the responding application.
Note that version numbers are not treated as fractional numbers. Each number in the version (for example, the "1" and "0" in HTTP/1.0) is treated as a separate number. So, when comparing HTTP versions, each number must be compared separately in order to determine which is the higher version. For example, HTTP/2.22 is a higher version than HTTP/2.3, because 22 is a larger number than 3.
2. See https://httpd.apache.org/docs-2.0/misc/known_client_problems.html for more on cases in which Apache has run into this problem with clients. Back
[previous] [next] |
Created: January 13, 2003
Revised: January 13, 2003
URL: https://webreference.com/programming/http/chap3/1/5.html
Find a programming school near you