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.
|
METHOD |
DESCRIPTION |
HTTP 1.0 METHODS |
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. |
HTTP 1.1 METHODS |
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. |
WEBDAV METHODS |
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
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
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 users
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 conditionalif 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 conditionalif 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 conditionalif 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 conditionalif 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
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
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
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 sentsometimes 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
|
CODE |
HTTP VERSION* |
|
INFORMATIONAL TRANSACTIONS |
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. |
SUCCESSFUL TRANSACTIONS |
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. |
206
|
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).
|
REDIRECTION TRANSACTIONS |
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. |
307 |
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. |
CLIENT ERROR MESSAGES |
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. |
SERVER ERROR MESSAGES |
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
|