[ Up (Contents) ] Last Updated: 30 August 2000


The XHTML 1.0 Web development Sourcebook

HTTP Methods and Header Fields Reference


This appendix summarizes the HTTP methods, request headers, response headers, and server error messages currently defined by the various HTTP specifications. The actual structure of HTTP messages was defined in Chapter 9 and is not reproduced here. The relevant HTTP specifications are noted in the references at the end of the appendix.

Alternate Formats
This Document (Word 6 Format)


D.1 HTTP Methods

HTTP methods are specified in the first line of a request header, as noted in the previous section. Table D.1 summarizes the HTTP methods defined in HTTP 1.0 and HTTP 1.1. Note that LINK and UNLINK, although defined in HTTP 1.0, are largely unimplemented by HTTP 1.0 servers and have been dropped from the specification in HTTP 1.1. The PUT and DELETE methods are implemented by some HTTP 1.0 servers, but these implementations are not always consistent with the behavior defined in the specification.

Table D.1
HTTP Methods and Their Meanings
GET Retrieves the indicated URL. Data can also be sent to the URL by including a query string with the URL. This is the situation for data sent from ISMAP active image maps, from ISINDEX queries, and from form elements with the form attribute method = "GET".
HEAD Retrieves the HTTP header information for the indicated URL.
POST Sends the data to the indicated URL. The URL must already exist: It is an error to POST to a nonexistent URL. This method is used by HTML form elements with the attribute value method = "POST".
PUT Places the data sent by the client in the indicated URL, replacing the old contents if the URL already exists. Many, but not all, servers support PUT (support is required for WebDAV).
DELETE Deletes the resource located at the indicated URL. Many, but not all, servers support DELETE (support is required for WebDAV).
LINK (obsolete) Links an existing object to another object. For an HTML document, this would imply editing the document and adding link information to the document head. This method is not implemented on most HTTP 1.0 servers and was dropped in HTTP 1.1.
UNLINK (obsolete) Removes the link information inserted, for example, by a link method. This method is not implemented on most HTTP 1.0 servers and was dropped in HTTP 1.1.
OPTIONS Similar to HEAD, this requests that the server return a list of all communication or processing options available for the requested object. The server should return a list of all such options without actually accessing the object.
TRACE This method requests that the server receiving the request should simply return the entire request header within the body of a message/http MIME-type message. This is intended for diagnosing HTTP communications problems.
CONNECT Reserved for future use and not currently implemented.
PROPFIND Requests that the response provide a list of DAV properties for the specified resource. With WebDAV, these properties are returned in an XML document.
PROPPATCH Requests that the properties of a set of resources be patched according to the information included in the message body. With WebDAV, the message body is an XML document containing WebDAV instructions.
MKCOL Requests that the server make a new resource or collection.
COPY Requests that the server create a duplicate of the indicated resource: The location of the copy is given by a destination header field.
MOVE Requests that the server move indicated resource: A destination header field gives the target location.
LOCK Requests that the server apply a lock of some sort to the indicated resource. With WebDAV, locking information is provided in the XML message body.
UNLOCK Requests that the server remove all locks from the indicated resource.


Back to top

D.2 HTTP General Header Fields

General header fields are those fields that are relevant in both requests and response headers, but that do not refer to the entity (content) part of the message. Instead, these fields provide general information about the message. Following are the defined general header fields and their meanings. The descriptions note which specification introduced this field: The notation CN refers to transparent content negotiation, and WebDAV refers to Web Distributed Authoring and Versioning.

Cache-control: cache-control-parameter (HTTP 1.1).

This header provides information that tells caching proxy servers how to handle caching for the message. For example, the directive cache-control: no-cache means that the data in the message must never be cached, and the directive cache-control: max-age: 10 indicates how long the data can be kept in the cache before it needs to be reloaded. There are many possible field values, and these values can differ depending on whether the header is describing how the data should be cached (a cache request) or describing properties of cached data (a cache response).

Connection: connection_state (HTTP 1.0 extension and HTTP 1.1).

Several HTTP 1.0 servers support keep-alive connections. With HTTP 1.0, if a browser sends the header field connection: keep-alive, then a server that supports keep-alive will not close the client-server link, allowing the client to send several requests down the still-open connection, and vice versa.

