Charles M. Kozierok The TCP-IP Guide

Подождите немного. Документ загружается.

Key Concept: Each HTTP response includes both a numeric status code and a text

reason phrase, both of which indicate the disposition of the corresponding client

request. The numeric code allows software programs to easily interpret the results of

a request, while the text phrase provides more useful information to human users. HTTP

status codes are three digits in length, with the first digit indicating the general class of the

reply.

Status Codes and Reason Phrases

Table 276 lists in numerical order the status codes defined by the HTTP/1.1 standard, along

with the “standard” reason phrase and a brief description of each:

Table 276: HTTP Status Codes (Page 1 of 4)

Status

Code

Reason Phrase Description

100 Continue

Client should continue sending its request. This is a special status code;

see below for details.

101

Switching

Protocols

The client has used the Upgrade header to request the use of an alter-

native protocol and the server has agreed.

200 OK

Generic successful request message response. This is the code sent most

often when a request is filled normally.

201 Created

The request was successful and resulted in a resource being created. This

would be a typical response to a PUT method.

202 Accepted

The request was accepted by the server but has not yet been processed.

This is an intentionally “non-commital” response that does not tell the client

whether or not the request will be carried out; the client determines the

eventual disposition of the request in some unspecified way. It is used only

in special circumstances.

203

Non-Authoritative

Information

The request was successful, but some of the information returned by the

server came not from the original server associated with the resource but

from a third party.

204 No Content

The request was successful, but the server has determined that it does not

need to return to the client an entity body.

205 Reset Content

The request was successful; the server is telling the client that it should

reset the document from which the request was generated so that a

duplicate request is not sent. This code is intended for use with forms.

206 Partial Content

The server has successfully fulfilled a partial GET request. See the topic on

methods for more details on this, as well as the description of the Range

header.

300 Multiple Choices

The resource is represented in more than one way on the server. The

server is returning information describing these representations, so the

client can pick the most appropriate one, a process called agent-driven

negotiation.

301

Moved

Permanently

The resource requested has been moved to a new URL permanently. Any

future requests for this resource should use the new URL.

This is the proper method of handling situations where a file on a server is

renamed or moved to a new directory. Most people don't bother setting this

up, which is why URLs “break” so often, resulting in 404 errors as

discussed below.

302 Found

The resource requested is temporarily using a different URL. The client

should continue to use the original URL. See code 307.

303 See Other

The response for the request can be found at a different URL, which the

server specifies. The client must do a fresh GET on that URL to see the

results of the prior request.

304 Not Modified

The client sent a conditional GET request, but the resource has not been

modified since the specified date/time, so the server has not sent it.

305 Use Proxy

To access the requested resource, the client must use a proxy, whose URL

is given by the server in its response.

306 (unused) Defined in an earlier (draft?) version of HTTP and no longer used.

307

Temporary

Redirect

The resource is temporarily located at a different URL than the one the

client specified.

Note that 302 and 307 are basically the same status code. 307 was

created to clear up some confusion related to 302 that occurred in earlier

