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 ...