In HTTP 1.1, all connections are by default kept alive and are consequently called persistent connections. Thus, in HTTP 1.1, the connection field is returned by the server and tells the client (and any intervening proxy servers) to close the connection rather than keep it open. The connection header field that closes a connection is connection: close. Only servers that understand HTTP 1.1 will send this header.

Date: date_time (HTTP 1.0).

Gives the time and date when the current object was assembled for transmission. Note that the time must be Greenwich Mean Time (GMT) to ensure that all servers share a common time zone. Possible formats for the date_time string are discussed at the end of Chapter 9.

Pragma: server_directive (HTTP 1.0 extension and HTTP 1.1).

Pragma directives pass special-purpose information to servers. Currently, there is only one server directive, Pragma: no-cache, which tells a proxy server (or servers, if it takes multiple proxy servers to reach the resource) to always fetch the document from the actual server, and to never use a locally cached copy. With HTTP 1.1, the role of  pragma is largely supplanted by cache-control.

Trailer: header-field-name (HTTP 1.1).

When messages are chunked, each message part can have its own set of header fields to describe the content of the chunk. In this case, trailer fields should be included in the overall message header to give the names of the fields that will appear in front of each chunk. For example, the field trailer: content-length means that each chunk will be preceded by a header field giving the length of the chunk.

Transfer-encoding: encoding-type (HTTP 1.1).

This header defines what types of transformations have been applied to the message content, where such transformations are designed to ensure safe transfer of the data from the client to server, or vice versa. Unlike content-encoding, this is a property of the way the message is being sent, and not a property of the content of the message. The only supported value is chunked, which indicates that the message is being sent as a sequence of data chunks.

Upgrade: supported-protocols-list (HTTP 1.1).

This header contains a list of additional communication protocols supported by the client: The server can then choose to switch to one of the available protocols, should it choose to do so. This is currently not widely supported.

Via: protocol received-by (HTTP 1.1).

This header is sent by proxy servers and indicates where the proxy server received the data from, and the protocol version used to receive the data. An example is via: HTTP/1.1 www.boo.org:80.

Warning: code server-id text date (HTTP 1.1).

A warning header field contains information about possible problems with the message. The code identifies the nature of the possible problem (RFC 2616 defines a set of three-digit warning codes), and server-id identifies the server that added this warning code to the message. The text field then provides a text description of the warning, and date gives the date at which the warning was added.

Back to top

D.3 HTTP Request Header Fields

Request header fields are used by a client to communicate information about the client (e.g., the types of data the client prefers or can accept) or about the request (e.g., send data only if the resource has changed since the given date and time). Thus, these headers act as modifiers of the request, in that the response may vary depending on the information sent in these fields. The descriptions note which specification introduced this field: The notation CN refers to transparent content negotiation, and WebDAV refers to Web Distributed Authoring and Versioning.

Accept: type/subtype, type/subtype2 ... (HTTP 1.0).

Contains a list of MIME content-types acceptable to the client, separated by commas. Types can also contain parameters describing their relative merit (q  = 0.0 to q = 0.1), and the maximum allowed size for a resource (mxb  = num_bytes). The use of these terms was discussed earlier in this chapter.

Accept-Charset: charset1, charset2 ... (HTTP 1.0).

Lists the character sets preferred by the browser, other than the default (ASCII or ISO Latin-1). Thus, the server, if capable, can deliver the resource using the character set preferred by the browser.

Accept-Encoding: enc_type1, enc_type2 ... (HTTP 1.0).

Lists the data encoding types acceptable to the client. For example,   Accept-Encoding: compress tells the server that the client can accept compressed data in the compress format. Currently understood encoding types are compress and gzip, which may also be seen under the names x-compress and x-gzip. Other possible (but largely unimplemented) encoding types are base64 and quoted-printable. If a server sends a document in one of these encodings, it must include the appropriate Content-encoding response header.

Accept-features: feature_info ... [CN (RFC 2295)].

This provides a list of special features that the server can use to determine the type of resource to return to the browser: The value is a comma-separated list of features. There are no defined values for these features, although there is a defined syntax for how values can be constructed (e.g., the exclamation mark denotes negation). A simple example is

Accept-features: paper=a4, !screen, colordepth=5