versions of HTTP (which I'd rather not get into!)

400 Bad Request

Server says, “huh?” ☺ Generic response when the request cannot be

understood or carried out due to a problem on the client's end.

401 Unauthorized

The client is not authorized to access the resource. Often returned if an

attempt is made to access a resource protected by a password or some

other means without the appropriate credentials.

402 Payment Required

This is reserved for future use. Its mere presence in the HTTP standard

has caused a lot of people to scratch their chins and go “hmm…” ☺

403 Forbidden

The request has been disallowed by the server. This is a generic “no way”

response that is not related to authorization. For example, if the maintainer

of Web site blocks access to it from a particular client, any requests from

that client will result in a 403 reply.

404 Not Found

The most common HTTP error message, returned when the server cannot

locate the requested resource. Usually occurs due to either the server

having moved/removed the resource, or the client giving an invalid URL

(misspellings being the most common cause.)

405

Method Not

Allowed

The requested method is not allowed for the specified resource. The

response includes an Allow header that indicates what methods the server

will permit.

Table 276: HTTP Status Codes (Page 2 of 4)

Status

Code

Reason Phrase Description

406 Not Acceptable

The client sent a request that specifies limitations that the server cannot

meet for the specified resource. This error may occur if an overly-restrictive

list of conditions is placed into a request such that the server cannot return

any part of the resource.

407

Proxy Authenti-

cation Required

Similar to 401, but the client must first authenticate itself with the proxy.

408 Request Timeout

The server was expecting the client to send a request within a particular

time frame and the client didn't send it.

409 Conflict

The request could not be filled because of a conflict of some sort related to

the resource. This most often occurs in response to a PUT method, such

as if one user tries to PUT a resource that another user has open for

editing, for example.

410 Gone

The resource is no longer available at the server, which does not know its

new URL. This is a more specific version of the 404 code that is used only

if the server knows that the resource was intentionally removed. It is seen

rarely (if ever) compared to 404.

411 Length Required

The request requires a Content-Length header field and one was not

included.

412 Precondition Failed

Indicates that the client specified a precondition in its request, such as the

use of an If-Match header, which evaluated to a false value. This indicates

that the condition was not satisfied so the request is not being filled. This is

used by clients in special cases to ensure that they do not accidentally

receive the wrong resource.

413

Request Entity Too

Large

The server has refused to fulfill the request because the entity that the

client is requesting is too large.

414

Request-URI Too

Long

The server has refused to fulfill the request because the URL specified is

longer than the server can process. This rarely occurs with properly-formed

URLs but may be seen if clients try to send gibberish to the server.

415

Unsupported

Media Type

The request cannot be processed because it contains an entity using a

media type the server does not support.

416

Requested Range

Not Satisfiable

The client included a Range header specifying a range of values that is not

valid for the resource. An example might be requesting bytes 3,000

through 4,000 of a 2,400-byte file.

417 Expectation Failed

The request included an Expect header that could not be satisfied by the

server.

500

Internal Server

Error

Generic error message indicating that the request could not be fulfilled due

to a server problem.

501 Not Implemented

The server does not know how to carry out the request, so it cannot satisfy

it.

502 Bad Gateway

The server, while acting as a gateway or proxy, received an invalid

response from another server it tried to access on the client's behalf.

Table 276: HTTP Status Codes (Page 3 of 4)

Status

Code

Reason Phrase Description

The 100 (Continue) Preliminary Reply

Phew. Now, let's go back to the top, status code 100. Normally, a client sends a complete

request to the server, and waits for a response to it (while optionally pipelining additional

requests). In certain circumstances, however, the client might wish to check in advance if

the server is willing to accept the request before it bothers sending the whole message.

This is not a common occurrence, because most requests are quite small, which makes it

not worth the bother. However, in cases where a user wants to submit a very large amount

of data to an online program, or use PUT to store a large file, for example, checking with the

server first can be a useful optimization.

In this situation, the client sends a request containing the special header “Expect: 100-

continue”. Assuming that the server supports the feature, it will process the request's

headers and immediately send back the “100 Continue” preliminary reply. This tells the

client to continue sending the rest of the request. The server then processes it and

responds normally. If the server doesn't send the 100 response after a certain amount of

time, the client will typically just send the rest of the request anyway.

Note: In some cases, servers send these preliminary replies even when they are

not supposed to, so clients must be prepared to deal with them (they are simply

discarded, since they contain no information).

503

Service

Unavailable

The server is temporarily unable to fulfill the request for internal reasons.

This is often returned when a server is overloaded or down for

maintenance.

504 Gateway Timeout

The server, while acting as a gateway or proxy, timed out while waiting for

a response from another server it tried to access on the client's behalf.

505

HTTP Version Not

Supported

The request used a version of HTTP that the server does not understand.

Table 276: HTTP Status Codes (Page 4 of 4)

Status

Code

Reason Phrase Description

HTTP Message Headers

HTTP communication takes place through the relatively simple exchange of request and

response messages. There are only a small number of methods (commands) supported by

the protocol, which might give one the impression that the protocol is quite limited. Looks

can be deceiving, however. Much of the functionality in HTTP is actually implemented in the

form of message headers, which convey important details between clients and servers.

Some headers can appear in only HTTP requests, some in only HTTP responses, and

some in either type of message. Since they are so important, there are literally dozens of

them, and many apply to both requests and responses, I decided to describe them in detail

in a separate section rather than try to summarize them too much in the course of

describing the message formats

In this section I provide a description of each of the many headers used in HTTP request

and response messages. The section contains four topics, each of which covers one of the

four basic types of HTTP headers: general headers, request headers, response headers

and entity headers.

Background Information: I assume here that you have already read the

preceding section describing HTTP message formats.

Note: For the purpose of determining how Web caches treat HTTP messages,

HTTP headers are categorized as either end-to-end or hop-by-hop headers. The

former are meaningful only to the ultimate recipient of a message, while the latter

are relevant to each device in the chain of devices (such as proxies) connecting a client and

server. To avoid unnecessary complication I have not categorized the headers in this

section using these categories; see the topic on caching for more information. In the

descriptions of the individual headers, I indicate which headers are hop-by-hop; all others

are end-to-end.

HTTP General Headers

HTTP general headers are so named because unlike the other three categories, they are

not specific to any particular kind of message or message component (request, response or

message entity). General headers are used primarily to communicate information about the

message itself, as opposed to what content it carries. They provide general information and

control how a message is processed and handled.

Despite not being specific to either requests or replies, some general headers are used

either mostly or entirely in one or the other type of message. There are also some general

headers that can appear in either a request or a reply, but have a somewhat different

meaning in each.

Cache-Control

Specifies directives that manage how caching is performed either for an HTTP request or

response. These directives affect the handling of a request or response by all devices in the

request/response chain from the HTTP client, through any present intermediaries, to the

HTTP server (or the other way, from the server, through intermediaries, to the client). They

override any default caching behavior performed by a device. See the topic on caching for a

full exposition of the subject.

There are a dozen individual directives that can appear in this header, the full details of

which can be found in RFC 2616. Even though this is a general header, some directives

can appear only in a request or a response. Some also include an additional parameter,

such as a number of seconds, that control their interpretation. Table 277 provides a brief

summary of the different Cache-Control options and how they are used.

Note that only one directive may appear in a Cache-Control header, but more than one

such header can appear in a message.

Table 277: HTTP Cache-Control Directives (Page 1 of 2)

Cache-

Control

Directive

HTTP

Message

Type

Description

no-cache

Request or

Response

When present, forces a caching device to forward any subsequent requests

for the same content to the server for revalidation. That is, the cache must

check with the server to ensure that the cached data is still valid.

Also see the Pragma header description, for an alternative way of accom-

plishing the same thing.

public Response

Indicates that the response may be cached by any cache, including a shared

one (a cache used by many clients). See the topic on caching for more details

on shared caches.

private Response

Specifies that the response is intended for only a particular user and should

not be placed into a shared cache.

no-store

Request or

Response

Specifies that the entire request or response should not be stored in a cache.

This is used sometimes to prevent the storing of sensitive documents in

caches where unauthorized people might be able to access them. However,

as the HTTP standard points out, this is really a very rudimentary security

measure and should not be trusted a great deal (since a malicious cache

operator could simply ignore the directive.)

max-age

Request or

Response

In a request, indicates that the client is willing to accept a response whose age

is no greater than the value specified. In a response, indicates the maximum

age of the response before it is considered “stale”—this is an alternative to the

use of the Expires header and takes precedence over it.

Connection

Contains instructions that pertain only to this particular connection, and must not be

retained by proxies and used for further connections. The most common use of this header

is with the parameter “close”, as follows:

Connection: close

This overrides the default persistent connection behavior of HTTP/1.1, forcing the

connection to terminate after the server's response. Connection is a hop-by-hop header.

Date

Indicates the date and time when the message originated. This is the same as the Date

header in the RFC 822 e-mail format. A typical example would be:

Date: Wed, 06 Aug 2003 16:43:50 GMT

s-maxage Response

If present, this directive specifies the maximum age for shared caches

receiving the response. Private caches (ones that serve only a single client)

use the max-age value described just above.

min-fresh Request

Specifies that the client wants a response that is not only not stale at the time

the request is received, but that will remain “fresh” for the specified number of

seconds.

max-stale Request

If sent without a parameter, indicates that the client is willing to accept a stale

reply (one that has expired). If a numeric parameter is included, it indicates

how stale, in seconds, the response may be.

only-if-

cached

Request

Used only in special circumstances, this directive forces the reply to come

from a cache only; the content may not come from the actual specified HTTP

server.

must-

revalidate

Response

Instructs a cache to revalidate its cache entry for the given response with the

original server after it becomes stale. This is used to prevent problems with

certain types of transactions that can occur if stale cache entries are sent to a

client (perhaps as a result of the client using the max-stale directive.)

proxy-

revalidate

Response

Similar to must-revalidate, but applies only to proxies that service many users.

Private caches, such as those on individual client computers, are not affected.

no-

transform

Request or

Response

Some caches will, by default, change the form in which certain cached entries

are stored, to save space or improve performance. In cases where this might

cause problems, the client or server can use this directive to request that this

transformation not be performed.

Table 277: HTTP Cache-Control Directives (Page 2 of 2)

Cache-

Control

Directive

HTTP

Message

Type

Description

Pragma

Used to enable implementation-specific directives to be applied to all devices in the

request/response chain. One common use of this header is to suppress caching by

including “Pragma: no-cache” in a message. This has the same meaning as a “Cache-

Control: no-cache” header, and is included in HTTP/1.1 for backward compatibility with

HTTP/1.0 (which supports Pragma but not Cache-Control).

Trailer

When “chunked” transfers are used, certain headers may be placed as trailers, after the

data being sent. In this case, the Trailer header is included before the data, and lists the

names of the headers that are actually trailers in that message. This warns the recipient to

look for them after the data. Trailer is a hop-by-hop header.

Transfer-Encoding

Indicates what encoding has been used for the body of the message, to ensure that it is

able to be transferred properly between devices. This header is most often used with the

“chunked” transfer method. Note that this header describes encoding applied to an entire

message, and is thus not the same as the Content-Encoding entity header, which specifi-

cally describes the entity carried in a message. See the topic on content and transfer

encodings for a full discussion. This header applies only to a single transfer, so it is a hop-

by-hop header.

Upgrade

Allows a client device to specify what additional protocols it supports. If the server also

supports one of the protocols the client listed, the server may agree to “upgrade” the

connection to the alternative protocol. It indicates the protocol to which it is upgrading by

including an Upgrade header in a 101 (“Switching Protocols”) response to the client. This is

a hop-by-hop header.

Via

Included by intermediary devices to indicate to the recipient what gateways, proxies and/or

tunnels were used in conveying a request or response. This header allows easy tracing of

the path a message took over a potentially complex chain of devices between a client and

server.

Warning

Used when needed to provide additional information about the status of a message. Many

of the defined warning header types are related to caching. More than one Warning header

may appear in a message, and each typically includes a three-digit numeric code as well as

a plain text message—the same basic format used in HTTP response status codes.

Table 278 briefly lists the warnings defined in RFC 2616.

Key Concept: HTTP general headers can appear in either an HTTP Request or

HTTP Response message. They are used to communicate information about the

message itself, as opposed to its contents. General headers are used for functions

such as specifying the date and time of a message, controlling how the message is cached,

and indicating its transfer encoding method.

HTTP Request Headers

HTTP request headers, as you might imagine, are used only in HTTP request messages,

and serve a number of functions in them. First, they allow the client to provide information

about itself to the server. Second, they give additional details about the nature of the

request that the client is making. Third, they allow the client to have greater control over

how its request is processed and how (or even if) a response is returned by the server or

intermediary.

This is the largest of the four categories of HTTP headers, comprising over a dozen

different types.

Allows the client to tell the server what Internet media types it is willing to accept in a

response. The header may list several different MIME media types and subtypes that the

client knows how to deal with. Each may be prepended with a “quality value” (“q”

Table 278: HTTP Warning Header Codes

Warning

Code

Warning Text Description

110 Response is stale

Must be included when a response provided by a cache is stale (that

is, has passed the expiration time set for it.)

111 Revalidation failed

A cache attempted to revalidate a cached entry but was unsuc-

cessful, so it returned its (stale) cached entry.

112 Disconnected operation The cache is disconnected from the rest of the network.

113 Heuristic expiration

Included if the cache chose a freshness lifetime of more than 24

hours, and the age of the response is also greater than 24 hours.

199 Miscellaneous warning Catch-all code for other, non-specific warnings.

214 Transformation applied

Warns the recipient that an intermediate cache or proxy applied a

transformation of some type to change the content coding or media

type of the message or message body.

299

Miscellaneous

persistent warning

Similar to code 199 but indicates a persistent warning.

parameter) to indicate the client's preference. If this header is not specified, the default is

for the server to assume any media type may be sent to the client. See the topics on entity

media types and content negotiation for more information on how this header is used.

Accept-Charset

Similar to Accept, but specifies what character sets the client is willing to accept in a

response, rather than what media types. Again, the listed charsets may use a “q” value, and

again, the default if the header is omitted is for the client to accept any character set.

Accept-Encoding

Similar to Accept and Accept-Charset, but specifies what content encodings the client is

willing to accept. This is often used to control whether or not the server may send content in

compressed form. (Remember that content codings are not the same as transfer

encodings.)

Accept-Language

Similar to the preceding Accept-type headers, but provides a list of language tags that

indicate what languages the client supports or expects the server to use in its response.

Authorization

Used by the client to present authentication information (called “credentials”) to the server

to allow the client to be authenticated. This is required only when the server requests

authentication, often by sending a 401 (“Unauthorized”) response to the client's initial

request. This response will contain a WWW-Authenticate header providing the client with

details on how to authenticate with the server. See the topic on security and privacy.

Expect

Indicates certain types of actions that the client is expecting the server to perform. Usually

the server will accept the indicated parameters; if not, it will send back a 417 (“Expectation

Failed”) response. The most common use of this field is to control when the server sends a

100 (“Continue”) response. The client indicates that it wants the server to send this prelim-

inary reply by including the “Expect: 100-continue” header in its request. (See the end of the

topic on status codes for details.)

From

Contains the e-mail address of the human user making the request. This is optional, and

since it is easily spoofed, should be used only for informational purposes, and not for any

type of access rights determination or authentication.