RFC 1945
Hypertext Transfer Protocol -- HTTP/1.0
4. HTTP Message 4.1 Message Types HTTP messages consist of requests from client to server and responses from server to client. HTTP-message = Simple-Request ; HTTP/0.9 messages | Simple-Response | Full-Request ; HTTP/1.0 messages | Full-Response Full-Request and Full-Response use the generic message format of RFC 822 [7] for transferring entities. Both messages may include optional header fields (also known as "headers") and an entity body. The entity body is separated from the headers by a null line (i.e., a line with nothing preceding the CRLF). Full-Request = Request-Line ; Section 5.1 *( General-Header ; Section 4.3 | Request-Header ; Section 5.2 | Entity-Header ) ; Section 7.1 CRLF [ Entity-Body ] ; Section 7.2 Full-Response = Status-Line ; Section 6.1 *( General-Header ; Section 4.3 | Response-Header ; Section 6.2
| Entity-Header ) ; Section 7.1
CRLF
[ Entity-Body ] ; Section 7.2
Simple-Request and Simple-Response do not allow the use of any header
information and are limited to a single request method (GET).
Simple-Request = "GET" SP Request-URI CRLF
Simple-Response = [ Entity-Body ]
Use of the Simple-Request format is discouraged because it prevents
the server from identifying the media type of the returned entity.
4.2 Message Headers
HTTP header fields, which include General-Header (Section 4.3),
Request-Header (Section 5.2), Response-Header (Section 6.2), and
Entity-Header (Section 7.1) fields, follow the same generic format as
that given in Section 3.1 of RFC 822 [7]. Each header field consists
of a name followed immediately by a colon (":"), a single space (SP)
character, and the field value. Field names are case-insensitive.
Header fields can be extended over multiple lines by preceding each
extra line with at least one SP or HT, though this is not
recommended.
HTTP-header = field-name ":" [ field-value ] CRLF
field-name = token
field-value = *( field-content | LWS )
field-content = <the OCTETs making up the field-value
and consisting of either *TEXT or combinations
of token, tspecials, and quoted-string>
The order in which header fields are received is not significant.
However, it is "good practice" to send General-Header fields first,
followed by Request-Header or Response-Header fields prior to the
Entity-Header fields.
Multiple HTTP-header fields with the same field-name may be present
in a message if and only if the entire field-value for that header
field is defined as a comma-separated list [i.e., #(values)]. It must
be possible to combine the multiple header fields into one "field-
name: field-value" pair, without changing the semantics of the
message, by appending each subsequent field-value to the first, each
separated by a comma.
4.3 General Header Fields There are a few header fields which have general applicability for both request and response messages, but which do not apply to the entity being transferred. These headers apply only to the message being transmitted. General-Header = Date ; Section 10.6 | Pragma ; Section 10.12 General header field names can be extended reliably only in combination with a change in the protocol version. However, new or experimental header fields may be given the semantics of general header fields if all parties in the communication recognize them to be general header fields. Unrecognized header fields are treated as Entity-Header fields. 5. Request A request message from a client to a server includes, within the first line of that message, the method to be applied to the resource, the identifier of the resource, and the protocol version in use. For backwards compatibility with the more limited HTTP/0.9 protocol, there are two valid formats for an HTTP request: Request = Simple-Request | Full-Request Simple-Request = "GET" SP Request-URI CRLF Full-Request = Request-Line ; Section 5.1 *( General-Header ; Section 4.3 | Request-Header ; Section 5.2 | Entity-Header ) ; Section 7.1 CRLF [ Entity-Body ] ; Section 7.2 If an HTTP/1.0 server receives a Simple-Request, it must respond with an HTTP/0.9 Simple-Response. An HTTP/1.0 client capable of receiving a Full-Response should never generate a Simple-Request. 5.1 Request-Line The Request-Line begins with a method token, followed by the Request-URI and the protocol version, and ending with CRLF. The elements are separated by SP characters. No CR or LF are allowed except in the final CRLF sequence. Request-Line = Method SP Request-URI SP HTTP-Version CRLF
Note that the difference between a Simple-Request and the Request- Line of a Full-Request is the presence of the HTTP-Version field and the availability of methods other than GET. 5.1.1 Method The Method token indicates the method to be performed on the resource identified by the Request-URI. The method is case-sensitive. Method = "GET" ; Section 8.1 | "HEAD" ; Section 8.2 | "POST" ; Section 8.3 | extension-method extension-method = token The list of methods acceptable by a specific resource can change dynamically; the client is notified through the return code of the response if a method is not allowed on a resource. Servers should return the status code 501 (not implemented) if the method is unrecognized or not implemented. The methods commonly used by HTTP/1.0 applications are fully defined in Section 8. 5.1.2 Request-URI The Request-URI is a Uniform Resource Identifier (Section 3.2) and identifies the resource upon which to apply the request. Request-URI = absoluteURI | abs_path The two options for Request-URI are dependent on the nature of the request. The absoluteURI form is only allowed when the request is being made to a proxy. The proxy is requested to forward the request and return the response. If the request is GET or HEAD and a prior response is cached, the proxy may use the cached message if it passes any restrictions in the Expires header field. Note that the proxy may forward the request on to another proxy or directly to the server specified by the absoluteURI. In order to avoid request loops, a proxy must be able to recognize all of its server names, including any aliases, local variations, and the numeric IP address. An example Request-Line would be: GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.0
The most common form of Request-URI is that used to identify a resource on an origin server or gateway. In this case, only the absolute path of the URI is transmitted (see Section 3.2.1, abs_path). For example, a client wishing to retrieve the resource above directly from the origin server would create a TCP connection to port 80 of the host "www.w3.org" and send the line: GET /pub/WWW/TheProject.html HTTP/1.0 followed by the remainder of the Full-Request. Note that the absolute path cannot be empty; if none is present in the original URI, it must be given as "/" (the server root). The Request-URI is transmitted as an encoded string, where some characters may be escaped using the "% HEX HEX" encoding defined by RFC 1738 [4]. The origin server must decode the Request-URI in order to properly interpret the request. 5.2 Request Header Fields The request header fields allow the client to pass additional information about the request, and about the client itself, to the server. These fields act as request modifiers, with semantics equivalent to the parameters on a programming language method (procedure) invocation. Request-Header = Authorization ; Section 10.2 | From ; Section 10.8 | If-Modified-Since ; Section 10.9 | Referer ; Section 10.13 | User-Agent ; Section 10.15 Request-Header field names can be extended reliably only in combination with a change in the protocol version. However, new or experimental header fields may be given the semantics of request header fields if all parties in the communication recognize them to be request header fields. Unrecognized header fields are treated as Entity-Header fields. 6. Response After receiving and interpreting a request message, a server responds in the form of an HTTP response message. Response = Simple-Response | Full-Response Simple-Response = [ Entity-Body ]
Full-Response = Status-Line ; Section 6.1
*( General-Header ; Section 4.3
| Response-Header ; Section 6.2
| Entity-Header ) ; Section 7.1
CRLF
[ Entity-Body ] ; Section 7.2
A Simple-Response should only be sent in response to an HTTP/0.9
Simple-Request or if the server only supports the more limited
HTTP/0.9 protocol. If a client sends an HTTP/1.0 Full-Request and
receives a response that does not begin with a Status-Line, it should
assume that the response is a Simple-Response and parse it
accordingly. Note that the Simple-Response consists only of the
entity body and is terminated by the server closing the connection.
6.1 Status-Line
The first line of a Full-Response message is the Status-Line,
consisting of the protocol version followed by a numeric status code
and its associated textual phrase, with each element separated by SP
characters. No CR or LF is allowed except in the final CRLF sequence.
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
Since a status line always begins with the protocol version and
status code
"HTTP/" 1*DIGIT "." 1*DIGIT SP 3DIGIT SP
(e.g., "HTTP/1.0 200 "), the presence of that expression is
sufficient to differentiate a Full-Response from a Simple-Response.
Although the Simple-Response format may allow such an expression to
occur at the beginning of an entity body, and thus cause a
misinterpretation of the message if it was given in response to a
Full-Request, most HTTP/0.9 servers are limited to responses of type
"text/html" and therefore would never generate such a response.
6.1.1 Status Code and Reason Phrase
The Status-Code element is a 3-digit integer result code of the
attempt to understand and satisfy the request. The Reason-Phrase is
intended to give a short textual description of the Status-Code. The
Status-Code is intended for use by automata and the Reason-Phrase is
intended for the human user. The client is not required to examine or
display the Reason-Phrase.
The first digit of the Status-Code defines the class of response. The
last two digits do not have any categorization role. There are 5
values for the first digit:
o 1xx: Informational - Not used, but reserved for future use
o 2xx: Success - The action was successfully received,
understood, and accepted.
o 3xx: Redirection - Further action must be taken in order to
complete the request
o 4xx: Client Error - The request contains bad syntax or cannot
be fulfilled
o 5xx: Server Error - The server failed to fulfill an apparently
valid request
The individual values of the numeric status codes defined for
HTTP/1.0, and an example set of corresponding Reason-Phrase's, are
presented below. The reason phrases listed here are only recommended
-- they may be replaced by local equivalents without affecting the
protocol. These codes are fully defined in Section 9.
Status-Code = "200" ; OK
| "201" ; Created
| "202" ; Accepted
| "204" ; No Content
| "301" ; Moved Permanently
| "302" ; Moved Temporarily
| "304" ; Not Modified
| "400" ; Bad Request
| "401" ; Unauthorized
| "403" ; Forbidden
| "404" ; Not Found
| "500" ; Internal Server Error
| "501" ; Not Implemented
| "502" ; Bad Gateway
| "503" ; Service Unavailable
| extension-code
extension-code = 3DIGIT
Reason-Phrase = *<TEXT, excluding CR, LF>
HTTP status codes are extensible, but the above codes are the only
ones generally recognized in current practice. HTTP applications are
not required to understand the meaning of all registered status
codes, though such understanding is obviously desirable. However, applications must understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class, with the exception that an unrecognized response must not be cached. For example, if an unrecognized status code of 431 is received by the client, it can safely assume that there was something wrong with its request and treat the response as if it had received a 400 status code. In such cases, user agents should present to the user the entity returned with the response, since that entity is likely to include human-readable information which will explain the unusual status. 6.2 Response Header Fields The response header fields allow the server to pass additional information about the response which cannot be placed in the Status- Line. These header fields give information about the server and about further access to the resource identified by the Request-URI. Response-Header = Location ; Section 10.11 | Server ; Section 10.14 | WWW-Authenticate ; Section 10.16 Response-Header field names can be extended reliably only in combination with a change in the protocol version. However, new or experimental header fields may be given the semantics of response header fields if all parties in the communication recognize them to be response header fields. Unrecognized header fields are treated as Entity-Header fields. 7. Entity Full-Request and Full-Response messages may transfer an entity within some requests and responses. An entity consists of Entity-Header fields and (usually) an Entity-Body. In this section, both sender and recipient refer to either the client or the server, depending on who sends and who receives the entity.
7.1 Entity Header Fields Entity-Header fields define optional metainformation about the Entity-Body or, if no body is present, about the resource identified by the request. Entity-Header = Allow ; Section 10.1 | Content-Encoding ; Section 10.3 | Content-Length ; Section 10.4 | Content-Type ; Section 10.5 | Expires ; Section 10.7 | Last-Modified ; Section 10.10 | extension-header extension-header = HTTP-header The extension-header mechanism allows additional Entity-Header fields to be defined without changing the protocol, but these fields cannot be assumed to be recognizable by the recipient. Unrecognized header fields should be ignored by the recipient and forwarded by proxies. 7.2 Entity Body The entity body (if any) sent with an HTTP request or response is in a format and encoding defined by the Entity-Header fields. Entity-Body = *OCTET An entity body is included with a request message only when the request method calls for one. The presence of an entity body in a request is signaled by the inclusion of a Content-Length header field in the request message headers. HTTP/1.0 requests containing an entity body must include a valid Content-Length header field. For response messages, whether or not an entity body is included with a message is dependent on both the request method and the response code. All responses to the HEAD request method must not include a body, even though the presence of entity header fields may lead one to believe they do. All 1xx (informational), 204 (no content), and 304 (not modified) responses must not include a body. All other responses must include an entity body or a Content-Length header field defined with a value of zero (0). 7.2.1 Type When an Entity-Body is included with a message, the data type of that body is determined via the header fields Content-Type and Content- Encoding. These define a two-layer, ordered encoding model:
entity-body := Content-Encoding( Content-Type( data ) )
A Content-Type specifies the media type of the underlying data. A
Content-Encoding may be used to indicate any additional content
coding applied to the type, usually for the purpose of data
compression, that is a property of the resource requested. The
default for the content encoding is none (i.e., the identity
function).
Any HTTP/1.0 message containing an entity body should include a
Content-Type header field defining the media type of that body. If
and only if the media type is not given by a Content-Type header, as
is the case for Simple-Response messages, the recipient may attempt
to guess the media type via inspection of its content and/or the name
extension(s) of the URL used to identify the resource. If the media
type remains unknown, the recipient should treat it as type
"application/octet-stream".
7.2.2 Length
When an Entity-Body is included with a message, the length of that
body may be determined in one of two ways. If a Content-Length header
field is present, its value in bytes represents the length of the
Entity-Body. Otherwise, the body length is determined by the closing
of the connection by the server.
Closing the connection cannot be used to indicate the end of a
request body, since it leaves no possibility for the server to send
back a response. Therefore, HTTP/1.0 requests containing an entity
body must include a valid Content-Length header field. If a request
contains an entity body and Content-Length is not specified, and the
server does not recognize or cannot calculate the length from other
fields, then the server should send a 400 (bad request) response.
Note: Some older servers supply an invalid Content-Length when
sending a document that contains server-side includes dynamically
inserted into the data stream. It must be emphasized that this
will not be tolerated by future versions of HTTP. Unless the
client knows that it is receiving a response from a compliant
server, it should not depend on the Content-Length value being
correct.
8. Method Definitions
The set of common methods for HTTP/1.0 is defined below. Although
this set can be expanded, additional methods cannot be assumed to
share the same semantics for separately extended clients and servers.
8.1 GET The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI. If the Request-URI refers to a data-producing process, it is the produced data which shall be returned as the entity in the response and not the source text of the process, unless that text happens to be the output of the process. The semantics of the GET method changes to a "conditional GET" if the request message includes an If-Modified-Since header field. A conditional GET method requests that the identified resource be transferred only if it has been modified since the date given by the If-Modified-Since header, as described in Section 10.9. The conditional GET method is intended to reduce network usage by allowing cached entities to be refreshed without requiring multiple requests or transferring unnecessary data. 8.2 HEAD The HEAD method is identical to GET except that the server must not return any Entity-Body in the response. The metainformation contained in the HTTP headers in response to a HEAD request should be identical to the information sent in response to a GET request. This method can be used for obtaining metainformation about the resource identified by the Request-URI without transferring the Entity-Body itself. This method is often used for testing hypertext links for validity, accessibility, and recent modification. There is no "conditional HEAD" request analogous to the conditional GET. If an If-Modified-Since header field is included with a HEAD request, it should be ignored. 8.3 POST The POST method is used to request that the destination server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the following functions: o Annotation of existing resources; o Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles; o Providing a block of data, such as the result of submitting a form [3], to a data-handling process; o Extending a database through an append operation.
The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI. The posted entity is subordinate to that URI in the same way that a file is subordinate to a directory containing it, a news article is subordinate to a newsgroup to which it is posted, or a record is subordinate to a database. A successful POST does not require that the entity be created as a resource on the origin server or made accessible for future reference. That is, the action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 200 (ok) or 204 (no content) is the appropriate response status, depending on whether or not the response includes an entity that describes the result. If a resource has been created on the origin server, the response should be 201 (created) and contain an entity (preferably of type "text/html") which describes the status of the request and refers to the new resource. A valid Content-Length is required on all HTTP/1.0 POST requests. An HTTP/1.0 server should respond with a 400 (bad request) message if it cannot determine the length of the request message's content. Applications must not cache responses to a POST request because the application has no way of knowing that the server would return an equivalent response on some future request. 9. Status Code Definitions Each Status-Code is described below, including a description of which method(s) it can follow and any metainformation required in the response. 9.1 Informational 1xx This class of status code indicates a provisional response, consisting only of the Status-Line and optional headers, and is terminated by an empty line. HTTP/1.0 does not define any 1xx status codes and they are not a valid response to a HTTP/1.0 request. However, they may be useful for experimental applications which are outside the scope of this specification. 9.2 Successful 2xx This class of status code indicates that the client's request was successfully received, understood, and accepted.
200 OK
The request has succeeded. The information returned with the
response is dependent on the method used in the request, as follows:
GET an entity corresponding to the requested resource is sent
in the response;
HEAD the response must only contain the header information and
no Entity-Body;
POST an entity describing or containing the result of the action.
201 Created
The request has been fulfilled and resulted in a new resource being
created. The newly created resource can be referenced by the URI(s)
returned in the entity of the response. The origin server should
create the resource before using this Status-Code. If the action
cannot be carried out immediately, the server must include in the
response body a description of when the resource will be available;
otherwise, the server should respond with 202 (accepted).
Of the methods defined by this specification, only POST can create a
resource.
202 Accepted
The request has been accepted for processing, but the processing
has not been completed. The request may or may not eventually be
acted upon, as it may be disallowed when processing actually takes
place. There is no facility for re-sending a status code from an
asynchronous operation such as this.
The 202 response is intentionally non-committal. Its purpose is to
allow a server to accept a request for some other process (perhaps
a batch-oriented process that is only run once per day) without
requiring that the user agent's connection to the server persist
until the process is completed. The entity returned with this
response should include an indication of the request's current
status and either a pointer to a status monitor or some estimate of
when the user can expect the request to be fulfilled.
204 No Content
The server has fulfilled the request but there is no new
information to send back. If the client is a user agent, it should
not change its document view from that which caused the request to
be generated. This response is primarily intended to allow input for scripts or other actions to take place without causing a change to the user agent's active document view. The response may include new metainformation in the form of entity headers, which should apply to the document currently in the user agent's active view. 9.3 Redirection 3xx This class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request. The action required may be carried out by the user agent without interaction with the user if and only if the method used in the subsequent request is GET or HEAD. A user agent should never automatically redirect a request more than 5 times, since such redirections usually indicate an infinite loop. 300 Multiple Choices This response code is not directly used by HTTP/1.0 applications, but serves as the default for interpreting the 3xx class of responses. The requested resource is available at one or more locations. Unless it was a HEAD request, the response should include an entity containing a list of resource characteristics and locations from which the user or user agent can choose the one most appropriate. If the server has a preferred choice, it should include the URL in a Location field; user agents may use this field value for automatic redirection. 301 Moved Permanently The requested resource has been assigned a new permanent URL and any future references to this resource should be done using that URL. Clients with link editing capabilities should automatically relink references to the Request-URI to the new reference returned by the server, where possible. The new URL must be given by the Location field in the response. Unless it was a HEAD request, the Entity-Body of the response should contain a short note with a hyperlink to the new URL. If the 301 status code is received in response to a request using the POST method, the user agent must not automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.
Note: When automatically redirecting a POST request after
receiving a 301 status code, some existing user agents will
erroneously change it into a GET request.
302 Moved Temporarily
The requested resource resides temporarily under a different URL.
Since the redirection may be altered on occasion, the client should
continue to use the Request-URI for future requests.
The URL must be given by the Location field in the response. Unless
it was a HEAD request, the Entity-Body of the response should
contain a short note with a hyperlink to the new URI(s).
If the 302 status code is received in response to a request using
the POST method, the user agent must not automatically redirect the
request unless it can be confirmed by the user, since this might
change the conditions under which the request was issued.
Note: When automatically redirecting a POST request after
receiving a 302 status code, some existing user agents will
erroneously change it into a GET request.
304 Not Modified
If the client has performed a conditional GET request and access is
allowed, but the document has not been modified since the date and
time specified in the If-Modified-Since field, the server must
respond with this status code and not send an Entity-Body to the
client. Header fields contained in the response should only include
information which is relevant to cache managers or which may have
changed independently of the entity's Last-Modified date. Examples
of relevant header fields include: Date, Server, and Expires. A
cache should update its cached entity to reflect any new field
values given in the 304 response.
9.4 Client Error 4xx
The 4xx class of status code is intended for cases in which the
client seems to have erred. If the client has not completed the
request when a 4xx code is received, it should immediately cease
sending data to the server. Except when responding to a HEAD request,
the server should include an entity containing an explanation of the
error situation, and whether it is a temporary or permanent
condition. These status codes are applicable to any request method.
Note: If the client is sending data, server implementations on TCP
should be careful to ensure that the client acknowledges receipt
of the packet(s) containing the response prior to closing the
input connection. If the client continues sending data to the
server after the close, the server's controller will send a reset
packet to the client, which may erase the client's unacknowledged
input buffers before they can be read and interpreted by the HTTP
application.
400 Bad Request
The request could not be understood by the server due to malformed
syntax. The client should not repeat the request without
modifications.
401 Unauthorized
The request requires user authentication. The response must include
a WWW-Authenticate header field (Section 10.16) containing a
challenge applicable to the requested resource. The client may
repeat the request with a suitable Authorization header field
(Section 10.2). If the request already included Authorization
credentials, then the 401 response indicates that authorization has
been refused for those credentials. If the 401 response contains
the same challenge as the prior response, and the user agent has
already attempted authentication at least once, then the user
should be presented the entity that was given in the response,
since that entity may include relevant diagnostic information. HTTP
access authentication is explained in Section 11.
403 Forbidden
The server understood the request, but is refusing to fulfill it.
Authorization will not help and the request should not be repeated.
If the request method was not HEAD and the server wishes to make
public why the request has not been fulfilled, it should describe
the reason for the refusal in the entity body. This status code is
commonly used when the server does not wish to reveal exactly why
the request has been refused, or when no other response is
applicable.
404 Not Found
The server has not found anything matching the Request-URI. No
indication is given of whether the condition is temporary or
permanent. If the server does not wish to make this information
available to the client, the status code 403 (forbidden) can be
used instead.
9.5 Server Error 5xx Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable of performing the request. If the client has not completed the request when a 5xx code is received, it should immediately cease sending data to the server. Except when responding to a HEAD request, the server should include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. These response codes are applicable to any request method and there are no required header fields. 500 Internal Server Error The server encountered an unexpected condition which prevented it from fulfilling the request. 501 Not Implemented The server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource. 502 Bad Gateway The server, while acting as a gateway or proxy, received an invalid response from the upstream server it accessed in attempting to fulfill the request. 503 Service Unavailable The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay. Note: The existence of the 503 status code does not imply that a server must use it when becoming overloaded. Some servers may wish to simply refuse the connection. 10. Header Field Definitions This section defines the syntax and semantics of all commonly used HTTP/1.0 header fields. For general and entity header fields, both sender and recipient refer to either the client or the server, depending on who sends and who receives the message.
10.1 Allow The Allow entity-header field lists the set of methods supported by the resource identified by the Request-URI. The purpose of this field is strictly to inform the recipient of valid methods associated with the resource. The Allow header field is not permitted in a request using the POST method, and thus should be ignored if it is received as part of a POST entity. Allow = "Allow" ":" 1#method Example of use: Allow: GET, HEAD This field cannot prevent a client from trying other methods. However, the indications given by the Allow header field value should be followed. The actual set of allowed methods is defined by the origin server at the time of each request. A proxy must not modify the Allow header field even if it does not understand all the methods specified, since the user agent may have other means of communicating with the origin server. The Allow header field does not indicate what methods are implemented by the server. 10.2 Authorization A user agent that wishes to authenticate itself with a server-- usually, but not necessarily, after receiving a 401 response--may do so by including an Authorization request-header field with the request. The Authorization field value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested. Authorization = "Authorization" ":" credentials HTTP access authentication is described in Section 11. If a request is authenticated and a realm specified, the same credentials should be valid for all other requests within this realm. Responses to requests containing an Authorization field are not cachable.
10.3 Content-Encoding The Content-Encoding entity-header field is used as a modifier to the media-type. When present, its value indicates what additional content coding has been applied to the resource, and thus what decoding mechanism must be applied in order to obtain the media-type referenced by the Content-Type header field. The Content-Encoding is primarily used to allow a document to be compressed without losing the identity of its underlying media type. Content-Encoding = "Content-Encoding" ":" content-coding Content codings are defined in Section 3.5. An example of its use is Content-Encoding: x-gzip The Content-Encoding is a characteristic of the resource identified by the Request-URI. Typically, the resource is stored with this encoding and is only decoded before rendering or analogous usage. 10.4 Content-Length The Content-Length entity-header field indicates the size of the Entity-Body, in decimal number of octets, sent to the recipient or, in the case of the HEAD method, the size of the Entity-Body that would have been sent had the request been a GET. Content-Length = "Content-Length" ":" 1*DIGIT An example is Content-Length: 3495 Applications should use this field to indicate the size of the Entity-Body to be transferred, regardless of the media type of the entity. A valid Content-Length field value is required on all HTTP/1.0 request messages containing an entity body. Any Content-Length greater than or equal to zero is a valid value. Section 7.2.2 describes how to determine the length of a response entity body if a Content-Length is not given. Note: The meaning of this field is significantly different from the corresponding definition in MIME, where it is an optional field used within the "message/external-body" content-type. In HTTP, it should be used whenever the entity's length can be determined prior to being transferred.
10.5 Content-Type The Content-Type entity-header field indicates the media type of the Entity-Body sent to the recipient or, in the case of the HEAD method, the media type that would have been sent had the request been a GET. Content-Type = "Content-Type" ":" media-type Media types are defined in Section 3.6. An example of the field is Content-Type: text/html Further discussion of methods for identifying the media type of an entity is provided in Section 7.2.1. 10.6 Date The Date general-header field represents the date and time at which the message was originated, having the same semantics as orig-date in RFC 822. The field value is an HTTP-date, as described in Section 3.3. Date = "Date" ":" HTTP-date An example is Date: Tue, 15 Nov 1994 08:12:31 GMT If a message is received via direct connection with the user agent (in the case of requests) or the origin server (in the case of responses), then the date can be assumed to be the current date at the receiving end. However, since the date--as it is believed by the origin--is important for evaluating cached responses, origin servers should always include a Date header. Clients should only send a Date header field in messages that include an entity body, as in the case of the POST request, and even then it is optional. A received message which does not have a Date header field should be assigned one by the recipient if the message will be cached by that recipient or gatewayed via a protocol which requires a Date. In theory, the date should represent the moment just before the entity is generated. In practice, the date can be generated at any time during the message origination without affecting its semantic value. Note: An earlier version of this document incorrectly specified that this field should contain the creation date of the enclosed Entity-Body. This has been changed to reflect actual (and proper)
usage.
10.7 Expires
The Expires entity-header field gives the date/time after which the
entity should be considered stale. This allows information providers
to suggest the volatility of the resource, or a date after which the
information may no longer be valid. Applications must not cache this
entity beyond the date given. The presence of an Expires field does
not imply that the original resource will change or cease to exist
at, before, or after that time. However, information providers that
know or even suspect that a resource will change by a certain date
should include an Expires header with that date. The format is an
absolute date and time as defined by HTTP-date in Section 3.3.
Expires = "Expires" ":" HTTP-date
An example of its use is
Expires: Thu, 01 Dec 1994 16:00:00 GMT
If the date given is equal to or earlier than the value of the Date
header, the recipient must not cache the enclosed entity. If a
resource is dynamic by nature, as is the case with many data-
producing processes, entities from that resource should be given an
appropriate Expires value which reflects that dynamism.
The Expires field cannot be used to force a user agent to refresh its
display or reload a resource; its semantics apply only to caching
mechanisms, and such mechanisms need only check a resource's
expiration status when a new request for that resource is initiated.
User agents often have history mechanisms, such as "Back" buttons and
history lists, which can be used to redisplay an entity retrieved
earlier in a session. By default, the Expires field does not apply to
history mechanisms. If the entity is still in storage, a history
mechanism should display it even if the entity has expired, unless
the user has specifically configured the agent to refresh expired
history documents.
Note: Applications are encouraged to be tolerant of bad or
misinformed implementations of the Expires header. A value of zero
(0) or an invalid date format should be considered equivalent to
an "expires immediately." Although these values are not legitimate
for HTTP/1.0, a robust implementation is always desirable.
10.8 From The From request-header field, if given, should contain an Internet e-mail address for the human user who controls the requesting user agent. The address should be machine-usable, as defined by mailbox in RFC 822 [7] (as updated by RFC 1123 [6]): From = "From" ":" mailbox An example is: From: webmaster@w3.org This header field may be used for logging purposes and as a means for identifying the source of invalid or unwanted requests. It should not be used as an insecure form of access protection. The interpretation of this field is that the request is being performed on behalf of the person given, who accepts responsibility for the method performed. In particular, robot agents should include this header so that the person responsible for running the robot can be contacted if problems occur on the receiving end. The Internet e-mail address in this field may be separate from the Internet host which issued the request. For example, when a request is passed through a proxy, the original issuer's address should be used. Note: The client should not send the From header field without the user's approval, as it may conflict with the user's privacy interests or their site's security policy. It is strongly recommended that the user be able to disable, enable, and modify the value of this field at any time prior to a request. 10.9 If-Modified-Since The If-Modified-Since request-header field is used with the GET method to make it conditional: if the requested resource has not been modified since the time specified in this field, a copy of the resource will not be returned from the server; instead, a 304 (not modified) response will be returned without any Entity-Body. If-Modified-Since = "If-Modified-Since" ":" HTTP-date An example of the field is: If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
A conditional GET method requests that the identified resource be
transferred only if it has been modified since the date given by the
If-Modified-Since header. The algorithm for determining this includes
the following cases:
a) If the request would normally result in anything other than
a 200 (ok) status, or if the passed If-Modified-Since date
is invalid, the response is exactly the same as for a
normal GET. A date which is later than the server's current
time is invalid.
b) If the resource has been modified since the
If-Modified-Since date, the response is exactly the same as
for a normal GET.
c) If the resource has not been modified since a valid
If-Modified-Since date, the server shall return a 304 (not
modified) response.
The purpose of this feature is to allow efficient updates of cached
information with a minimum amount of transaction overhead.
10.10 Last-Modified
The Last-Modified entity-header field indicates the date and time at
which the sender believes the resource was last modified. The exact
semantics of this field are defined in terms of how the recipient
should interpret it: if the recipient has a copy of this resource
which is older than the date given by the Last-Modified field, that
copy should be considered stale.
Last-Modified = "Last-Modified" ":" HTTP-date
An example of its use is
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
The exact meaning of this header field depends on the implementation
of the sender and the nature of the original resource. For files, it
may be just the file system last-modified time. For entities with
dynamically included parts, it may be the most recent of the set of
last-modify times for its component parts. For database gateways, it
may be the last-update timestamp of the record. For virtual objects,
it may be the last time the internal state changed.
An origin server must not send a Last-Modified date which is later
than the server's time of message origination. In such cases, where
the resource's last modification would indicate some time in the
future, the server must replace that date with the message origination date. 10.11 Location The Location response-header field defines the exact location of the resource that was identified by the Request-URI. For 3xx responses, the location must indicate the server's preferred URL for automatic redirection to the resource. Only one absolute URL is allowed. Location = "Location" ":" absoluteURI An example is Location: http://www.w3.org/hypertext/WWW/NewLocation.html 10.12 Pragma The Pragma general-header field is used to include implementation- specific directives that may apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems may require that behavior be consistent with the directives. Pragma = "Pragma" ":" 1#pragma-directive pragma-directive = "no-cache" | extension-pragma extension-pragma = token [ "=" word ] When the "no-cache" directive is present in a request message, an application should forward the request toward the origin server even if it has a cached copy of what is being requested. This allows a client to insist upon receiving an authoritative response to its request. It also allows a client to refresh a cached copy which is known to be corrupted or stale. Pragma directives must be passed through by a proxy or gateway application, regardless of their significance to that application, since the directives may be applicable to all recipients along the request/response chain. It is not possible to specify a pragma for a specific recipient; however, any pragma directive not relevant to a recipient should be ignored by that recipient. 10.13 Referer The Referer request-header field allows the client to specify, for the server's benefit, the address (URI) of the resource from which the Request-URI was obtained. This allows a server to generate lists
of back-links to resources for interest, logging, optimized caching,
etc. It also allows obsolete or mistyped links to be traced for
maintenance. The Referer field must not be sent if the Request-URI
was obtained from a source that does not have its own URI, such as
input from the user keyboard.
Referer = "Referer" ":" ( absoluteURI | relativeURI )
Example:
Referer: http://www.w3.org/hypertext/DataSources/Overview.html
If a partial URI is given, it should be interpreted relative to the
Request-URI. The URI must not include a fragment.
Note: Because the source of a link may be private information or
may reveal an otherwise private information source, it is strongly
recommended that the user be able to select whether or not the
Referer field is sent. For example, a browser client could have a
toggle switch for browsing openly/anonymously, which would
respectively enable/disable the sending of Referer and From
information.
10.14 Server
The Server response-header field contains information about the
software used by the origin server to handle the request. The field
can contain multiple product tokens (Section 3.7) and comments
identifying the server and any significant subproducts. By
convention, the product tokens are listed in order of their
significance for identifying the application.
Server = "Server" ":" 1*( product | comment )
Example:
Server: CERN/3.0 libwww/2.17
If the response is being forwarded through a proxy, the proxy
application must not add its data to the product list.
Note: Revealing the specific software version of the server may
allow the server machine to become more vulnerable to attacks
against software that is known to contain security holes. Server
implementors are encouraged to make this field a configurable
option.
Note: Some existing servers fail to restrict themselves to the
product token syntax within the Server field.
10.15 User-Agent
The User-Agent request-header field contains information about the
user agent originating the request. This is for statistical purposes,
the tracing of protocol violations, and automated recognition of user
agents for the sake of tailoring responses to avoid particular user
agent limitations. Although it is not required, user agents should
include this field with requests. The field can contain multiple
product tokens (Section 3.7) and comments identifying the agent and
any subproducts which form a significant part of the user agent. By
convention, the product tokens are listed in order of their
significance for identifying the application.
User-Agent = "User-Agent" ":" 1*( product | comment )
Example:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Note: Some current proxy applications append their product
information to the list in the User-Agent field. This is not
recommended, since it makes machine interpretation of these
fields ambiguous.
Note: Some existing clients fail to restrict themselves to
the product token syntax within the User-Agent field.
10.16 WWW-Authenticate
The WWW-Authenticate response-header field must be included in 401
(unauthorized) response messages. The field value consists of at
least one challenge that indicates the authentication scheme(s) and
parameters applicable to the Request-URI.
WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge
The HTTP access authentication process is described in Section 11.
User agents must take special care in parsing the WWW-Authenticate
field value if it contains more than one challenge, or if more than
one WWW-Authenticate header field is provided, since the contents of
a challenge may itself contain a comma-separated list of
authentication parameters.
(next page on part 3)