which tells the server that the client can accept media designed for a4 paper, cannot accept media designed for screen, and can accept media with a colordepth value of 5. A server can return a list of resources that satisfy these conditions within a collection of alternates header fields.

Accept-language: lang1, lang2 ... (HTTP 1.0).

This field lists the languages preferred by the browser. For example, the field

Accept-language fr-ca, fr, en

would mean that the browser prefers Canadian French, will accept standard French if Canadian French is not available, and last, will accept English if the other two are not available.

Authorization: scheme scheme_data (HTTP 1.0).

This passes user authentication and encryption scheme information to the server. Scheme indicates the authorization scheme to be used, with scheme_data containing scheme-specific authorization data. If authentication is not required, this field is absent.

Cookie: name=value cookie_info [HTTP State Management (RFC 2109)].

This passes stored state information from the client to server. Servers can use a special Set-Cookie: response header to place state information, in the form of name/value pairs, on a client. The client will then return this information, but only to the server that originally sent the "cookie."

Depth: level [WebDAV (RFC 2518)].

Tells the depth to which the DAV method should apply to the resource: that is, only to the resource, to the resource and any child resources (e.g., a directory and its files), or the resource and all children (e.g., a directory and all subdirectories and files).

Destination: URL [WebDAV (RFC 2518)].

Indicates the destination of the resource: This is relevant only if the request method is COPY or MOVE.

Expect: expectation (HTTP 1.1).

This header tells the server that the browser expects the server to be able to perform specifically defined actions. For example, the field expect: 100-continue   means that the client is asking the server if it can continue by sending the data described in the request headers. The server should respond with an appropriate header indicating whether the client can or cannot continue with the request.

From: mail_address (HTTP 1.0).

Contains the address, in Internet mail format, of the user accessing the server. In general, a browser does not send this information, out of concern for a user’s privacy.

Host: server.domain.name:port (HTP 1.0 extension; HTTP 1.1).

Contains the domain name and port number (optional if port 80) to which the request is being directed. This is useful if the request is passing through a proxy server, or if the request is to a server that has more than one domain name or IP address. Older browsers do not send this field.

If: expression [WebDAV (RFC 2518)].

This is a generalization of the If-match, If-modified-since, and other such headers. The value for this field is a logical expression defining conditions for the request. If the conditions are not satisfied, then the server should not continue with the requested transaction.

If-match: entity-tag (HTTP 1.1).

This header is sent with a request to make the request conditional—if the requested resource has the indicated entity tag value (as defined by an ET   header fields), the resource should be processed as per the request. This header is defined to improve the efficiency of updating cached data.

If-Modified-Since: date_time (HTTP 1.0).

This header is sent with a request to make the request conditional—if the requested document has not changed since the indicated time and date, the server does not process the document. Possible formats for the date_time string are discussed at the end of Chapter 9. If the document is not sent, the server should send the response header message 304 (not modified).

If-none-match: entity-tags (HTTP 1.1).

This header is sent with a request to make the request conditional—if none of the entity tags match the requested resource then the resource should be processed as per the request. This header is defined to improve the efficiency of updating cached data.

If-range: range (HTTP 1.1).

This header is used to conditionally retrieve portions of a resource that have changed.

If-unmodified-since: date_time (HTTP 1.1).

This header is sent with a request to make the request conditional—if the resource has not been modified since the indicated date and time, then the transaction should proceed as per the request.

Lock-token: coded-URL [WebDAV (RFC 2518)].

This is used with an UNLOCK request to identify the lock to be removed as a result of the request. A coded URL is simply a URL surrounded by angle brackets (i.e., <url-string> ).

Max-forwards: number (HTTP 1.1).

Defines the maximum number of proxy servers the message can be forwarded to before forwarding should be stopped. This is designed for use with OPTIONS or TRACE methods for diagnosing HTTP problems (analogous to the TCP/IP traceroute utility).

Negotiate: directive [CN (RFC 2295)].

This field contains directives to define how the content negotiation process should proceed. The allowed values for the directives are defined in RFC 2295. This will only be supported by servers that support transparent content negotiation.

Overwrite: T (for true) or F (for false) [WebDAV (RFC 2518)].

This is used during a COPY or MOVE method request to indicate whether the operation should or should not overwrite an existing resource. The value T means that overwriting is allowed, and F means that overwriting is not allowed.

