1 - 2 - 7 - 8 - A - B - C - D - E - F - G - H - I - K - L - M - N - O - P - Q - R - S - T - U - V - W - X
header
Click on the red underlined text to get to the source
... allows an open-ended set of methods and headers that indicate the
purpose of a request [47]. It builds on the discipline of reference
...
... entity consists of metainformation in the form of
entity-header fields and content in the form of an entity-body, as
described in section 7. ...
... cache is semantically transparent, the client
receives exactly the same response (except for hop-by-hop headers)
that it would have received had its request been handled directly
by the origin server. ...
...
HTTP/1.1 header field values can be folded onto multiple lines if the
continuation line begins with a space or horizontal tab. All linear
white space, including folding, has the same semantics ...
...
A CRLF is allowed in the definition of TEXT only as part of a header
field continuation. It is expected that the folding LWS will be
replaced with a single SP before interpretation of the TEXT value.
...
...
Many HTTP/1.1 header field values consist of words separated by LWS
or special characters. These special characters MUST be in a quoted
string to be used within a parameter value ...
...
Comments can be included in some HTTP header fields by surrounding
the comment text with parentheses. Comments are only allowed in
fields containing "comment" as part of their field value definition.
...
... versions of HTTP may involve modification
of header fields required or forbidden by the versions involved.
...
... 1123std3 format for representing HTTP-date values
in header fields. See section 19.3 for further information.
...
...
Some HTTP header fields allow a time value to be specified as an
integer number of seconds, represented in decimal, after the time
...
... Some HTTP/1.0 software has interpreted a Content-Type header without
charset parameter incorrectly to mean "recipient should guess."
...
... Encoding (section 14.3) and
Content-Encoding (section 14.11) header fields. Although the value
describes the content-coding, what is more important is that it
indicates what decoding mechanism will be required to remove ...
... encoding; the use of no transformation
whatsoever. This content-coding is used only in the Accept-
Encoding header, and SHOULD NOT be used in the Content-Encoding
header ...
... HTTP/1.1 uses
transfer-coding values in the TE header field (section 14.39) and in
the Transfer-Encoding header field ...
... transfer it as a series of chunks, each with its own size indicator,
followed by an OPTIONAL trailer containing entity-header fields. This
allows dynamically produced content to be transferred along with the
information necessary for the recipient to verify that it has
...
...
The trailer allows the sender to include additional HTTP header
fields at the end of the message. The Trailer header field can be
used to indicate which header fields ...
... The trailer allows the sender to include additional HTTP header
fields at the end of the message. The Trailer header field can be
used to indicate which header fields are included in a trailer (see
...
... HTTP header
fields at the end of the message. The Trailer header field can be
used to indicate which header fields are included in a trailer (see
section 14.40).
...
...
A server using chunked transfer-coding in a response MUST NOT use the
trailer for any header fields unless at least one of the following is
true:
...
...
a)the request included a TE header field that indicates "trailers" is
acceptable in the transfer-coding of the response, as described in
section 14.39; or,
...
... 17] in the Content-Type (section
14.17) and Accept (section 14.1) header fields in order to provide
open and extensible data typing and type negotiation.
...
... CRLF within any of the HTTP control
structures (such as header fields and multipart boundaries).
...
... MIME user agent would upon receipt of a multipart type.
The MIME header fields within each body-part of a multipart message-
body do not have any significance to HTTP beyond that defined by
...
... 14.19), If-Match (section 14.24), If-None-Match (section 14.26), and
If-Range (section 14.27) header fields. The definition of how they
are used and compared as cache validators is in section 13.3.3. An
...
... Range (section 14.35) and Content-Range (section 14.16)
header fields. An entity can be broken down into subranges according
to various structural units.
...
... of the message). Both types of message consist of a start-line, zero
or more header fields (also known as "headers"), an empty line (i.e.,
a line with nothing preceding the CRLF ...
... start-line, zero
or more header fields (also known as "headers"), an empty line (i.e.,
a line with nothing preceding the CRLF) indicating the end of the
...
... a line with nothing preceding the CRLF) indicating the end of the
header fields, and possibly a message-body.
...
... message-header ...
... Message Headers ...
...
HTTP header fields, which include general-header (section 4.5),
request-header (section 5.3), response-header ...
... HTTP header fields, which include general-header (section 4.5),
request-header (section 5.3), response-header (section 6.2), and
entity ...
... header (section 4.5),
request-header (section 5.3), response-header (section 6.2), and
entity-header ...
... 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 822std11(-> 2822prop) [9 ...
... that given in Section 3.1 of RFC 822std11(-> 2822prop) [9]. Each header field consists
of a name followed by a colon (":") and the field value. Field names
are case-insensitive ...
... case-insensitive. The field value MAY be preceded by any amount
of LWS, though a single SP is preferred. Header fields can be
extended over multiple lines by preceding each extra line with at
least one SP ...
...
The order in which header fields with differing field names are
received is not significant. However, it is "good practice" to send
general-header fields ...
... header fields with differing field names are
received is not significant. However, it is "good practice" to send
general-header fields first, followed by request-header or response-
header fields ...
... received is not significant. However, it is "good practice" to send
general-header fields first, followed by request-header or response-
header fields, and ending with the entity ...
... header fields first, followed by request-header or response-
header fields, and ending with the entity-header fields.
...
...
Multiple message-header fields with the same field-name MAY be
present in a message if and only if the entire field-value for that
...
... 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
...
... 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 ...
... semantics of the
message, by appending each subsequent field-value to the first, each
separated by a comma. The order in which header fields with the same
field-name are received is therefore significant to the
...
... entity-body only when a transfer-coding has been
applied, as indicated by the Transfer-Encoding header field (section
14.41).
...
... inclusion of a Content-Length or Transfer-Encoding header field in
the request's message-headers. A message-body ...
... Transfer-Encoding header field in
the request's message-headers. A message-body MUST NOT be included in
a request if the specification of the request method ...
... message-body, even though the presence of entity-
header fields might lead one to believe they do. All 1xx
(informational), 204 (no content), and 304 (not modified) responses
MUST NOT include a message-body ...
... as the 1xx, 204, and 304 responses and any response to a HEAD
request) is always terminated by the first empty line after the
header fields, regardless of the entity-header fields present in
...
... If a Transfer-Encoding header field (section 14.41) is present and
has any value other than "identity", then the transfer-length is
...
... If a Content-Length header field (section 14.13) is present, its
decimal value in OCTETs represents both the entity-length and the
...
... entity-length and the
transfer-length. The Content-Length header field MUST NOT be sent
if these two lengths are different (i.e., if a Transfer-Encoding
...
... if these two lengths are different (i.e., if a Transfer-Encoding
header field is present). If a message is received with both a
Transfer-Encoding header field ...
... header field is present). If a message is received with both a
Transfer-Encoding header field and a Content-Length header field,
...
... Transfer-Encoding header field and a Content-Length header field,
the latter MUST be ignored. ...
... sender knows that the recipient can arse
it; the presence in a request of a Range header with ultiple byte-
range specifiers from a 1.1 client ...
... A range header might be forwarded by a 1.0 proxy that does not
understand multipart/byteranges; in this case the server MUST
...
... message-body MUST include a valid Content-Length header
field unless the server is known to be HTTP/1.1 compliant. If a
request contains a message-body ...
...
Messages MUST NOT include both a Content-Length header field and a
non-identity transfer-coding. If the message does include a non-
...
... 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
...
... request and response messages, but which do not apply to the
entity being transferred. These header fields apply only to the
message being transmitted. ...
...
General-header field names can be extended reliably only in
combination with a change in the protocol version. However, new or
...
... version. However, new or
experimental header fields may be given the semantics of general
header fields ...
... 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 ...
... header fields if all parties in the communication recognize them to
be general-header fields. Unrecognized header fields are treated as
entity ...
... header fields if all parties in the communication recognize them to
be general-header fields. Unrecognized header fields are treated as
entity-header fields ...
... general-header ...
... request-header ...
... The list of methods allowed by a resource can be specified in an
Allow header field (section 14.7). The return code of the response
always notifies the client ...
... authority) MUST
be transmitted in a Host header field. For example, a client wishing
to retrieve the resource above directly from the origin server would
...
... requested host MAY ignore the Host header field value when
determining the resource identified by an HTTP/1.1 request. (But see
...
... Request-URI is not an absoluteURI, and the request includes
a Host header field, the host is determined by the Host header
field ...
... Recipients of an HTTP/1.0 request that lacks a Host header field MAY
attempt to use heuristics (e.g., examination of the URI ...
... Request Header Fields ...
...
The request-header fields allow the client to pass additional
information about the request, and about the client ...
...
Request-header field names can be extended reliably only in
combination with a change in the protocol version. However, new or
...
... version. However, new or
experimental header fields MAY be given the semantics of request-
header fields ...
... 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 ...
... header fields if all parties in the communication recognize them to
be request-header fields. Unrecognized header fields are treated as
entity ...
... header fields if all parties in the communication recognize them to
be request-header fields. Unrecognized header fields are treated as
entity-header fields ...
... general-header ...
... response-header ...
... 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 ...
... 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 field names can be extended reliably only in
combination with a change in the protocol version. However, new or
...
... version. However, new or
experimental header fields MAY be given the semantics of response-
header fields ...
... 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 ...
... header fields if all parties in the communication recognize them to
be response-header fields. Unrecognized header fields are treated as
entity ...
... header fields if all parties in the communication recognize them to
be response-header fields. Unrecognized header fields are treated as
entity-header fields ...
... entity
consists of entity-header fields and an entity-body, although some
responses will only include the entity ...
... Entity Header Fields ...
...
Entity-header fields define metainformation about the entity-body or,
if no body is present, about the resource identified by the request.
...
... extension-header ...
... message-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 ...
... 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 MUST be forwarded by
transparent proxies.
...
... entity-body is included with a message, the data type of that
body is determined via the header fields Content-Type and Content-
Encoding ...
... entity-body SHOULD include a
Content-Type header field defining the media type of that body. If
and only if the media type ...
... signaling takes
place using the Connection header field (section 14.10). Once a close
has been signaled, the client MUST NOT send any more requests on that
...
... connection immediately after sending the
response, it SHOULD send a Connection header including the
connection-token ...
... decide to keep it open based on whether the response from a server
contains a Connection header with the connection-token close. In case
...
... connection for more than that
request, it SHOULD send a Connection header including the
connection-token ...
... proxies correctly implement the
properties of the Connection header field as specified in section
14.10.
...
... empty trailer MAY be used to prematurely mark the end of the message.
If the body was preceded by a Content-Length header, the client MUST
close the connection ...
... request message with a request body
to determine if the origin server is willing to accept the request
(based on the request headers) before the client sends the request
body. In some cases, it might either be inappropriate or highly
...
... If a client will wait for a 100 (Continue) response before
sending the request body, it MUST send an Expect request-header
field (section 14.20) with the "100-continue" expectation. ...
... A client MUST NOT send an Expect request-header field (section
14.20) with the "100-continue" expectation if it does not intend
to send a request body. ...
... or a 100 (Continue) status. Therefore, when a client sends this
header field to an origin server (possibly via a proxy) from which it
has never seen a 100 (Continue) status, the client ...
... Upon receiving a request which includes an Expect request-header
field with the "100-continue" expectation, an origin server MUST
either respond with 100 (Continue) status and continue to read
...
... An origin server SHOULD NOT send a 100 (Continue) response if
the request message does not include an Expect request-header
field with the "100-continue" expectation, and MUST NOT send a
100 (Continue) response if such a request comes from an HTTP/1.0 ...
... status in response to an HTTP/1.1 PUT or POST request that does
not include an Expect request-header field with the "100-
continue" expectation. This exception, the purpose of which is
to minimize any client ...
... If an origin server receives a request that does not include an
Expect request-header field with the "100-continue" expectation,
the request includes a request body, and the server responds
with a final status code ...
... If a proxy receives a request that includes an Expect request-
header field with the "100-continue" expectation, and the proxy
either knows that the next-hop ...
... version of the next-hop
server, it MUST forward the request, including the Expect header
field. ...
... HTTP/1.0 (or earlier)
client and did not include an Expect request-header field with
the "100-continue" expectation. This requirement overrides the
...
... HTTP/1.1 client sends a request which includes a request body,
but which does not include an Expect request-header field with the
"100-continue" expectation, and if the client is not directly
...
... Transmit the request-headers ...
...
A 200 response SHOULD include any header fields that indicate
optional features implemented by the server and applicable to that
...
... request message includes an If-Modified-Since, If-Unmodified-Since,
If-Match, If-None-Match, or If-Range header field. A conditional GET
method requests that the entity be transferred only under the
...
... GET
method requests that the entity be transferred only under the
circumstances described by the conditional header field(s). The
conditional GET method is intended to reduce unnecessary network ...
... request message includes a Range header field. A partial GET requests
that only part of the entity be transferred, as described in section
...
... return a message-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 ...
... entity which describes the
status of the request and refers to the new resource, and a Location
header (see section 14.30).
...
... method are not cacheable, unless the response
includes appropriate Cache-Control or Expires header fields. However,
the 303 (See Other) response can be used to direct the user agent to
...
... entity MUST NOT ignore any Content-*
(e.g. Content-Range) headers that it does not understand or implement
and MUST return a 501 (Not Implemented) response in such cases.
...
... header, the
entity-headers in the PUT request SHOULD be applied to the resource
created or modified by the PUT.
...
... client to see what is being received at the other
end of the request chain and use that data for testing or diagnostic
information. The value of the Via header field (section 14.45) is of
particular interest, since it acts as a trace of the request chain.
...
... particular interest, since it acts as a trace of the request chain.
Use of the Max-Forwards header field allows the client to limit the
length of the request chain, which is useful for testing a chain of
...
... class of status code indicates a provisional response,
consisting only of the Status-Line and optional headers, and is
terminated by an empty line. There are no required headers for this
...
... consisting only of the Status-Line and optional headers, and is
terminated by an empty line. There are no required headers for this
class of status code ...
... The server understands and is willing to comply with the client's
request, via the Upgrade message header field (section 14.42), for a
change in the application protocol being used on this connection ...
... server will switch protocols to those defined by the response's
Upgrade header field immediately after the empty line which
terminates the 101 response. ...
... the entity-header fields corresponding to the requested
resource are sent in the response without any message-body; ...
... entity of the response, with the most specific URI
for the resource given by a Location header field. ...
... the media type given in the Content-Type header field. The origin
server MUST create the resource before returning the 201 status code ...
...
A 201 response MAY contain an ETag response header field indicating
the current value of the entity tag ...
... The returned metainformation in the entity-header is not the
definitive set as available from the origin server, but is gathered
from a local or a third-party ...
... response MAY include new or updated metainformation in the form of
entity-headers, which if present SHOULD be associated with the
requested variant. ...
... The 204 response MUST NOT include a message-body, and thus is always
terminated by the first empty line after the header fields.
...
... The server has fulfilled the partial GET request for the resource.
The request MUST have included a Range header field (section 14.35)
indicating the desired range, and MAY have included an If-Range ...
... range, and MAY have included an If-Range
header field (section 14.27) to make the request conditional. ...
...
The response MUST include the following header fields:
...
... Either a Content-Range header field (section 14.16) indicating
the range included with this response, or a multipart/byteranges
...
... Range fields for each part. If a
Content-Length header field is present in the response, its
value MUST match the actual number of OCTETs transmitted in the
message-body ...
... ETag and/or Content-Location, if the header would have been sent
in a 200 response to the same request ...
... cache validator (see section 13.3.3), the response SHOULD NOT
include other entity-headers. If the response is the result of an
If-Range request that used a weak validator, the response MUST NOT
...
... Range request that used a weak validator, the response MUST NOT
include other entity-headers; this prevents inconsistencies between
cached entity-bodies and updated headers ...
... headers; this prevents inconsistencies between
cached entity-bodies and updated headers. Otherwise, the response
MUST include all of the entity-headers ...
... headers. Otherwise, the response
MUST include all of the entity-headers that would have been returned
with a 200 (OK) response to the same request.
...
... A cache MUST NOT combine a 206 response with other previously cached
content if the ETag or Last-Modified headers do not match exactly,
see 13.5.4.
...
... cache that does not support the Range and Content-Range headers
MUST NOT cache 206 (Partial) responses.
...
... entity format is specified by the media type given in the Content-
Type header field. Depending upon the format and the capabilities of
...
... Request-URI for future requests. This response
is only cacheable if indicated by a Cache-Control or Expires header
field. ...
... message-body, and thus is always terminated by the first empty line
after the header fields. ...
...
The response MUST include the following header fields:
...
... ETag and/or Content-Location, if the header would have been sent
in a 200 response to the same request ...
... cache validator (see section
13.3.3), the response SHOULD NOT include other entity-headers.
Otherwise (i.e., the conditional GET used a weak validator), the
response MUST NOT include other entity ...
... Otherwise (i.e., the conditional GET used a weak validator), the
response MUST NOT include other entity-headers; this prevents
inconsistencies between cached entity-bodies and updated headers ...
... Request-URI for future requests. This response
is only cacheable if indicated by a Cache-Control or Expires header
field. ...
... user authentication. The response MUST include a
WWW-Authenticate header field (section 14.47) containing a challenge
applicable to the requested resource. ...
... client MAY repeat the
request with a suitable Authorization header field (section 14.8). If
the request already included Authorization credentials ...
... resource identified by the Request-URI. The response MUST include an
Allow header containing a list of valid methods for the requested
...
... The resource identified by the request is only capable of generating
response entities which have content characteristics not acceptable
according to the accept headers sent in the request. ...
... media type given
in the Content-Type header field. Depending upon the format and the
capabilities of the user agent, selection of the most appropriate
...
... Note: HTTP/1.1 servers are allowed to return responses which are
not acceptable according to the accept headers sent in the
request. In some cases, this may even be preferable to sending a
406 response. User agents ...
... request. In some cases, this may even be preferable to sending a
406 response. User agents are encouraged to inspect the headers of
an incoming response to determine if it is acceptable.
...
... return a Proxy-Authenticate header field (section 14.33) containing a
challenge applicable to the proxy for the requested resource. ...
... Proxy-Authorization
header field (section 14.34). HTTP access authentication is explained
in "HTTP Authentication ...
... valid
Content-Length header field containing the length of the message-body
in the request message ...
... The precondition given in one or more of the request-header fields
evaluated to false when it was tested on the server. This response
code allows the client ...
... response
code allows the client to place preconditions on the current resource
metainformation (header field data) and thus prevent the requested
method from being applied to a resource other than the one intended. ...
...
If the condition is temporary, the server SHOULD include a Retry-
After header field to indicate that it is temporary and after what
time the client MAY try again.
...
... status code if a request
included a Range request-header field (section 14.35), and none of
the range-specifier values in this field overlap the current extent
...
... of the selected resource, and the request did not include an If-Range
request-header field. (For byte-ranges, this means that the first-
byte-pos of all of the byte-range ...
... response SHOULD include a Content-Range entity-header field
specifying the current length of the selected resource (see section
14.16). This response MUST NOT use the multipart/byteranges content-
...
... The expectation given in an Expect request-header field (see section
14.20) could not be met by this server, or, if the server is a proxy,
...
... some delay. If known, the length of the delay MAY be indicated in a
Retry-After header. If no Retry-After is given, the client SHOULD
...
... the response (the dimensions over which it can vary; e.g. language,
content-coding, etc.) and the contents of particular header fields in
the request message or on other information pertaining to the request
...
... guess" is good enough for the user). In order to improve the server's
guess, the user agent MAY include request header fields (Accept,
Accept-Language, Accept-Encoding ...
...
HTTP/1.1 includes the following request-header fields for enabling
server-driven negotiation through description of user agent ...
... origin server is not limited to these dimensions and MAY vary the
response based on any aspect of the request, including information
outside the request-header fields or within extension header fields
not defined by this specification.
...
... response based on any aspect of the request, including information
outside the request-header fields or within extension header fields
not defined by this specification.
...
...
The Vary header field can be used to express the parameters the
server uses to select a representation that is subject to server-
...
... subject to server-
driven negotiation. See section 13.6 for use of the Vary header field
by caches and section 14.44 for use of the Vary header field ...
... initial response from the origin server. Selection is based on a list
of the available representations of the response included within the
header fields or entity-body of the initial response, with each
representation identified by its own URI ...
... cache
MAY still return the response with the appropriate Warning
header (see section 13.1.5 and 14.46), unless such a response
is prohibited (e.g., by a "no-store" cache-directive, or by a
...
... client without adding a new
Warning (but without removing any existing Warning headers). A cache
SHOULD NOT attempt to revalidate a response simply because that
...
... cache returns a response that is neither first-hand nor
"fresh enough" (in the sense of condition 2 in section 13.1.1), it
MUST attach a warning to that effect, using a Warning general-header.
The Warning header and the currently defined warnings are described
...
... MUST attach a warning to that effect, using a Warning general-header.
The Warning header and the currently defined warnings are described
in section 14.46. The warning allows clients to take appropriate
...
... entity body or entity
headers that is not rectified by a revalidation (for example, a
lossy compression of the entity ...
... language (perhaps based on the client's Accept
headers), and include an OPTIONAL indication of what character set is
used.
...
...
The Cache-Control header allows a client or server to transmit a
variety of directives in either requests or responses. These
...
... directives typically override the default caching algorithms. As a
general rule, if there is any apparent conflict between header
values, the most restrictive interpretation is applied (that is, the
one that is most likely to preserve semantic transparency). However,
...
... connected to the origin server. Whenever a cache returns a stale
response, it MUST mark it as such (using a Warning header) enabling
the client software to alert ...
...
Servers specify explicit expiration times using either the Expires
header, or the max-age directive of the Cache-Control header.
...
... heuristic expiration times, employing
algorithms that use other header values (such as the Last-Modified
time) to estimate a plausible expiration time. The HTTP/1.1
...
...
HTTP/1.1 requires origin servers to send a Date header, if possible,
with every response, giving the time at which the response was
generated (see section 14.18). We use the term "date_value" to denote
...
... with every response, giving the time at which the response was
generated (see section 14.18). We use the term "date_value" to denote
the value of the Date header, in a form appropriate for arithmetic
operations.
...
...
HTTP/1.1 uses the Age response-header to convey the estimated age of
the response message when obtained from a cache ...
...
We use the term "age_value" to denote the value of the Age header, in
a form appropriate for arithmetic operations.
...
... * this response.
* date_value
* is the value of the origin server's Date: header
* request_time
* is the (local) time when the cache ...
... cache entry, the cache MUST include a single Age
header field in the response with a value equal to the cache entry's
current_age.
...
...
The presence of an Age header field in a response implies that a
response is not first-hand. However, the converse is not true, since
the lack of an Age header field ...
... header field in a response implies that a
response is not first-hand. However, the converse is not true, since
the lack of an Age header field in a response does not imply that the
...
...
We use the term "expires_value" to denote the value of the Expires
header. We use the term "max_age_value" to denote an appropriate
value of the number of seconds carried by the "max-age" directive of
the Cache-Control ...
... value of the number of seconds carried by the "max-age" directive of
the Cache-Control header in a response (see section 14.9.3).
...
... for a request that was already fresh in its own cache, and the Date
header in its existing cache entry is newer than the Date on the new
response, then the client ...
... cache has two fresh responses for the same representation with
different validators, it MUST use the one with the more recent Date
header. This situation might arise because the cache is pooling
responses from other caches ...
... client tries to revalidate a cache entry, and the response it
receives contains a Date header that appears to be older than the one
for the existing entry, then the client SHOULD repeat the request
...
... HTTP/1.1, a conditional request looks exactly the same as a normal
request for the same resource, except that it carries a special
header (which includes the validator) that implicitly turns the
method (usually, GET) into a conditional.
...
...
The Last-Modified entity-header field value is often used as a cache
validator. In simple terms, a cache ...
... entity-body or any entity-
headers) changes in any way, then the associated validator would
change as well. If this is true, then we call this validator a
"strong validator."
...
... A "use" of a validator is either when a client generates a request
and includes the validator in a validating header field, or when a
server compares two validators.
...
... The validator is about to be used by a client in an If-
Modified-Since or If-Unmodified-Since header, because the client
has a cache ...
... unless the risk of a breakdown in semantic transparency that
could result from using this date in an If-Modified-Since header
would lead to serious problems. ...
... receiving a conditional request that
includes both a Last-Modified date (e.g., in an If-Modified-Since or
If-Unmodified-Since header field) and one or more entity tags (e.g.,
...
... tags (e.g.,
in an If-Match, If-None-Match, or If-Range header field) as cache
validators, MUST NOT return a response status of 304 (Not Modified)
...
... cache
validators, MUST NOT return a response status of 304 (Not Modified)
unless doing so is consistent with all of the conditional header
fields in the request.
...
... client unless that cached response is consistent with all of the
conditional header fields in the request.
...
... validator comparison function more complex than byte-equality would
open up a can of worms. Thus, comparisons of any other headers
(except Last-Modified, for compatibility with HTTP/1.0 ...
... that such a response was taken from a cache by comparing the Date
header to the current time.
...
... and 307) MUST NOT be returned in a reply to a subsequent request
unless there are cache-control directives or another header(s) that
explicitly allow it. For example, these include the following: an
Expires header ...
... header(s) that
explicitly allow it. For example, these include the following: an
Expires header (section 14.21); a "max-age", "s-maxage", "must-
revalidate", "proxy-revalidate", "public" or "private" cache-control ...
... End-to-end and Hop-by-hop Headers ...
... For the purpose of defining the behavior of caches and non-caching
proxies, we divide HTTP headers into two categories:
...
... End-to-end headers, which are transmitted to the ultimate
recipient of a request or response. End-to-end headers ...
... headers, which are transmitted to the ultimate
recipient of a request or response. End-to-end headers in
responses MUST be stored as part of a cache entry and MUST be
...
... Other hop-by-hop headers MUST be listed in a Connection header,
(section 14.10) to be introduced into HTTP/1.1 (or later).
...
... Non-modifiable Headers ...
... HTTP/1.1 protocol, such as Digest
Authentication, depend on the value of certain end-to-end headers. A
transparent proxy SHOULD NOT modify an end-to-end ...
... transparent proxy SHOULD NOT modify an end-to-end header unless the
definition of that header requires or specifically allows that.
...
... end-to-end header unless the
definition of that header requires or specifically allows that.
...
...
but it MAY add any of these fields if not already present. If an
Expires header is added, it MUST be given a field-value identical to
that of the Date header in that response.
...
... Expires header is added, it MUST be given a field-value identical to
that of the Date header in that response.
...
...
Warning: unnecessary modification of end-to-end headers might
cause authentication failures if stronger authentication ...
... HTTP. Such
authentication mechanisms MAY rely on the values of header fields
not listed here.
...
... Combining Headers ...
... response. If the status code is 206 (Partial Content) and the ETag or
Last-Modified headers match exactly, the cache MAY combine the
contents stored in the cache ...
...
The end-to-end headers stored in the cache entry are used for the
constructed response, except that
...
... any stored Warning headers with warn-code 1xx (see section
14.46) MUST be deleted from the cache ...
... any stored Warning headers with warn-code 2xx MUST be retained
in the cache entry and the forwarded response. ...
... any end-to-end headers provided in the 304 or 206 response MUST
replace the corresponding headers from the cache ...
... end-to-end headers provided in the 304 or 206 response MUST
replace the corresponding headers from the cache entry. ...
... cache entry, it MUST also
replace the end-to-end headers stored with the cache entry with
corresponding headers ...
... headers stored with the cache entry with
corresponding headers received in the incoming response, except for
Warning headers as described immediately above. If a header field ...
... corresponding headers received in the incoming response, except for
Warning headers as described immediately above. If a header field-
name in the incoming response matches more than one header ...
... headers received in the incoming response, except for
Warning headers as described immediately above. If a header field-
name in the incoming response matches more than one header in the
...
... headers as described immediately above. If a header field-
name in the incoming response matches more than one header in the
cache entry, all such old headers ...
...
In other words, the set of end-to-end headers received in the
incoming response overrides all corresponding end-to-end headers ...
... headers received in the
incoming response overrides all corresponding end-to-end headers
stored with the cache entry (except for stored Warning headers ...
... headers
stored with the cache entry (except for stored Warning headers with
warn-code 1xx, which are deleted even if not overridden).
...
... Note: this rule allows an origin server to use a 304 (Not
Modified) or a 206 (Partial Content) response to update any header
associated with a previous response for the same entity or sub-
...
... a 304 (Not Modified) or a 206 (Partial Content) response to
entirely delete a header that it had provided with a previous
response.
...
... Use of server-driven content negotiation (section 12.1), as indicated
by the presence of a Vary header field in a response, alters the
conditions and procedure by which a cache can use the response for
...
... conditions and procedure by which a cache can use the response for
subsequent requests. See section 14.44 for use of the Vary header
field by servers.
...
... header field to inform a cache of what
request-header fields were used to select among multiple
representations of a cacheable response subject to server-driven
...
... subject to server-driven
negotiation. The set of header fields named by the Vary field value
is known as the "selecting" request-headers.
...
... negotiation. The set of header fields named by the Vary field value
is known as the "selecting" request-headers.
...
... Request-URI
specifies one or more cache entries including a Vary header field,
the cache MUST NOT use such a cache ...
... cache MUST NOT use such a cache entry to construct a response to
the new request unless all of the selecting request-headers present
in the new request match the corresponding stored request-headers in
...
... the new request unless all of the selecting request-headers present
in the new request match the corresponding stored request-headers in
the original request.
...
...
The selecting request-headers from two requests are defined to match
if and only if the selecting request-headers in the first request can
...
... The selecting request-headers from two requests are defined to match
if and only if the selecting request-headers in the first request can
be transformed to the selecting request-headers in the second request
...
... if and only if the selecting request-headers in the first request can
be transformed to the selecting request-headers in the second request
by adding or removing linear white space (LWS) at places where this
...
... is allowed by the corresponding BNF, and/or combining multiple
message-header fields with the same field name following the rules
about message headers in section 4.2.
...
... message-header fields with the same field name following the rules
about message headers in section 4.2.
...
...
A Vary header field-value of "*" always fails to match and subsequent
requests on that resource can only be properly interpreted by the
origin server.
...
...
If the selecting request header fields for the cached entry do not
match the selecting request header fields of the new request, then
...
... If the selecting request header fields for the cached entry do not
match the selecting request header fields of the new request, then
the cache MUST NOT use a cached entry to satisfy the request unless
...
... entity tags
in an If-None-Match header field from all its cache entries for the
resource. This conveys to the server the set of entities currently
...
... cache, so that if any one of these entities matches the
requested entity, the server can use the ETag header field in its 304
(Not Modified) response to tell the cache which entry is appropriate.
...
... tag of the new response matches that of an existing
entry, the new response SHOULD be used to update the header fields of
the existing entry, and the result MUST be returned to the client.
...
... entity-tag SHOULD NOT be included in
the If-None-Match header field unless the request is for a range that
would be fully satisfied by that entry.
...
... cache that receives an incomplete response (for example, with fewer
bytes of data than specified in a Content-Length header) MAY store
the response. However, the cache MUST treat this as a partial
...
... Request-URI, or by the Location
or Content-Location headers (if present). These methods are:
...
... on the URI in a Location or Content-Location header MUST only be
performed if the host part is the same as in the Request-URI ...
...
Note: a new response that has an older Date header value than
existing cached responses is not cacheable.
...
... Header Field Definitions ...
... syntax and semantics of all standard
HTTP/1.1 header fields. For entity-header fields, both sender ...
... HTTP/1.1 header fields. For entity-header fields, both sender and
recipient refer to either the client or the server, depending on who
...
...
The Accept request-header field can be used to specify certain media
types which are acceptable for the response. Accept headers can be
...
... The Accept request-header field can be used to specify certain media
types which are acceptable for the response. Accept headers can be
used to indicate that the request is specifically limited to a small
set of desired types, as in the case of a request for an in-line
...
...
If no Accept header field is present, then it is assumed that the
client accepts all media types ...
... client accepts all media types. If an Accept header field is present,
and if the server cannot send a response which is acceptable
according to the combined Accept field value, then the server SHOULD
...
...
The Accept-Charset request-header field can be used to indicate what
character sets are acceptable for the response. This field allows
...
...
If no Accept-Charset header is present, the default is that any
character set is acceptable. If an Accept-Charset ...
... character set is acceptable. If an Accept-Charset header is present,
and if the server cannot send a response which is acceptable
according to the Accept-Charset ...
... and if the server cannot send a response which is acceptable
according to the Accept-Charset header, then the server SHOULD send
an error response with the 406 (not acceptable) status code ...
...
The Accept-Encoding request-header field is similar to Accept, but
restricts the content-codings (section 3.5) that are acceptable in
the response.
...
... The special "*" symbol in an Accept-Encoding field matches any
available content-coding not explicitly listed in the header
field. ...
... Encoding field is present in a request, and if the
server cannot send a response which is acceptable according to the
Accept-Encoding header, then the server SHOULD send an error response
with the 406 (Not Acceptable) status code ...
...
The Accept-Language request-header field is similar to Accept, but
restricts the set of natural languages that are preferred as a
...
... language quality factor
assigned is 0. If no Accept-Language header is present in the
request, the server
SHOULD assume that all languages ...
... languages are equally acceptable. If an
Accept-Language header is present, then all languages which are
assigned a quality factor greater than 0 are acceptable.
...
... privacy expectations of the user to send
an Accept-Language header with the complete linguistic preferences of
the user in every request. For a discussion of this issue, see
...
... preference available to the user. If the choice is not made
available, then the Accept-Language header field MUST NOT be given in
the request.
...
...
The Accept-Ranges response-header field allows the server to
indicate its acceptance of range requests for a resource:
...
... but are not required to do so. Clients MAY generate byte-range
requests without having received this header for the resource
involved. Range units are defined in section 3.12.
...
...
The Age response-header field conveys the sender's estimate of the
amount of time since the response (or its revalidation) was
...
... integer it can represent, or if any of its age calculations
overflows, it MUST transmit an Age header with a value of
2147483648 (2^31). An HTTP/1.1 server that includes a cache ...
... HTTP/1.1 server that includes a cache MUST
include an Age header field in every response generated from its
own cache. Caches ...
...
The Allow entity-header field lists the set of methods supported
by the resource identified by the Request-URI ...
... valid methods
associated with the resource. An Allow header field MUST be
present in a 405 (Method Not Allowed) response.
...
... 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
...
...
The Allow header field MAY be provided with a PUT request to
recommend the methods to be supported by the new or modified
...
... resource. The server is not required to support these methods and
SHOULD include an Allow header in the response giving the actual
supported methods.
...
...
A proxy MUST NOT modify the Allow header field even if it does not
understand all the methods specified, since the user agent ...
... receiving a 401 response--does
so by including an Authorization request-header field with the
request. The Authorization field value consists of credentials ...
... proxy cache MUST first revalidate it with the origin
server, using the request-headers from the new request to allow
the origin server to authenticate the new request. (This is the
...
... caches
MUST first revalidate it with the origin server, using the
request-headers from the new request to allow the origin server
to authenticate the new request. ...
...
The Cache-Control general-header field is used to specify directives
that MUST be obeyed by all caching mechanisms along the
request/response ...
... versions of the HTTP protocol might apply these directives to
header fields not defined in HTTP/1.1.
...
... requirements of the
request method, request header fields, and the response status
indicate that it is cacheable. Section 13.4 summarizes these defaults
for cacheability. The following Cache-Control ...
... subsequent request without successful revalidation with the origin
server. This allows an origin server to prevent the re-use of
certain header fields in a response, while still allowing caching
of the rest of the response.
...
... The expiration time of an entity MAY be specified by the origin
server using the Expires header (see section 14.21). Alternatively,
it MAY be specified using the max-age directive in a response. When
the max-age cache-control ...
...
If a response includes both an Expires header and a max-age
directive, the max-age directive overrides the Expires header, even
...
... If a response includes both an Expires header and a max-age
directive, the max-age directive overrides the Expires header, even
if the Expires header is more restrictive. This rule allows an origin
...
... directive, the max-age directive overrides the Expires header, even
if the Expires header is more restrictive. This rule allows an origin
server to provide, for a given response, a longer expiration time to
an HTTP/1.1 ...
... cache receives such a response, and the response does not include a
Cache-Control header field, it SHOULD consider the response to be
non-cacheable in order to retain compatibility with HTTP/1.0 ...
... cache), the maximum age specified by
this directive overrides the maximum age specified by either the
max-age directive or the Expires header. The s-maxage directive
also implies the semantics of the proxy ...
... cache MAY exploit the
requirement that the max-age directive overrides the Expires header,
and the fact that pre-HTTP/1.1-compliant caches ...
... override the expiration time of a response, the cache MUST attach a
Warning header to the stale response, using Warning 110 (Response is
stale).
...
... intermediate cache or proxy MUST NOT change those headers that are
listed in section 13.5.2 as being subject to the no-transform
...
... proxy MUST NOT change
any aspect of the entity-body that is specified by these headers,
including the value of the entity-body itself.
...
...
The Cache-Control header field can be extended through the use of one
or more cache-extension tokens ...
...
A cache seeing this header field will act correctly even if the cache
does not understand the community cache ...
...
The Connection general-header field allows the sender to specify
options that are desired for that particular connection ...
...
The Connection header has the following grammar:
...
... HTTP/1.1 proxies MUST parse the Connection header field before a
message is forwarded and, for each connection-token ...
... token in this field,
remove any header field(s) from the message with the same name as the
connection-token ...
... connection-token in the Connection header field, not by any
corresponding additional header field(s), since the additional header ...
... Connection header field, not by any
corresponding additional header field(s), since the additional header
field may not be sent if there are no parameters associated with that
...
... header field, not by any
corresponding additional header field(s), since the additional header
field may not be sent if there are no parameters associated with that
connection ...
...
in either the request or the response header fields indicates that
the connection SHOULD NOT be considered `persistent' (section 8.1)
...
... token in this
field, remove and ignore any header field(s) from the message with
the same name as the connection-token ...
... connection-token. This protects against mistaken
forwarding of such header fields by pre-HTTP/1.1 proxies. See section
...
... The Content-Encoding entity-header field is used as a modifier to the
media-type. When present, its value indicates what additional content
...
... media-type
referenced by the Content-Type header field. Content-Encoding is
primarily used to allow a document to be compressed without losing
...
... response MUST include a Content-Encoding entity-header (section
14.11) that lists the non-identity content-coding(s) used.
...
... encoding parameters MAY be provided
by other entity-header fields not defined by this specification.
...
... The Content-Language entity-header field describes the natural
language(s) of the intended audience for the enclosed entity ...
... The Content-Length entity-header field indicates the size of the
entity-body, in decimal number of OCTETs, sent to the recipient or,
...
... The Content-Location entity-header field MAY be used to supply the
resource location for the entity enclosed in the message when that
...
...
The meaning of the Content-Location header in PUT or POST requests is
undefined; servers are free to ignore it in those cases.
...
...
The Content-MD5 header field MAY be generated by an origin server or
client to function as an integrity ...
... gateways and proxies, MAY check that the digest value
in this header field matches that of the entity-body as received.
...
... composite
types MAY contain many body-parts, each with its own MIME and HTTP
headers (including Content-MD5, Content-Transfer-Encoding, and
...
... Content-Transfer-Encoding, and
Content-Encoding headers). If a body-part has a Content-Transfer-
Encoding or Content-Encoding ...
... Encoding or Content-Encoding header, it is assumed that the content
of the body-part has had the encoding applied, and the body-part is
...
... Content-MD5 digest as is -- i.e., after the
application. The Transfer-Encoding header field is not allowed within
body-parts.
...
... The Content-Range entity-header is sent with a partial entity-body to
specify where in the full entity ...
...
The header SHOULD indicate the total length of the full entity-body,
unless this length is unknown or difficult to determine. The asterisk
...
... ranges that overlap without any holes), this content is
transmitted with a Content-Range header, and a Content-Length header
...
... Range header, and a Content-Length header
showing the number of bytes actually transferred. For example,
...
... invalid, the server SHOULD treat the request as if the invalid Range
header field did not exist. (Normally, this means return a 200
response containing the full entity).
...
... If the server receives a request (other than one including an If-
Range request-header field) with an unsatisfiable Range request-
header field ...
... request-header field) with an unsatisfiable Range request-
header field (that is, all of whose byte-range-spec values have a
first-byte-pos value greater than the current length of the selected
...
... range not satisfiable) response instead of a 200 (OK) response for
an unsatisfiable Range request-header, since not all servers
implement this request-header.
...
...
The Date general-header field represents the date and time at which
the message was originated, having the same semantics as orig-date in
...
...
Origin servers MUST include a Date header field in all responses,
except in these cases:
...
... If the response status code is 100 (Continue) or 101 (Switching
Protocols), the response MAY include a Date header field, at
the server's option. ...
... If the server does not have a clock that can provide a
reasonable approximation of the current time, its responses
MUST NOT include a Date header field. In this case, the rules
in section 14.18.1 MUST be followed. ...
...
A received message that does not have a Date header field MUST be
assigned one by the recipient if the message will be cached by that
recipient or gatewayed via a protocol which requires a Date. An HTTP ...
...
Clients SHOULD only send a Date header field in messages that include
an entity-body, as in the case of the PUT and POST requests, and even
...
... entity-body, as in the case of the PUT and POST requests, and even
then it is optional. A client without a clock MUST NOT send a Date
header field in a request.
...
...
The HTTP-date sent in a Date header SHOULD NOT represent a date and
time subsequent to the generation of the message. It SHOULD represent
the best available approximation of the date and time of message
...
...
The Expect request-header field is used to indicate that particular
server behaviors are required by the client.
...
...
This header field is defined with extensible syntax to allow for
future extensions. If a server receives a request containing an
Expect field that includes an expectation-extension that it does not
...
... return a 417 (Expectation Failed) status if it receives a request
with an expectation that it cannot meet. However, the Expect
request-header itself is end-to-end; it MUST be forwarded if the
request is forwarded.
...
...
The Expires entity-header field gives the date/time after which the
response is considered stale. A stale cache ...
...
To mark a response as "already expired," an origin server sends an
Expires date that is equal to the Date header value. (See the rules
for expiration calculations in section 13.2.4.)
...
...
The presence of an Expires header field with a date value of some
time in the future on a response that otherwise would by default be
non-cacheable indicates that the response is cacheable, unless
...
... non-cacheable indicates that the response is cacheable, unless
indicated otherwise by a Cache-Control header field (section 14.9).
...
...
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
...
... 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 ...
...
The client SHOULD NOT send the From header field without the user's
approval, as it might conflict with the user's privacy interests or
...
... A client MUST include a Host header field in all HTTP/1.1 request
messages . If the requested URI ...
... host
name for the service being requested, then the Host header field MUST
be given with an empty value. An HTTP/1.1 proxy ...
... request message it forwards does contain an appropriate Host header
field that identifies the service being requested by the proxy. All
...
... entity that
would have been returned in the response to a similar GET request
(without the If-Match header) on that resource, or if "*" is given
and any current entity exists for that resource, then the server MAY
...
... entity exists for that resource, then the server MAY
perform the requested method as if the If-Match header field did not
exist.
...
...
If the request would, without the If-Match header field, result in
anything other than a 2xx or 412 status, then the If-Match header
...
... If the request would, without the If-Match header field, result in
anything other than a 2xx or 412 status, then the If-Match header
MUST be ignored.
...
... A request intended to update a resource (e.g., a PUT) MAY include an
If-Match header field to signal that the request method MUST NOT be
applied if the entity ...
...
The result of a request having both an If-Match header field and
either an If-None-Match or an If-Modified-Since header fields is
...
... The result of a request having both an If-Match header field and
either an If-None-Match or an If-Modified-Since header fields is
undefined by this specification.
...
...
The If-Modified-Since request-header field is used with a method to
make it conditional: if the requested variant has not been modified
...
... GET method with an If-Modified-Since header and no Range header
requests that the identified entity be transferred only if it has
...
... requests that the identified entity 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:
...
...
Note: The Range request-header field modifies the meaning of If-
Modified-Since; see section 14.35 for full details.
...
...
Note: When handling an If-Modified-Since header field, some
servers will use an exact date comparison function, rather than a
...
... less-than function, for deciding whether to send a 304 (Not
Modified) response. To get best results when sending an If-
Modified-Since header field for cache validation, clients ...
... clients are
advised to use the exact date string received in a previous Last-
Modified header field whenever possible.
...
... Note: If a client uses an arbitrary date in the If-Modified-Since
header instead of a date taken from the Last-Modified header for
the same request, the client ...
... client uses an arbitrary date in the If-Modified-Since
header instead of a date taken from the Last-Modified header for
the same request, the client should be aware of the fact that this
...
...
The result of a request having both an If-Modified-Since header field
and either an If-Match or an If-Unmodified-Since header fields is
...
... The result of a request having both an If-Modified-Since header field
and either an If-Match or an If-Unmodified-Since header fields is
undefined by this specification.
...
...
The If-None-Match request-header field is used with a method to make
it conditional. A client ...
... entity tags in the
If-None-Match header field. The purpose of this feature is to allow
efficient updates of cached information with a minimum amount of
transaction ...
... entity that
would have been returned in the response to a similar GET request
(without the If-None-Match header) on that resource, or if "*" is
given and any current entity exists for that resource, then the
...
... method, unless required to do
so because the resource's modification date fails to match that
supplied in an If-Modified-Since header field in the request.
Instead, if the request method was GET or HEAD, the server SHOULD
...
... respond with a 304 (Not Modified) response, including the cache-
related header fields (particularly ETag) of one of the entities that
matched. For all other request methods, the server MUST respond with
...
... tags match, then the server MAY perform the
requested method as if the If-None-Match header field did not exist,
but MUST also ignore any If-Modified-Since header field(s) in the
...
... method as if the If-None-Match header field did not exist,
but MUST also ignore any If-Modified-Since header field(s) in the
request. That is, if no entity tags ...
...
If the request would, without the If-None-Match header field, result
in anything other than a 2xx or 304 status, then the If-None-Match
header ...
... header field, result
in anything other than a 2xx or 304 status, then the If-None-Match
header MUST be ignored. (See section 13.3.4 for a discussion of
server behavior when both If-Modified-Since and If-None-Match appear
...
...
The result of a request having both an If-None-Match header field and
either an If-Match or an If-Unmodified-Since header fields is
...
... The result of a request having both an If-None-Match header field and
either an If-Match or an If-Unmodified-Since header fields is
undefined by this specification.
...
... cache, it
could use the Range request-header with a conditional GET (using
either or both of If-Unmodified-Since and If-Match.) However, if the
condition fails because the entity ...
... entity, but does have a Last-
Modified date, it MAY use that date in an If-Range header. (The
server can distinguish between a valid HTTP ...
... tag by examining no more than two characters.) The If-Range
header SHOULD only be used together with a Range header, and MUST be
...
... header SHOULD only be used together with a Range header, and MUST be
ignored if the request does not include a Range header ...
... header, and MUST be
ignored if the request does not include a Range header, or if the
server does not support the sub-range operation.
...
...
The If-Unmodified-Since request-header field is used with a method to
make it conditional. If the requested resource has not been modified
...
... make it conditional. If the requested resource has not been modified
since the time specified in this field, the server SHOULD perform the
requested operation as if the If-Unmodified-Since header were not
present.
...
...
If the request normally (i.e., without the If-Unmodified-Since
header) would result in anything other than a 2xx or 412 status, the
If-Unmodified-Since header SHOULD be ignored.
...
... header) would result in anything other than a 2xx or 412 status, the
If-Unmodified-Since header SHOULD be ignored.
...
...
If the specified date is invalid, the header is ignored.
...
...
The result of a request having both an If-Unmodified-Since header
field and either an If-None-Match or an If-Modified-Since header
fields is undefined by this specification.
...
...
The result of a request having both an If-Unmodified-Since header
field and either an If-None-Match or an If-Modified-Since header
fields is undefined by this specification.
...
...
The Last-Modified entity-header field indicates the date and time at
which the origin server believes the variant was last modified.
...
...
The exact meaning of this header field depends on the implementation
of the origin server and the nature of the original resource. For
files, it may be just the file system ...
...
The Location response-header field is used to redirect the recipient
to a location other than the Request-URI for completion of the
...
...
Note: The Content-Location header field (section 14.14) differs
from Location in that the Content-Location identifies the original
...
... location of the entity enclosed in the request. It is therefore
possible for a response to contain header fields for both Location
and Content-Location. Also see section 13.10 for cache ...
...
The Max-Forwards request-header field provides a mechanism with the
TRACE (section 9.8) and OPTIONS (section 9.2) methods ...
... gateway recipient of a TRACE or OPTIONS request
containing a Max-Forwards header field MUST check and update its
value prior to forwarding the request. If the received value is zero
...
...
The Max-Forwards header field MAY be ignored for all other methods
defined by this specification and for any extension methods ...
...
The Pragma general-header field is used to include implementation-
specific directives that might apply to any recipient along the
request/response ...
... HTTP/1.0. Clients SHOULD include both header fields when a no-cache
request is sent to a server not known to be HTTP/1.1 ...
... Note: because the meaning of "Pragma: no-cache as a response
header field is not actually specified, it does not provide a
reliable replacement for "Cache-Control: no-cache ...
... The Proxy-Authenticate response-header field MUST be included as part
of a 407 (Proxy Authentication Required ...
... WWW-Authenticate, the Proxy-Authenticate header field applies only to
the current connection and SHOULD NOT be passed on to downstream ...
... The Proxy-Authorization request-header field allows the client to
identify itself (or its user) to a proxy ...
... Authorization, the Proxy-Authorization header field applies only to
the next outbound proxy that demanded authentication ...
... Proxy-Authorization header field is consumed by the first outbound
proxy that was expecting to receive credentials. A proxy ...
... set that includes one or more syntactically invalid byte-range-spec
values MUST ignore the header field that includes that byte-range-
set.
...
... the entire entity, using the Range request header, which applies to
the entity returned as the result of the request:
...
... A server MAY ignore the Range header. However, HTTP/1.1 origin
servers and intermediate caches ...
... The presence of a Range header in an unconditional GET modifies
what is returned if the GET is otherwise successful. In other
...
... The presence of a Range header in a conditional GET (a request
using one or both of If-Modified-Since and If-None-Match, or
one or both of If-Unmodified-Since and If-Match) modifies what
...
... In some cases, it might be more appropriate to use the If-Range
header (see section 14.27) in addition to the Range header.
...
...
The Referer[sic] request-header field allows the client to specify,
for the server's benefit, the address ...
... which the Request-URI was obtained (the "referrer", although the
header field is misspelled.) The Referer request-header allows a
server to generate lists of back-links ...
... Request-URI was obtained (the "referrer", although the
header field is misspelled.) The Referer request-header allows a
server to generate lists of back-links to resources for interest,
...
...
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 ...
... proxy
application MUST NOT modify the Server response-header. Instead, it
SHOULD include a Via field (as described in section 14.45).
...
...
The TE request-header field indicates what extension transfer-codings
it is willing to accept in the response and whether or not it is
willing to accept trailer fields ...
...
The TE header field only applies to the immediate connection.
Therefore, the keyword MUST be supplied within a Connection ...
... connection.
Therefore, the keyword MUST be supplied within a Connection header
field (section 14.10) whenever TE is present in an HTTP/1.1 message.
...
...
The Trailer general field value indicates that the given set of
header fields is present in the trailer of a message encoded with
chunked transfer-coding.
...
...
An HTTP/1.1 message SHOULD include a Trailer header field in a
message using chunked transfer-coding with a non-empty trailer. Doing
so allows the recipient to know which header fields ...
... header field in a
message using chunked transfer-coding with a non-empty trailer. Doing
so allows the recipient to know which header fields to expect in the
trailer.
...
...
If no Trailer header field is present, the trailer SHOULD NOT include
any header fields. See section 3.6.1 for restrictions on the use of
...
... If no Trailer header field is present, the trailer SHOULD NOT include
any header fields. See section 3.6.1 for restrictions on the use of
trailer fields in a "chunked" transfer-coding.
...
...
Message header fields listed in the Trailer header field MUST NOT
include the following header fields ...
...
Message header fields listed in the Trailer header field MUST NOT
include the following header fields:
...
... Message header fields listed in the Trailer header field MUST NOT
include the following header fields:
...
...
The Transfer-Encoding general-header field indicates what (if any)
type of transformation has been applied to the message body in order
...
... encoding parameters MAY be provided
by other entity-header fields not defined by this specification.
...
... Many older HTTP/1.0 applications do not understand the Transfer-
Encoding header.
...
...
The Upgrade general-header allows the client to specify what
additional communication protocols it supports and would like to use
...
... if the server finds it appropriate to switch protocols. The server
MUST use the Upgrade header field within a 101 (Switching Protocols)
response to indicate which protocol(s) are being switched.
...
...
The Upgrade header field is intended to provide a simple mechanism
for transition from HTTP/1.1 to some other, incompatible protocol. It
...
...
The Upgrade header field only applies to switching application-layer
protocols upon the existing transport-layer ...
... new protocol chosen, although the first action
after changing the protocol MUST be a response to the initial HTTP
request containing the Upgrade header field.
...
...
The Upgrade header field only applies to the immediate connection.
Therefore, the upgrade keyword MUST be supplied within a Connection ...
... Therefore, the upgrade keyword MUST be supplied within a Connection
header field (section 14.10) whenever Upgrade is present in an
HTTP/1.1 message.
...
...
The Upgrade header field cannot be used to indicate a switch to a
protocol on a different connection ...
...
The User-Agent request-header field contains information about the
user agent originating the request. This is for statistical purposes,
...
...
The Vary field value indicates the set of request-header fields that
fully determines, while the response is fresh, whether a cache is
...
... to select the representation. A Vary field value of "*" implies that
a cache cannot determine from the request headers of a subsequent
request whether this response is the appropriate representation. See
section 13.6 for use of the Vary header field ...
... headers of a subsequent
request whether this response is the appropriate representation. See
section 13.6 for use of the Vary header field by caches.
...
...
An HTTP/1.1 server SHOULD include a Vary header field with any
cacheable response that is subject to server-driven negotiation ...
... user agent about the presence of negotiation
on that resource. A server MAY include a Vary header field with a
non-cacheable response that is subject to server-driven negotiation ...
... the representation selected for the response is based on a selection
algorithm which considers ONLY the listed request-header field values
in selecting the most appropriate representation. A cache MAY assume
...
... The field-names given are not limited to the set of standard
request-header fields defined by this specification. Field names are
case-insensitive.
...
...
A Vary field value of "*" signals that unspecified parameters not
limited to the request-headers (e.g., the network address of the
...
...
Comments MAY be used in the Via header field to identify the software
of the recipient proxy or gateway ...
... gateway, analogous to the User-Agent and
Server header fields. However, all comments in the Via field are
optional and MAY be removed by any recipient prior to forwarding the
...
... the request by forwarding it to the origin server at www.ics.uci.edu.
The request received by www.ics.uci.edu would then have the following
Via header field:
...
... internal structures, a proxy MAY combine an ordered subsequence of
Via header field entries with identical received-protocol values into
a single such entry. For example,
...
...
The Warning general-header field is used to carry additional
information about the status or transformation of a message which
might not be reflected in the message. This information is typically
...
...
Warning headers are sent with responses using:
...
...
A response MAY carry more than one Warning header.
...
...
Warning headers can in general be applied to any message, however
some specific warn-codes are specific to caches and can only be
...
... some specific warn-codes are specific to caches and can only be
applied to response messages. New Warning headers SHOULD be added
after any existing Warning headers. A cache ...
... applied to response messages. New Warning headers SHOULD be added
after any existing Warning headers. A cache MUST NOT delete any
...
... cache MUST NOT delete any
Warning header that it received with a message. However, if a cache
successfully validates ...
... cache entry, it SHOULD remove any Warning
headers previously attached to that entry except as specified for
specific Warning codes. It MUST then add any Warning headers received
...
... headers previously attached to that entry except as specified for
specific Warning codes. It MUST then add any Warning headers received
in the validating response. In other words, Warning headers are those
...
... specific Warning codes. It MUST then add any Warning headers received
in the validating response. In other words, Warning headers are those
that would be attached to the most recent relevant response.
...
...
When multiple Warning headers are attached to a response, the user
agent ought to inform the user of as many of them as possible, in the
order that they appear in the response. If it is not possible to
...
...
Systems that generate multiple Warning headers SHOULD order them with
this user agent behavior in mind. ...
... transformation changing the content-coding (as specified in the
Content-Encoding header) or media-type (as specified in the
Content-Type ...
... media-type (as specified in the
Content-Type header) of the response, or the entity-body of the
response, unless this Warning code already appears in the response. ...
...
If an implementation sends a message with one or more Warning headers
whose version is HTTP/1.0 ...
... deleted from
the message before storing, forwarding, or using it. (This prevents
bad consequences of naive caching of Warning header fields.) If all
of the warning-values are deleted for this reason, the Warning header ...
... header fields.) If all
of the warning-values are deleted for this reason, the Warning header
MUST be deleted as well.
...
...
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 ...
... Authenticate field value as it might contain more than one challenge,
or if more than one WWW-Authenticate header field is provided, the
contents of a challenge itself can contain a comma-separated list of
authentication ...
... applications SHOULD supply as much control over this information as
possible to the provider of that information. Four header fields are
worth special mention in this context: Server, Via, Referer and From.
...
... network firewall SHOULD
take special precautions regarding the transfer of header information
that identifies the hosts behind the firewall ...
...
The Referer header allows reading patterns to be studied and reverse
links drawn. Although it can be very useful, its power can be abused
...
... the Referer. Even when the personal information has been removed, the
Referer header might indicate a private document's URI whose
publication would be inappropriate.
...
...
The User-Agent (section 14.43) or Server (section 14.38) header
fields can sometimes be used to determine that a specific client or
server have a particular security hole which might be exploited.
...
...
Accept request-headers can reveal information about the user to all
servers which are accessed. The Accept-Language header ...
... request-headers can reveal information about the user to all
servers which are accessed. The Accept-Language header in particular
can reveal information the user would consider to be of a private
nature, because the understanding of particular languages ...
... User agents which offer the option to configure the contents of an
Accept-Language header to be sent in every request are strongly
encouraged to let the configuration process include a message which
makes the user aware of the loss of privacy ...
... user agent
to omit the sending of Accept-Language headers by default, and to ask
the user whether or not to start sending Accept-Language ...
... the user whether or not to start sending Accept-Language headers to a
server if it detects, by looking for any Vary response-header fields
...
... Language headers to a
server if it detects, by looking for any Vary response-header fields
generated by the server, that such sending could improve the quality
of service ...
...
Elaborate user-customized accept header fields sent in every request,
in particular if these include quality values, can be used by servers
as relatively reliable and long-lived user identifiers ...
... privacy, user agents ought to be conservative in offering accept
header configuration options to end users. As an extreme privacy
measure, proxies ...
... measure, proxies could filter the accept headers in relayed requests.
General purpose user agents which provide a high degree of header ...
... headers in relayed requests.
General purpose user agents which provide a high degree of header
configurability SHOULD warn users about the loss of privacy which can
...
... trust
one another, then it MUST check the values of Location and Content-
Location headers in responses that are generated under control of
said organizations to make sure that they do not attempt to
invalidate resources over which they have no authority ...
... 35], from which the often implemented Content-Disposition
(see section 19.5.1) header in HTTP is derived, has a number of very
serious security considerations ...
... Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047draft, November 1996. ...
... Troost, R. and Dorner, S., "Communicating Presentation Information in Internet Messages: The Content-Disposition Header", RFC 1806exp, June 1995. ...
... Troost, R., Dorner, S. and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183prop, August 1997. ...
...
The line terminator for message-header fields is the sequence CRLF.
However, we recommend that applications, when parsing such headers ...
... message-header fields is the sequence CRLF.
However, we recommend that applications, when parsing such headers,
recognize a single LF as a line terminator and ignore the leading CR ...
... If an HTTP header incorrectly carries a date value with a time
zone other than GMT, it MUST be converted into GMT ...
... HTTP/1.1 messages MAY
include a single MIME-Version general-header field to indicate what
version of the MIME ...
... MIME protocol was used to construct the message. Use
of the MIME-Version header field indicates that the message is in
full compliance with the MIME protocol (as defined in RFC 2045draft ...
... Proxies and gateways from
other protocols SHOULD ensure that any Date header field present in a
message conforms to one of the HTTP/1.1 formats and rewrite the date
...
... HTTP/1.1's
Content-Encoding header field. Since this acts as a modifier on the
media type, proxies ...
... protocols MUST either change the value of the Content-Type header
field or decode the entity-body before forwarding the message. (Some
experimental ...
... transports all message-bodies as payload (see section 3.7.2) and
does not interpret the content or any MIME header lines that might be
contained therein.
...
...
The Content-Disposition response-header field has been proposed as a
means for the origin server to suggest a default filename if the user
requests that the content is saved to a file. This usage is derived
...
... clients and servers support the Host request-
header, report an error if the Host request-header (section 14.23) is
...
... header, report an error if the Host request-header (section 14.23) is
missing from an HTTP/1.1 request, and accept absolute URIs ...
... Charset wildcarding is introduced to avoid explosion of character set
names in accept headers. (Section 14.2)
...
... meta-data
were always returned; by allowing the server to only send needed
headers in a 206 response, this problem can be avoided. (Section
10.2.7, 13.5.3, and 14.27)
...
...
This change adds the Expect header and 417 status code. The message
transmission requirements ...
... Warnings could be cached incorrectly, or not updated appropriately.
(Section 13.1.2, 13.2.4, 13.5.2, 13.5.3, 14.9.3, and 14.46) Warning
also needed to be a general header, as PUT or other methods may have
need for it in requests.
...
... adding an IANA registry for transfer-codings (separate from content
codings), a new header field (TE) and enabling trailer headers in the
...
... codings), a new header field (TE) and enabling trailer headers in the
future. Transfer encoding is a major performance ...
... URI, Public and
Content-Base header fields were defined in previous versions of this
specification, but not commonly implemented. See RFC 2068(-> 2616draft) ...