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
... 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 headers 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 ...
...
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 ...
... SP | HT
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.
Note: Recipients of date values are encouraged to be robust in
...
...
Some HTTP header fields allow a time value to be specified as an
integer number of seconds, represented in decimal, after the time
...
... Encoding (section 14.3) and
Content-Encoding (section 14.12) 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 ...
... transfer it as a series of chunks, each with its own size indicator,
followed by an optional footer 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
...
... entity that is generated dynamically; applications MUST NOT send
header fields in the footer which are not explicitly defined as being
appropriate for the footer, such as Content-MD5 or future extensions
...
... Media Types in the Content-Type (section 14.18)
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).
If an entity ...
... Some HTTP/1.0 software has interpreted a Content-Type header without
charset parameter incorrectly to mean "recipient should guess."
...
...
In HTTP, multipart body-parts MAY contain header fields which are
significant to the meaning of that part. A Content-Location header
field ...
... header fields which are
significant to the meaning of that part. A Content-Location header
field (section 14.15) SHOULD be included in the body-part of each
enclosed entity that can be identified by a URL ...
... 14.20), If-Match (section 14.25), 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.36) and Content-Range (section 14.17)
header fields. An entity may be broken down into subranges according
to various structural units.
...
... of the message). Both types of message consist of a start-line, one
or more header fields (also known as "headers"), an empty line (i.e.,
a line with nothing preceding the CRLF ...
... start-line, one
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 an optional message-body.
...
... 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 ...
... implementations that fail to accept anything beyond the common forms.
message-header = field-name ":" [ field-value ] CRLF
...
... token, tspecials, and quoted-string>
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.
...
... 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.40).
...
... 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 MAY be included in a
request only when 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 ...
... (such 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 the
...
...
2. If a Transfer-Encoding header field (section 14.40) is present and
indicates that the "chunked" transfer coding has been applied, then
...
...
3. If a Content-Length header field (section 14.14) is present, its
value in bytes represents the length of the message-body.
...
... sender knows that the recipient can parse it;
the presence in a request of a Range header with multiple byte-range
specifiers implies that the client ...
... 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 the
"chunked" transfer coding. If both are received, the Content-Length
...
... 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.
...
... | Via ; Section 14.44
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 ...
...
Request = Request-Line ; Section 5.1
*( general-header ; Section 4.5
| request-header ; Section 5.3
...
... 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 ...
... by the server. The list of methods known by a server
can be listed in a Public response-header field (section 14.35).
The methods ...
... URI (net_loc) MUST
be transmitted in a Host header field. For example, a client wishing
to retrieve the resource above directly from the origin server would
...
... Request-URI and the Host header field.
An origin server that does not allow resources to differ by the
...
... requested host MAY ignore the Host header field value. (But see
section 19.5.1 for other requirements on Host ...
... Request-URI is not an absoluteURI, and the request
includes a Host header field, the host is determined by the Host
...
... 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 ...
... invocation.
request-header = Accept ; Section 14.1
| Accept-Charset ; Section 14.2
...
... User-Agent ; Section 14.42
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 ...
...
Response = Status-Line ; Section 6.1
*( general-header ; Section 4.5
| response-header ; Section 6.2
...
... Response Header Fields ...
...
The response-header fields allow the server to pass additional
information about the response which cannot be placed in the Status-
Line. These header fields ...
... 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.
...
... WWW-Authenticate ; Section 14.46
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-body, although some
responses will only include the entity-headers.
In this section, both sender ...
... Entity Header Fields ...
...
Entity-header fields define optional metainformation about the
entity-body or, if no body is present, about the resource identified
...
... | Expires ; Section 14.21
| Last-Modified ; Section 14.29
| extension-header
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 forwarded by 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. 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 14.2.1.
The proxy server ...
... empty footer 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 ...
... client
o MUST first send the request header fields, and then
o MUST wait for the server to respond with either a 100 (Continue)
...
... connection to the server
2. Transmit the request-headers
3. Initialize a variable R to the estimated round-trip time ...
... Request-URI is an asterisk ("*"), the OPTIONS request is
intended to apply to the server as a whole. A 200 response SHOULD
include any header fields which indicate optional features
implemented by the server (e.g., Public), including any extensions
...
... by the server (e.g., Public), including any extensions
not defined by this specification, in addition to any applicable
general or response-header fields. As described in section 5.1.2, an
"OPTIONS *" request can be applied through a proxy by specifying the
...
... Request-URI is not an asterisk, the OPTIONS request applies
only to the options that are available when communicating with that
resource. A 200 response SHOULD include any header fields which
indicate optional features implemented by the server and applicable
...
... to that resource (e.g., Allow), including any extensions not defined
by this specification, in addition to any applicable general or
response-header fields. If the OPTIONS request passes through a
proxy, the proxy ...
... 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).
Responses to this method ...
... method are not cachable, 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.
...
... 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.44) 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. Since HTTP/1.0 did not define any 1xx
...
... The server understands and is willing to comply with the client's
request, via the Upgrade message header field (section 14.41), 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.
...
...
HEAD 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 URL
for the resource given by a Location header field. The origin server
MUST create the resource before returning the 201 status code ...
...
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 ...
... view. The response MAY include new metainformation in the form of
entity-headers, which SHOULD apply to the document currently in the
user agent's active ...
... 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.36)
indicating the desired range. The response MUST include either a
...
... range. The response MUST include either a
Content-Range header field (section 14.17) indicating the range
included with this response, or a multipart/byteranges Content-Type ...
... Range fields for each part. If multipart/byteranges
is not used, the Content-Length header field in the response MUST
match the actual number of OCTETs transmitted in the message-body.
...
... 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
the user agent, selection of the most appropriate choice may be
...
... Request-URI for future requests. This response is
only cachable if indicated by a Cache-Control or Expires header
field.
If the new URI ...
... message-body.
The response MUST include the following header fields:
o Date
...
...
o 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 ...
... headers; this prevents
inconsistencies between cached entity-bodies and updated headers.
If a 304 response indicates an entity ...
... The 304 response MUST NOT include a message-body, and thus is always
terminated by the first empty line after the header fields.
...
... user authentication. The response MUST include a
WWW-Authenticate header field (section 14.46) containing a challenge
applicable to the requested resource. The client MAY repeat the
...
... 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.
Unless it was a HEAD 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 ...
... 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. If the response
could be unacceptable, a user agent ...
... return a Proxy-Authenticate header field (section 14.33) containing a
challenge applicable to the proxy for the requested resource. The
...
... Proxy-Authorization
header field (section 14.34). HTTP access authentication is explained
in section 11.
...
... 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.
...
... 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
...
... user agent. This response MUST
include a WWW-Authenticate header field containing at least one
challenge applicable to the requested resource.
...
... receiving a 401 or 411 response-
-MAY do so by including an Authorization header field with the
request. The Authorization field value consists of credentials ...
... request, it SHOULD return a 401 (Unauthorized) response. The response
MUST include a WWW-Authenticate header field containing the (possibly
new) challenge applicable to the requested resource and an entity
...
... transport level or
via message encapsulation, and with additional header fields
specifying authentication information. However, these additional
...
... WWW-Authenticate and
Authorization headers untouched, and follow the rules found in
section 14.8.
...
... user agent wishes to send the userid "Aladdin" and password
"open sesame", it would use the following header field:
Authorization ...
... 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.
...
...
HTTP/1.1 origin servers MUST include an appropriate Vary header field
(section 14.43) in any cachable response based on server-driven
negotiation ...
... (section 14.43) in any cachable response based on server-driven
negotiation. The Vary header field describes the dimensions over
which the response might vary (i.e. the dimensions over which the
origin server picks its "best guess" response from multiple
...
... HTTP/1.1 public caches MUST recognize the Vary header field when it
is included in a response and obey the requirements described in
...
... initial response from the origin server. Selection is based on a list
of the available representations of the response included within the
header fields (this specification reserves the field-name Alternates,
as described in appendix 19.6.2.1) or entity ...
... cache performing transparent negotiation MUST include a Vary header
field in the response (defining the dimensions of its variance) if it
is cachable to ensure correct interoperation with all HTTP/1.1
...
... 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
...
... "fresh enough" (in the sense of condition 2 in section 13.1.1), it
must attach a warning to that effect, using a Warning response-
header. This warning allows clients to take appropriate action.
...
... caches will simply pass the
warning along as an entity-header in the response.
Warnings are assigned numbers between 0 and 99. This specification
...
... language (perhaps based on the client's Accept
headers), and include an optional indication of what character set is
used.
...
... heuristics.
The Warning header and the currently defined warnings are described
in section 14.45.
...
...
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 should be applied (that
is, the one that is most likely to preserve semantic transparency).
...
... connected to the origin server. Whenever a cache returns a stale
response, it MUST mark it as such (using a Warning header). This
allows 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.
...
... header, or the max-age directive of the Cache-Control header.
An expiration time cannot be used to force a user agent ...
... 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
...
...
Also note that HTTP/1.1 requires origin servers to send a Date header
with every response, giving the time at which the response was
generated. We use the term "date_value" to denote the value of the
...
... with every response, giving the time at which the response was
generated. We use the term "date_value" to denote the value of the
Date header, in a form appropriate for arithmetic operations.
HTTP/1.1 ...
...
HTTP/1.1 uses the Age response-header to help convey age information
between caches. The Age header value ...
... header to help convey age information
between caches. The Age header value is the sender's estimate of the
amount of time since the response was generated at the origin server.
...
... network paths.
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 ...
... corrected_initial_age the amount of time that the response was
resident locally. It must then transmit this total age, using the Age
header, to the next recipient cache.
...
... Note that a client cannot reliably tell that a response is first-
hand, but the presence of an Age header indicates that a response
is definitely not first-hand. Also, if the Date in a response is
earlier than the client ...
...
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.10.
The max-age directive takes priority ...
... 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 may arise because the cache is pooling
responses from other caches ...
... intentionally carries an earlier expiration time. However, the
HTTP/1.1 specification requires the transmission of Date headers on
every response, and the Date values are ordered to a granularity of
one second.
...
... 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.
...
... o 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.
...
... 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.
Note that some HTTP/1.0 ...
... and returning a response to a previous request if that request
included an Authorization header.
A response received with a status code ...
... 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 (section
...
... directives or another header(s) that explicitly allow it. For
example, these include the following: an Expires header (section
14.21); a "max-age", "must-revalidate", "proxy-revalidate", "public"
...
... 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:
o End-to-end ...
...
o End-to-end headers, which must be transmitted to the
ultimate recipient of a request or response. End-to-end
...
... ultimate recipient of a request or response. End-to-end
headers in responses must be stored as part of a cache entry
and transmitted in any response formed from a cache ...
... and transmitted in any response formed from a cache entry.
o Hop-by-hop headers, which are meaningful only for a single
transport-level connection ...
... Non-modifiable Headers ...
... HTTP/1.1 protocol, such as Digest
Authentication, depend on the value of certain end-to-end headers. A
cache or non-caching proxy ...
... cache or non-caching proxy SHOULD NOT modify an end-to-end header
unless the definition of that header requires or specifically allows
...
... end-to-end header
unless the definition of that header requires or specifically allows
that.
...
...
Warning: unnecessary modification of end-to-end headers may cause
authentication failures if stronger authentication ...
... later versions of HTTP. Such authentication
mechanisms may rely on the values of header fields not listed here.
...
... Combining Headers ...
... entity-body of this
outgoing response. The end-to-end headers stored in the cache entry
are used for the constructed response, except that any end-to-end ...
... are used for the constructed response, except that any end-to-end
headers provided in the 304 response MUST replace the corresponding
headers from the cache ...
... headers provided in the 304 response MUST replace the corresponding
headers from the cache entry. Unless the cache decides to remove ...
... 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.
...
...
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. The cache ...
... stored with the cache entry. The cache may add Warning headers (see
section 14.45) to this set.
...
... section 14.45) to this set.
If a header field-name in the incoming response matches more than one
header in the cache ...
... If a header field-name in the incoming response matches more than one
header in the cache entry, all such old headers are replaced.
...
... header in the cache entry, all such old headers are replaced.
Note: this rule allows an origin server to use a 304 (Not Modified)
...
... Note: this rule allows an origin server to use a 304 (Not Modified)
response to update any header associated with a previous response
for the same entity, although it might not always be meaningful or
...
... correct to do so. This rule does not allow an origin server to use
a 304 (not Modified) response to entirely delete a header that it
had provided with a previous response.
...
... Use of server-driven content negotiation (section 12), 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
...
... subsequent requests.
A server MUST use the Vary header field (section 14.43) to inform a
cache of what header field ...
... header field (section 14.43) to inform a
cache of what header field dimensions are used to select among
multiple representations of a cachable response. A cache may use the
...
... response) for replying to subsequent requests on that resource only
when the subsequent requests have the same or equivalent values for
all header fields specified in the Vary response-header. Requests
with a different value for one or more of those header fields ...
... when the subsequent requests have the same or equivalent values for
all header fields specified in the Vary response-header. Requests
with a different value for one or more of those header fields would
...
... header fields specified in the Vary response-header. Requests
with a different value for one or more of those header fields would
be forwarded toward the origin server.
...
... entity tags in an If-
None-Match header field from all its cache entries for the Request-
URI ...
... cache, so that if any one of these entities matches the requested
entity, the server can use the ETag header in its 304 (Not Modified)
response to tell the cache which entry is appropriate. If the
...
...
new response SHOULD be used to update the header fields of the
existing entry, and the result MUST be returned to the client.
...
... client.
The Vary header field may also inform the cache that the
representation was selected using criteria not limited to the
...
... cache that the
representation was selected using criteria not limited to the
request-headers; in this case, a cache MUST NOT use the response in a
reply to a subsequent request unless the