Proxy-authorization: scheme scheme_data (HTTP 1.1).

Gives authorization information that lets the user authenticate him- or herself to the proxy server. The field value is as for the authorization

Range: range_value (HTTP 1.1).

Specifies the range of the data as a chunk of the actual entity from which the data is derived. Values can be ranges in bytes (e.g., range: 0-65535)), although other units are supported. Ranges are used with chunked data transfers, to keep track of the range covered by the different chunks.

Referer: URL (HTTP 1.0).

Gives the URL of the document from which the request originated. This can be a partial URL, in which case it is interpreted relative to the URL of the document being requested. If a document contains an HTML BASE element, then the URL referenced by this element should be sent instead.

TE: transfer-encoding-info (HTTP 1.1).

Indicates whether the client will accept trailer fields in chunked transfer encodings. If it does, then the value must be TE: trailers.

Timeout: timeout-value [WebDAV (RFC 2518)].

This is used during a LOCK method request to indicate how long the lock should be reserved for the client making the request. A WebDAV server can use this as a hint to how long the requestor will need the lock: The WebDAV server would be likely to cancel the lock and release the resource after the time specified by the timeout field. This is a hint to the WebDAV server, which can ignore timeout values. Allowed values are defined in RFC 2518.

User-Agent: program/version comments (HTTP 1.0).

Provides information about the client software making the request. An example is

User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)

Back to top

D.4 HTTP Response Header Fields

The following is a list of currently implemented HTTP response headers. These headers define properties about the server, and about the client-server connection, such as the server capabilities, the date the message was sent, requests for authentication data required by the connection, and so on. The descriptions note which specification introduced this field: The notation CN refers to transparent content negotiation, and WebDAV refers to Web Distributed Authoring and Versioning.

Accept-ranges: type (HTTP 1.1).

Indicates whether the server accepts range requests, and if so of what type. Thus, the response accept-ranges: bytes says that the server will accept byte range requests, but no others. The value none means that range requests are not accepted.

Age: seconds (HTTP 1.1).

Provides an estimate of the time, in seconds, since the response was generated on the origin server. This lets a proxy server (or client) estimate how stale the data may be.

ETag: entity-tag (HTTP 1.1).

Provides the entity tag value corresponding to the data being returned. This is used in content negotiation, and lets the server distinguish (using differing etag values) between different entities returned upon requests to the same URL. The HTTP 1.1 specification defines how entity tag values are constructed.

Location: URL (HTTP 1.0).

Contains a URL to which the client should be redirected. This is returned by a server if the requested document was not found on the server, but the server knows the correct (moved) location of the resource. A Location header is included when a redirection HTTP status field (status 301 or 302) is returned.

Proxy-authenticate: scheme scheme_message (HTTP 1.1).

Returned by a proxy server, and requests authentication information for the proxy server, and is otherwise equivalent to www-authenticate. Authentication information is returned in a proxy-authorization header field.

Retry-after: date_time (or seconds) (HTTP 1.1).

Contains a time and date (or a time in seconds) after which a client should retry to access a resource that was temporarily unavailable. This field is appropriate when the status header 503 (service unavailable) is being returned. It might be returned by a server or gateway program that is temporarily unable to comply with a request. The value can be a date and time (as defined at the end of Chapter 9) or a length of time in seconds. Note that most current browsers do not understand the retry-after field.

Server: program/version other_info (HTTP 1.0).

Contains information about the server software from which the resource originated. The program and version information fields are separated by a slash. Other information is presented as text after this. An example is

Server: Apache/1.3.11 (Unix) PHP/3.0.14.

Set-cookie: cookie-information [HTTP State Management (RFC 2109)].

Contains cookie data sent by the server. A browser that supports cookies will save this data to disk and will return it to the server that originally deposited the data. The mechanism is discussed in detail in Chapter 10.

Status-URI: status-code URL [WebDAV (RFC 2518)].

This field may be used with a response status code 102 (still processing) response and can indicate the processing status (using a status-code, as defined in Table D.2) of the associated URL. A response can contain multiple status-URI lines to report on the processing status of multiple resources.

TCN: signal [CN (RFC 2295)].

This field is returned by a server to indicate that the resource is being transparently content-negotiated and to indicate the type of the response (i.e., that the response is returning a resource or a list of possible resources to choose from). Allowed values are defined in RFC 2295. This header can only be returned for resources that are being transparently negotiated.

Variant-Vary: field-names [CN (RFC 2295)].

This is like a vary field, except that it provides vary data for a transparently negotiated content delivery, and tells the client (or proxy server) which fields were used to determine the returned variant. An example is

variant-vary: content-type, content-encoding, content-language.

Vary: field-names (HTTP 1.1).

This indicates the set of request header fields that fully defines whether the content of the cache can be used in response to a request. This is to ensure that the right variant is returned subject to a request.

WWW-Authenticate: scheme scheme_message (HTTP 1.0).

Tells the client that authentication is required, and also states the encryption and authorization schemes the server wants to use. This is only used for directory, file, or CGI program access that requires user authentication. Scheme  gives the name of the authorization scheme (e.g. Basic or Digest), and scheme_message gives related data.

Back to top

D.5 Entity Header Fields

These headers define specific properties of the message or resource being sent or describe information about resources that could be sent. The descriptions note which specification introduced this field: The notation CN refers to transparent content negotiation and WebDAV refers to Web Distributed Authoring and Versioning.

Allow: method1, method2, ... (HTTP 1.1).

Contains a comma-separated list of HTTP methods supported by the resource. This must be returned if the status code 405 (HTTP method not allowed) is being returned. It can contain any supported method, including nonstandard ones supported by the server.

Alternates: feature_info ... [CN (RFC 2295)].

This field returns a list of possible variants that the server could return, given the accept- header field information in the original request and the data available on the server. An example field might be

Alternates: {"p.1" 0.9 {type text/html} {language en}},

{"p.2" 0.7 {type text/html} {language fr}},

{"p.3" 1.0 {type text/xml} {language en}}

which denotes three alternate resources. A browser would then automatically rerequest the preferred resource, or may prompt the user for this selection. RFC 2295 denotes the syntax for the value of an alternates header field.

Content-Encoding: encoding_type (HTTP 1.0).

Specifies the encoding type mechanism appropriate to the data. The only currently valid types are compress and gzip, and their synonyms x-compress and x-gzip (the latter are obsolete and are being phased out). You can only have one content-encoding type per header. This allows compressed files to be uncompressed on the fly by the client.

Content-language: lang (HTTP 1.0).

Gives the human (as opposed to computer) language of the message being sent after the header.

Content-length: length (HTTP 1.0).

Gives the length, in bytes, of the message being sent after the header.

Content-location: URL (HTTP 1.1).

Provides an alternate URL for retrieving the resource being returned in the response.

Content-MD5: MD5-checksum (HTTP 1.1).

Returns an MD5 checksum generated from the data in the message body. The client can use this checksum to verify that the data was not modified in transit.

Content-range: range (HTTP 1.1).

Specifies the range of the entity that is covered by the returned data chunk and is only used with chunked data transfers. For example, the value content-range: 1024-65536 means that the entity corresponds to the indicated range of bytes of the full entity.

Content-type: type/subtype;parameters (HTTP 1.0).

Gives the MIME content-type of the message being sent to the client. The content-type can contain optional parameter fields, separated from the type/subtype by a semicolon. For example

Content-type: text/html; charset=ISO-10646-1

indicates that the message is an HTML document, written using the ISO 10646-1 character set. Parameter fields are ignored by most current browsers.

DAV: v1,v2,.... [WebDAV (RFC 2518)].

Indicates a comma-separated list of the versions of the DAV language and protocol supported by the resource. An example is: DAV: 1,2, which means the resource supports both level 1 and level 2 DAV.

Expires: date_time (HTTP 1.0).

Gives the time and date after which the information being sent should be considered invalid. This tells clients when to refresh data in their local cache. Proxy servers can use this field to determine when a cached copy of a document should be refreshed.

Last-modified: date_time (HTTP 1.0).

Gives the date and time that the document was last modified: The allowed format is defined at the end of Chapter 9. As in the Date field, the date must be given in Greenwich Mean Time (GMT).

Back to top

D.6 Deprecated Header Fields

The following header fields were defined in previous HTTP specifications, but they have been dropped as they were never implemented in software and are known to have significant problems.

Link: link_information. Was intended to define relationships between the data being returned by the server and other resources, analogous to HTML link elements.

MIME-version: version_number. Specifies the MIME specification used in the message. This was seen as largely irrelevant (HTTP uses MIME, but also extends it in certain ways), so this header was dropped.

Title: title. F Specified a title for the resource and would be equivalent to the content of an HTML title element (if the data was an HTML document).

URI: uri_of_resource (HTTP 1.0; dropped in HTTP 1.1).
Contains a URL for the resource being sent—sometimes this is an alternate URL for the same resource (as per the Location field). In general, the meaning of the URI header is not well defined, and it was dropped in HTTP 1.1 in favor of other headers with better-defined meanings.

Public: method1, method2, ... (Early versions of HTTP 1.1 only).
Specified a comma-separated list of nonstandard (experimental) methods supported by the server. This header was introduced in an early draft of the HTTP 1.1 specification, but was dropped in subsequent versions. It is supported by some older HTTP 1.0 and 1.1 servers.

Back to top

D.7 HTTP Status Codes

Table D.2
Lists the meanings of the different HTTP status codes. In general, codes 100 to 199 correspond to steps in an ongoing transaction, while 200 through 299 indicate a completed, successful transaction. Codes 300 through 399 imply redirection of some sort: Either the resource has moved and the server is returning the URL of the new location to the client, or the resource has not changed since it was last requested by the client, in which case the server is not resending the document. Codes 400 through 599 indicate an error of some type: Values in the range of 400 to 499 imply an error in the request format, and values between 500 and 599 imply an internal server error of some sort.
100 1.1 Tells the client that it can continue with a transaction. This is returned if a client sent a request without a message body, and simply was asking if it is okay to send the message. In this case, the client request must have contained an expect: 100-continue field to indicate that it will continue with the request if it receives a 100 response.
101 1.1 Tells the client that the server is willing to comply with the client's request to upgrade the protocol being used. The protocol that the server will accept is indicated by an upgrade field just after the 101 status line.
102 WD Tells the client that the server has accepted the request, but has not yet completed processing it. This simply tells the client that processing is continuing, and that the client should keep waiting for a completed response.
200 1.0 The request was completed successfully.
201 1.0 The request was a POST (or PUT) method and was completed successfully. 201 indicates that data was sent to the server, and that the server created a new resource as a result of the request.
203 1.0 The request has been accepted for processing, but the results of this processing are unknown. This would be returned, for example, if the client deposited data for batch processing at a later date.
204 1.0 The GET (or HEAD) request was fulfilled (as with 200), but has returned partial or nonauthoritative information.
205 1.1 The request was fulfilled, but there is no new information to send to the client. The browser should do nothing and should continue.
1.1 The response contains only part of the requested resource. The response must contain sufficient headers that the client can tell which part of the resource is being returned.
207 WD The response contains multiple responses corresponding to the results of multiple independent operations (for example, this could be the result of a WebDAV request that created several different resources on a server).
300 1.1 The requested resource is available from more than one location, but the server could not determine which version to return to the client. The response should contain a list of the locations and their characteristics. The client should then choose the one that is most appropriate.
301 1.0 The requested resource has been permanently moved to a new URL. If this status is returned, the server should also return a location field providing the new location of the resource, as in Location: URL, where URL is the new document URL. Browsers that understand the Location field will automatically connect to the new URL.
302 1.0 The resource was found, but it actually resides at a different URL. If this status is returned, the server should also send the client the correct URL via the header Location: URL. Browsers that understand the Location field will automatically connect to the new URL. You will get a 302 redirection if a URL pointing to a directory is missing the trailing slash character.
303 1.1 The response is available at a different URL, and should be retrieved using a GET method. This lets a server, accessed via a POST method request, redirect the client to a second resource that should be accessed using the GET method.
304 1.0 A GET request was sent that contained the If-Modified-Since field, and the server found that the document had not been modified since the date specified in this field. Consequently, the server responds with this code and does not resend the document.
305 1.1 The request must be accessed through a proxy server; the response must also contain a Location field specifying the location of the proxy. A browser should automatically redirect the request to go via the specified proxy server.
1.1 The response is temporarily available at a different URL (given by a location field), and should be retrieved using a GET method. However, the client should continue to use the original (non-redirected) URL.
400 1.0 The request syntax was wrong.
401 1.0 The request required an Authorization field, and the client did not specify one. The server also returns a list of the allowed authorization schemes using a WWW-Authenticate response header. A client and server use this mechanism to negotiate an acceptable user authentication scheme.
402 1.0 The requested operation costs money and the client did not specify a way to pay. There is no specification for payment methods, so this is not currently implemented.
403 1.0 The client has requested a resource that is forbidden. No explanation is provided for this refusal.
404 1.0 The server cannot find the requested resource.
405 1.1 The client tried to access a resource using an HTTP method that is not supported by that resource. The response must include an allow field listing the allowed methods.
406 1.1 The resource was found, but could not be delivered because the type of the resource is incompatible with the acceptable types indicated by the accept or accept-encoding headers sent to the server by the client.
407 1.1 The request was to a proxy server, and the proxy server requires authentication information; the proxy server must also return a Proxy-authenticate header field to indicate the authentication scheme required by the server.
408 1.1 The client did not produce a request in a timely manner, and the server has timed out and is breaking the connection.
409 1.1 The request could not be completed due to a conflict; for example, a PUT is not allowed because someone else has locked the resource.
410 1.1 The resource was once at this location but is no longer available on the server, and no forwarding information is available.
411 1.1 The server is refusing access because the client tried to access the server and send data to the server, but did not use a content-length header to give the size of the data stream. 
412 1.1 The server is refusing access because one of the conditions in the request header field was not satisfied.
413 1.1 The server is refusing access because the request is too large in some way-for example, the client wants to send a data file that is too large for the server. If this is a temporary limitation, the server should include a Retry-after response field to indicate when the client should try again.
414 1.1 The server is refusing access because the URI of the request is too long for the server to process.
415 1.1 The server is refusing access because the client is trying to send data in a MIME type not supported by the server.
416 1.1 The server is refusing access because the client tried to request a range of a resource, but no such range of the resource is available.
417 1.1 The client sent an expect header field, but the server is unable to satisfy the conditions implied by the value of this header field.
422 WD The server understands the type of the data being sent, but is unable to process it (for example, because it contains WebDAV instructions that are not supported or are incorrectly formatted).
423 WD The resource cannot be accessed because it is locked.
424 WD The method could not be performed on the resource because the request depended on another action, and that other action failed.
500 1.0 The server has encountered an internal error and cannot continue with the request.
501 1.0 The request made is legal, but the server does not support this method.
502 1.0 The client requested a resource from a server that, in turn, attempted to access the resource from another server or gateway. In this case, the secondary server or gateway did not return a valid response to the server.
503 1.0 The service is unavailable because the server is too busy. The server may also send a Retry-After: header, which tells the client how long to wait before trying again.
504 1.0 The client requested a resource from a server that, in turn, attempted to access the resource from another server or gateway. This is similar to 502, except that in this case, the transaction failed because the secondary server or gateway took too long to respond.
505 1.1 The server does not support the HTTP protocol version in which the request was posed.
506 CN The 506 status code indicates that the server has an internal configuration error: The chosen variant resource is configured to engage in transparent content negotiation itself, and is, therefore, not a proper end point in the negotiation process.
507 WD The request failed because the server had insufficient storage space to proceed with the transaction.

*In this column, 1.0 means HTTP 1.0 (RFC 1945), 1.1 means HTTP 1.1 (RFC 2617), CN means transparent content negotiation (RFC 2295), and WD means WebDAV (RFC 2518).

Back to top

D.8 References

www.ietf.org/rfc/rfc1945.txt HTTP 1.0
www.ietf.org/rfc/rfc2109.txt HTTP state management (cookies)
www.ietf.org/rfc/rfc2295.txt HTTP transparent content negotiation
www.ietf.org/rfc/rfc2518.txt WebDAV extensions to HTTP
www.ietf.org/rfc/rfc2616.txt HTTP 1.1
www.ietf.org/rfc/rfc2617.txt HTTP Basic and Digest authentication
www.ietf.org/rfc/rfc2774.txt Experimental HTTP extension framework

Back to top

The XHTML Web Development Sourcebook © 1995-2000 by Ian S. Graham