access controls.
13.8 Errors or Incomplete Response Cache Behavior
A 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
response. Partial responses may be combined as described in section
13.5.4; the result might be a full response or might still be
partial. A cache MUST NOT return a partial response to a client
without explicitly marking it as such, using the 206 (Partial
Content) status code. A cache MUST NOT return a partial response
using a status code of 200 (OK).
If a cache receives a 5xx response while attempting to revalidate an
entry, it may either forward this response to the requesting client,
or act as if the server failed to respond. In the latter case, it MAY
return a previously received response unless the cached entry
includes the "must-revalidate" Cache-Control directive (see section
14.9).
13.9 Side Effects of GET and HEAD
Unless the origin server explicitly prohibits the caching of their
responses, the application of GET and HEAD methods to any resources
SHOULD NOT have side effects that would lead to erroneous behavior if
these responses are taken from a cache. They may still have side
effects, but a cache is not required to consider such side effects in
its caching decisions. Caches are always expected to observe an
origin server's explicit restrictions on caching.
We note one exception to this rule: since some applications have
traditionally used GETs and HEADs with query URLs (those containing a
"?" in the rel_path part) to perform operations with significant side
effects, caches MUST NOT treat responses to such URLs as fresh unless
the server provides an explicit expiration time. This specifically
means that responses from HTTP/1.0 servers for such URIs should not
be taken from a cache. See section 9.1.1 for related information.
13.10 Invalidation After Updates or Deletions
The effect of certain methods at the origin server may cause one or
more existing cache entries to become non-transparently invalid. That
is, although they may continue to be "fresh," they do not accurately
reflect what the origin server would return for a new request.
There is no way for the HTTP protocol to guarantee that all such
cache entries are marked invalid. For example, the request that
caused the change at the origin server may not have gone through the
proxy where a cache entry is stored. However, several rules help
reduce the likelihood of erroneous behavior.
In this section, the phrase "invalidate an entity" means that the
cache should either remove all instances of that entity from its
storage, or should mark these as "invalid" and in need of a mandatory
revalidation before they can be returned in response to a subsequent
request.
Some HTTP methods may invalidate an entity. This is either the entity
referred to by the Request-URI, or by the Location or Content-
Location response-headers (if present). These methods are:
o PUT
o DELETE
o POST
In order to prevent denial of service attacks, an invalidation based
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.
13.11 Write-Through Mandatory
All methods that may be expected to cause modifications to the origin
server's resources MUST be written through to the origin server. This
currently includes all methods except for GET and HEAD. A cache MUST
NOT reply to such a request from a client before having transmitted
the request to the inbound server, and having received a
corresponding response from the inbound server. This does not prevent
a cache from sending a 100 (Continue) response before the inbound
server has replied.
The alternative (known as "write-back" or "copy-back" caching) is not
allowed in HTTP/1.1, due to the difficulty of providing consistent
updates and the problems arising from server, cache, or network
failure prior to write-back.
13.12 Cache Replacement
If a new cachable (see sections 14.9.2, 13.2.5, 13.2.6 and 13.8)
response is received from a resource while any existing responses for
the same resource are cached, the cache SHOULD use the new response
to reply to the current request. It may insert it into cache storage
and may, if it meets all other requirements, use it to respond to any
future requests that would previously have caused the old response to
be returned. If it inserts the new response into cache storage it
should follow the rules in section 13.5.3.
Note: a new response that has an older Date header value than
existing cached responses is not cachable.
13.13 History Lists
User agents often have history mechanisms, such as "Back" buttons and
history lists, which can be used to redisplay an entity retrieved
earlier in a session.
History mechanisms and caches are different. In particular history
mechanisms SHOULD NOT try to show a semantically transparent view of
the current state of a resource. Rather, a history mechanism is meant
to show exactly what the user saw at the time when the resource was
retrieved.
By default, an expiration time does not apply to history mechanisms.
If the entity is still in storage, a history mechanism should display
it even if the entity has expired, unless the user has specifically
configured the agent to refresh expired history documents.
This should not be construed to prohibit the history mechanism from
telling the user that a view may be stale.
Note: if history list mechanisms unnecessarily prevent users from
viewing stale resources, this will tend to force service authors to
avoid using HTTP expiration controls and cache controls when they
would otherwise like to. Service authors may consider it important
that users not be presented with error messages or warning messages
when they use navigation controls (such as BACK) to view previously
fetched resources. Even though sometimes such resources ought not
to cached, or ought to expire quickly, user interface
considerations may force service authors to resort to other means
of preventing caching (e.g. "once-only" URLs) in order not to
suffer the effects of improperly functioning history mechanisms.
14 Header Field Definitions
This section defines the syntax and semantics of all standard
HTTP/1.1 header fields. For entity-header fields, both sender and
recipient refer to either the client or the server, depending on who
sends and who receives the entity.
14.1 Accept
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
image.
Accept = "Accept" ":"
#( media-range [ accept-params ] )
media-range = ( "*/*"
| ( type "/" "*" )
| ( type "/" subtype )
) *( ";" parameter )
accept-params = ";" "q" "=" qvalue *( accept-extension )
accept-extension = ";" token [ "=" ( token | quoted-string ) ]
The asterisk "*" character is used to group media types into ranges,
with "*/*" indicating all media types and "type/*" indicating all
subtypes of that type. The media-range MAY include media type
parameters that are applicable to that range.
Each media-range MAY be followed by one or more accept-params,
beginning with the "q" parameter for indicating a relative quality
factor. The first "q" parameter (if any) separates the media-range
parameter(s) from the accept-params. Quality factors allow the user
or user agent to indicate the relative degree of preference for that
media-range, using the qvalue scale from 0 to 1 (section 3.9). The
default value is q=1.
Note: Use of the "q" parameter name to separate media type
parameters from Accept extension parameters is due to historical
practice. Although this prevents any media type parameter named
"q" from being used with a media range, such an event is believed
to be unlikely given the lack of any "q" parameters in the IANA
media type registry and the rare usage of any media type parameters
in Accept. Future media types should be discouraged from
registering any parameter named "q".
The example
Accept: audio/*; q=0.2, audio/basic
SHOULD be interpreted as "I prefer audio/basic, but send me any audio
type if it is the best available after an 80% mark-down in quality."
If no Accept header field is present, then it is assumed that the
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
send a 406 (not acceptable) response.
A more elaborate example is
Accept: text/plain; q=0.5, text/html,
text/x-dvi; q=0.8, text/x-c
Verbally, this would be interpreted as "text/html and text/x-c are
the preferred media types, but if they do not exist, then send the
text/x-dvi entity, and if that does not exist, send the text/plain
entity."
Media ranges can be overridden by more specific media ranges or
specific media types. If more than one media range applies to a given
type, the most specific reference has precedence. For example,
Accept: text/*, text/html, text/html;level=1, */*
have the following precedence:
1) text/html;level=1
2) text/html
3) text/*
4) */*
The media type quality factor associated with a given type is
determined by finding the media range with the highest precedence
which matches that type. For example,
Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
text/html;level=2;q=0.4, */*;q=0.5
would cause the following values to be associated:
text/html;level=1 = 1
text/html = 0.7
text/plain = 0.3
image/jpeg = 0.5
text/html;level=2 = 0.4
text/html;level=3 = 0.7
Note: A user agent may be provided with a default set of quality
values for certain media ranges. However, unless the user agent is
a closed system which cannot interact with other rendering agents,
this default set should be configurable by the user.
14.2 Accept-Charset
The Accept-Charset request-header field can be used to indicate what
character sets are acceptable for the response. This field allows
clients capable of understanding more comprehensive or special-
purpose character sets to signal that capability to a server which is
capable of representing documents in those character sets. The ISO-
8859-1 character set can be assumed to be acceptable to all user
agents.
Accept-Charset = "Accept-Charset" ":"
1#( charset [ ";" "q" "=" qvalue ] )
Character set values are described in section 3.4. Each charset may
be given an associated quality value which represents the user's
preference for that charset. The default value is q=1. An example is
Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
If no Accept-Charset header is present, the default is that any
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 header, then the server SHOULD send
an error response with the 406 (not acceptable) status code, though
the sending of an unacceptable response is also allowed.
14.3 Accept-Encoding
The Accept-Encoding request-header field is similar to Accept, but
restricts the content-coding values (section 14.12) which are
acceptable in the response.
Accept-Encoding = "Accept-Encoding" ":"
#( content-coding )
An example of its use is
Accept-Encoding: compress, gzip
If no Accept-Encoding header is present in a request, the server MAY
assume that the client will accept any content coding. If an Accept-
Encoding header is present, 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.
An empty Accept-Encoding value indicates none are acceptable.
14.4 Accept-Language
The Accept-Language request-header field is similar to Accept, but
restricts the set of natural languages that are preferred as a
response to the request.
Accept-Language = "Accept-Language" ":"
1#( language-range [ ";" "q" "=" qvalue ] )
language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )
Each language-range MAY be given an associated quality value which
represents an estimate of the user's preference for the languages
specified by that range. The quality value defaults to "q=1". For
example,
Accept-Language: da, en-gb;q=0.8, en;q=0.7
would mean: "I prefer Danish, but will accept British English and
other types of English." A language-range matches a language-tag if
it exactly equals the tag, or if it exactly equals a prefix of the
tag such that the first tag character following the prefix is "-".
The special range "*", if present in the Accept-Language field,
matches every tag not matched by any other range present in the
Accept-Language field.
Note: This use of a prefix matching rule does not imply that
language tags are assigned to languages in such a way that it is
always true that if a user understands a language with a certain
tag, then this user will also understand all languages with tags
for which this tag is a prefix. The prefix rule simply allows the
use of prefix tags if this is the case.
The language quality factor assigned to a language-tag by the
Accept-Language field is the quality value of the longest language-
range in the field that matches the language-tag. If no language-
range in the field matches the tag, the language quality factor
assigned is 0. If no Accept-Language header is present in the
request, the server SHOULD assume that all 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.
It may be contrary to the 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
section 15.7.
Note: As intelligibility is highly dependent on the individual
user, it is recommended that client applications make the choice of
linguistic 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.
14.5 Accept-Ranges
The Accept-Ranges response-header field allows the server to indicate
its acceptance of range requests for a resource:
Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges
acceptable-ranges = 1#range-unit | "none"
Origin servers that accept byte-range requests MAY send
Accept-Ranges: bytes
but are not required to do so. Clients MAY generate byte-range
requests without having received this header for the resource
involved.
Servers that do not accept any kind of range request for a resource
MAY send
Accept-Ranges: none
to advise the client not to attempt a range request.
14.6 Age
The Age response-header field conveys the sender's estimate of the
amount of time since the response (or its revalidation) was generated
at the origin server. A cached response is "fresh" if its age does
not exceed its freshness lifetime. Age values are calculated as
specified in section 13.2.3.
Age = "Age" ":" age-value
age-value = delta-seconds
Age values are non-negative decimal integers, representing time in
seconds.
If a cache receives a value larger than the largest positive 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).
HTTP/1.1 caches MUST send an Age header in every response. Caches
SHOULD use an arithmetic type of at least 31 bits of range.
14.7 Allow
The Allow entity-header field lists the set of methods supported by
the resource identified by the Request-URI. The purpose of this field
is strictly to inform the recipient of valid methods associated with
the resource. An Allow header field MUST be present in a 405 (Method
Not Allowed) response.
Allow = "Allow" ":" 1#method
Example of use:
Allow: GET, HEAD, PUT
This field cannot prevent a client from trying other methods.
However, the indications given by the Allow header field value SHOULD
be followed. The actual set of allowed methods is defined by the
origin server at the time of each request.
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 MAY have
other means of communicating with the origin server.
The Allow header field does not indicate what methods are implemented
at the server level. Servers MAY use the Public response-header field
(section 14.35) to describe what methods are implemented on the
server as a whole.
14.8 Authorization
A user agent that wishes to authenticate itself with a server--
usually, but not necessarily, after receiving a 401 response--MAY do
so by including an Authorization request-header field with the
request. The Authorization field value consists of credentials
containing the authentication information of the user agent for the
realm of the resource being requested.
Authorization = "Authorization" ":" credentials
HTTP access authentication is described in section 11. If a request
is authenticated and a realm specified, the same credentials SHOULD
be valid for all other requests within this realm.
When a shared cache (see section 13.7) receives a request containing
an Authorization field, it MUST NOT return the corresponding response
as a reply to any other request, unless one of the following specific
exceptions holds:
1. If the response includes the "proxy-revalidate" Cache-Control
directive, the cache MAY use that response in replying to a
subsequent request, but a 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.
2. If the response includes the "must-revalidate" Cache-Control
directive, the cache MAY use that response in replying to a
subsequent request, but all 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.
3. If the response includes the "public" Cache-Control directive, it
may be returned in reply to any subsequent request.
14.9 Cache-Control
The Cache-Control general-header field is used to specify directives
that MUST be obeyed by all caching mechanisms along the
request/response chain. The directives specify behavior intended to
prevent caches from adversely interfering with the request or
response. These directives typically override the default caching
algorithms. Cache directives are unidirectional in that the presence
of a directive in a request does not imply that the same directive
should be given in the response.
Note that HTTP/1.0 caches may not implement Cache-Control and may
only implement Pragma: no-cache (see section 14.32).
Cache directives must be passed through by a proxy or gateway
application, regardless of their significance to that application,
since the directives may be applicable to all recipients along the
request/response chain. It is not possible to specify a cache-
directive for a specific cache.
Cache-Control = "Cache-Control" ":" 1#cache-directive
cache-directive = cache-request-directive
| cache-response-directive
cache-request-directive =
"no-cache" [ "=" <"> 1#field-name <"> ]
| "no-store"
| "max-age" "=" delta-seconds
| "max-stale" [ "=" delta-seconds ]
| "min-fresh" "=" delta-seconds
| "only-if-cached"
| cache-extension
cache-response-directive =
"public"
| "private" [ "=" <"> 1#field-name <"> ]
| "no-cache" [ "=" <"> 1#field-name <"> ]
| "no-store"
| "no-transform"
| "must-revalidate"
| "proxy-revalidate"
| "max-age" "=" delta-seconds
| cache-extension
cache-extension = token [ "=" ( token | quoted-string ) ]
When a directive appears without any 1#field-name parameter, the
directive applies to the entire request or response. When such a
directive appears with a 1#field-name parameter, it applies only to
the named field or fields, and not to the rest of the request or
response. This mechanism supports extensibility; implementations of
future versions of the HTTP protocol may apply these directives to
header fields not defined in HTTP/1.1.
The cache-control directives can be broken down into these general
categories:
o Restrictions on what is cachable; these may only be imposed by the
origin server.
o Restrictions on what may be stored by a cache; these may be imposed
by either the origin server or the user agent.
o Modifications of the basic expiration mechanism; these may be
imposed by either the origin server or the user agent.
o Controls over cache revalidation and reload; these may only be
imposed by a user agent.
o Control over transformation of entities.
o Extensions to the caching system.
14.9.1 What is Cachable
By default, a response is cachable if the requirements of the request
method, request header fields, and the response status indicate that
it is cachable. Section 13.4 summarizes these defaults for
cachability. The following Cache-Control response directives allow an
origin server to override the default cachability of a response:
public
Indicates that the response is cachable by any cache, even if it
would normally be non-cachable or cachable only within a non-shared
cache. (See also Authorization, section 14.8, for additional
details.)
private
Indicates that all or part of the response message is intended for a
single user and MUST NOT be cached by a shared cache. This allows an
origin server to state that the specified parts of the response are
intended for only one user and are not a valid response for requests
by other users. A private (non-shared) cache may cache the response.
Note: This usage of the word private only controls where the
response may be cached, and cannot ensure the privacy of the
message content.
no-cache
Indicates that all or part of the response message MUST NOT be cached
anywhere. This allows an origin server to prevent caching even by
caches that have been configured to return stale responses to client
requests.
Note: Most HTTP/1.0 caches will not recognize or obey this
directive.
14.9.2 What May be Stored by Caches
The purpose of the no-store directive is to prevent the inadvertent
release or retention of sensitive information (for example, on backup
tapes). The no-store directive applies to the entire message, and may
be sent either in a response or in a request. If sent in a request, a
cache MUST NOT store any part of either this request or any response
to it. If sent in a response, a cache MUST NOT store any part of
either this response or the request that elicited it. This directive
applies to both non-shared and shared caches. "MUST NOT store" in
this context means that the cache MUST NOT intentionally store the
information in non-volatile storage, and MUST make a best-effort
attempt to remove the information from volatile storage as promptly
as possible after forwarding it.
Even when this directive is associated with a response, users may
explicitly store such a response outside of the caching system (e.g.,
with a "Save As" dialog). History buffers may store such responses as
part of their normal operation.
The purpose of this directive is to meet the stated requirements of
certain users and service authors who are concerned about accidental
releases of information via unanticipated accesses to cache data
structures. While the use of this directive may improve privacy in
some cases, we caution that it is NOT in any way a reliable or
sufficient mechanism for ensuring privacy. In particular, malicious
or compromised caches may not recognize or obey this directive; and
communications networks may be vulnerable to eavesdropping.
14.9.3 Modifications of the Basic Expiration Mechanism
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.
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
server to provide, for a given response, a longer expiration time to
an HTTP/1.1 (or later) cache than to an HTTP/1.0 cache. This may be
useful if certain HTTP/1.0 caches improperly calculate ages or
expiration times, perhaps due to desynchronized clocks.
Note: most older caches, not compliant with this specification, do
not implement any Cache-Control directives. An origin server
wishing to use a Cache-Control directive that restricts, but does
not prevent, caching by an HTTP/1.1-compliant cache may exploit the
requirement that the max-age directive overrides the Expires
header, and the fact that non-HTTP/1.1-compliant caches do not
observe the max-age directive.
Other directives allow an user agent to modify the basic expiration
mechanism. These directives may be specified on a request:
max-age
Indicates that the client is willing to accept a response whose age
is no greater than the specified time in seconds. Unless max-stale
directive is also included, the client is not willing to accept a
stale response.
min-fresh
Indicates that the client is willing to accept a response whose
freshness lifetime is no less than its current age plus the
specified time in seconds. That is, the client wants a response
that will still be fresh for at least the specified number of
seconds.
max-stale
Indicates that the client is willing to accept a response that has
exceeded its expiration time. If max-stale is assigned a value,
then the client is willing to accept a response that has exceeded
its expiration time by no more than the specified number of
seconds. If no value is assigned to max-stale, then the client is
willing to accept a stale response of any age.
If a cache returns a stale response, either because of a max-stale
directive on a request, or because the cache is configured to
override the expiration time of a response, the cache MUST attach a
Warning header to the stale response, using Warning 10 (Response is
stale).
14.9.4 Cache Revalidation and Reload Controls
Sometimes an user agent may want or need to insist that a cache
revalidate its cache entry with the origin server (and not just with
the next cache along the path to the origin server), or to reload its
cache entry from the origin server. End-to-end revalidation may be
necessary if either the cache or the origin server has overestimated
the expiration time of the cached response. End-to-end reload may be
necessary if the cache entry has become corrupted for some reason.
End-to-end revalidation may be requested either when the client does
not have its own local cached copy, in which case we call it
"unspecified end-to-end revalidation", or when the client does have a
local cached copy, in which case we call it "specific end-to-end
revalidation."
The client can specify these three kinds of action using Cache-
Control request directives:
End-to-end reload
The request includes a "no-cache" Cache-Control directive or, for
compatibility with HTTP/1.0 clients, "Pragma: no-cache". No field
names may be included with the no-cache directive in a request. The
server MUST NOT use a cached copy when responding to such a
request.
Specific end-to-end revalidation
The request includes a "max-age=0" Cache-Control directive, which
forces each cache along the path to the origin server to revalidate
its own entry, if any, with the next cache or server. The initial
request includes a cache-validating conditional with the client's
current validator.
Unspecified end-to-end revalidation
The request includes "max-age=0" Cache-Control directive, which
forces each cache along the path to the origin server to revalidate
its own entry, if any, with the next cache or server. The initial
request does not include a cache-validating conditional; the first
cache along the path (if any) that holds a cache entry for this
resource includes a cache-validating conditional with its current
validator.
When an intermediate cache is forced, by means of a max-age=0
directive, to revalidate its own cache entry, and the client has
supplied its own validator in the request, the supplied validator may
differ from the validator currently stored with the cache entry. In
this case, the cache may use either validator in making its own
request without affecting semantic transparency.
However, the choice of validator may affect performance. The best
approach is for the intermediate cache to use its own validator when
making its request. If the server replies with 304 (Not Modified),
then the cache should return its now validated copy to the client
with a 200 (OK) response. If the server replies with a new entity and
cache validator, however, the intermediate cache should compare the
returned validator with the one provided in the client's request,
using the strong comparison function. If the client's validator is
equal to the origin server's, then the intermediate cache simply
returns 304 (Not Modified). Otherwise, it returns the new entity with
a 200 (OK) response.
If a request includes the no-cache directive, it should not include
min-fresh, max-stale, or max-age.
In some cases, such as times of extremely poor network connectivity,
a client may want a cache to return only those responses that it
currently has stored, and not to reload or revalidate with the origin
server. To do this, the client may include the only-if-cached
directive in a request. If it receives this directive, a cache SHOULD
either respond using a cached entry that is consistent with the other
constraints of the request, or respond with a 504 (Gateway Timeout)
status. However, if a group of caches is being operated as a unified
system with good internal connectivity, such a request MAY be
forwarded within that group of caches.
Because a cache may be configured to ignore a server's specified
expiration time, and because a client request may include a max-stale
directive (which has a similar effect), the protocol also includes a
mechanism for the origin server to require revalidation of a cache
entry on any subsequent use. When the must-revalidate directive is
present in a response received by a cache, that cache MUST NOT use
the entry after it becomes stale to respond to a subsequent request
without first revalidating it with the origin server. (I.e., the
cache must do an end-to-end revalidation every time, if, based solely
on the origin server's Expires or max-age value, the cached response
is stale.)
The must-revalidate directive is necessary to support reliable
operation for certain protocol features. In all circumstances an
HTTP/1.1 cache MUST obey the must-revalidate directive; in
particular, if the cache cannot reach the origin server for any
reason, it MUST generate a 504 (Gateway Timeout) response.
Servers should send the must-revalidate directive if and only if
failure to revalidate a request on the entity could result in
incorrect operation, such as a silently unexecuted financial
transaction. Recipients MUST NOT take any automated action that
violates this directive, and MUST NOT automatically provide an
unvalidated copy of the entity if revalidation fails.
Although this is not recommended, user agents operating under severe
connectivity constraints may violate this directive but, if so, MUST
explicitly warn the user that an unvalidated response has been
provided. The warning MUST be provided on each unvalidated access,
and SHOULD require explicit user confirmation.
The proxy-revalidate directive has the same meaning as the must-
revalidate directive, except that it does not apply to non-shared
user agent caches. It can be used on a response to an authenticated
request to permit the user's cache to store and later return the
response without needing to revalidate it (since it has already been
authenticated once by that user), while still requiring proxies that
service many users to revalidate each time (in order to make sure
that each user has been authenticated). Note that such authenticated
responses also need the public cache control directive in order to
allow them to be cached at all.
14.9.5 No-Transform Directive
Implementers of intermediate caches (proxies) have found it useful to
convert the media type of certain entity bodies. A proxy might, for
example, convert between image formats in order to save cache space
or to reduce the amount of traffic on a slow link. HTTP has to date
been silent on these transformations.
Serious operational problems have already occurred, however, when
these transformations have been applied to entity bodies intended for
certain kinds of applications. For example, applications for medical
imaging, scientific data analysis and those using end-to-end
authentication, all depend on receiving an entity body that is bit
for bit identical to the original entity-body.
Therefore, if a response includes the no-transform directive, an
intermediate cache or proxy MUST NOT change those headers that are
listed in section 13.5.2 as being subject to the no-transform
directive. This implies that the cache or proxy must not change any
aspect of the entity-body that is specified by these headers.
14.9.6 Cache Control Extensions
The Cache-Control header field can be extended through the use of one
or more cache-extension tokens, each with an optional assigned value.
Informational extensions (those which do not require a change in
cache behavior) may be added without changing the semantics of other
directives. Behavioral extensions are designed to work by acting as
modifiers to the existing base of cache directives. Both the new
directive and the standard directive are supplied, such that
applications which do not understand the new directive will default
to the behavior specified by the standard directive, and those that
understand the new directive will recognize it as modifying the
requirements associated with the standard directive. In this way,
extensions to the Cache-Control directives can be made without
requiring changes to the base protocol.
This extension mechanism depends on a HTTP cache obeying all of the
cache-control directives defined for its native HTTP-version, obeying
certain extensions, and ignoring all directives that it does not
understand.
For example, consider a hypothetical new response directive called
"community" which acts as a modifier to the "private" directive. We
define this new directive to mean that, in addition to any non-shared
cache, any cache which is shared only by members of the community
named within its value may cache the response. An origin server
wishing to allow the "UCI" community to use an otherwise private
response in their shared cache(s) may do so by including
Cache-Control: private, community="UCI"
A cache seeing this header field will act correctly even if the cache
does not understand the "community" cache-extension, since it will
also see and understand the "private" directive and thus default to
the safe behavior.
Unrecognized cache-directives MUST be ignored; it is assumed that any
cache-directive likely to be unrecognized by an HTTP/1.1 cache will
be combined with standard directives (or the response's default
cachability) such that the cache behavior will remain minimally
correct even if the cache does not understand the extension(s).
14.10 Connection
The Connection general-header field allows the sender to specify
options that are desired for that particular connection and MUST NOT
be communicated by proxies over further connections.
The Connection header has the following grammar:
Connection-header = "Connection" ":" 1#(connection-token)
connection-token = token
HTTP/1.1 proxies MUST parse the Connection header field before a
message is forwarded and, for each connection-token in this field,
remove any header field(s) from the message with the same name as the
connection-token. Connection options are signaled by the presence of
a connection-token in the 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
connection option. HTTP/1.1 defines the "close" connection option
for the sender to signal that the connection will be closed after
completion of the response. For example,
Connection: close
in either the request or the response header fields indicates that
the connection should not be considered `persistent' (section 8.1)
after the current request/response is complete.
HTTP/1.1 applications that do not support persistent connections MUST
include the "close" connection option in every message.
14.11 Content-Base
The Content-Base entity-header field may be used to specify the base
URI for resolving relative URLs within the entity. This header field
is described as Base in RFC1808, which is expected to be revised.
Content-Base = "Content-Base" ":" absoluteURI
If no Content-Base field is present, the base URI of an entity is
defined either by its Content-Location (if that Content-Location URI
is an absolute URI) or the URI used to initiate the request, in that
order of precedence. Note, however, that the base URI of the contents
within the entity-body may be redefined within that entity-body.
14.12 Content-Encoding
The Content-Encoding entity-header field is used as a modifier to the
media-type. When present, its value indicates what additional content
codings have been applied to the entity-body, and thus what decoding
mechanisms MUST be applied in order to obtain the media-type
referenced by the Content-Type header field. Content-Encoding is
primarily used to allow a document to be compressed without losing
the identity of its underlying media type.
Content-Encoding = "Content-Encoding" ":" 1#content-coding
Content codings are defined in section 3.5. An example of its use is
Content-Encoding: gzip
The Content-Encoding is a characteristic of the entity identified by
the Request-URI. Typically, the entity-body is stored with this
encoding and is only decoded before rendering or analogous usage.
If multiple encodings have been applied to an entity, the content
codings MUST be listed in the order in which they were applied.
Additional information about the encoding parameters MAY be provided
by other entity-header fields not defined by this specification.
14.13 Content-Language
The Content-Language entity-header field describes the natural
language(s) of the intended audience for the enclosed entity. Note
that this may not be equivalent to all the languages used within the
entity-body.
Content-Language = "Content-Language" ":" 1#language-tag
Language tags are defined in section 3.10. The primary purpose of
Content-Language is to allow a user to identify and differentiate
entities according to the user's own preferred language. Thus, if the
body content is intended only for a Danish-literate audience, the
appropriate field is
Content-Language: da
If no Content-Language is specified, the default is that the content
is intended for all language audiences. This may mean that the sender
does not consider it to be specific to any natural language, or that
the sender does not know for which language it is intended.
Multiple languages MAY be listed for content that is intended for
multiple audiences. For example, a rendition of the "Treaty of
Waitangi," presented simultaneously in the original Maori and English
versions, would call for
Content-Language: mi, en
However, just because multiple languages are present within an entity
does not mean that it is intended for multiple linguistic audiences.
An example would be a beginner's language primer, such as "A First
Lesson in Latin," which is clearly intended to be used by an
English-literate audience. In this case, the Content-Language should
only include "en".
Content-Language may be applied to any media type -- it is not
limited to textual documents.
14.14 Content-Length
The Content-Length entity-header field indicates the size of the
message-body, in decimal number of octets, sent to the recipient or,
in the case of the HEAD method, the size of the entity-body that
would have been sent had the request been a GET.
Content-Length = "Content-Length" ":" 1*DIGIT
An example is
Content-Length: 3495
Applications SHOULD use this field to indicate the size of the
message-body to be transferred, regardless of the media type of the
entity. It must be possible for the recipient to reliably determine
the end of HTTP/1.1 requests containing an entity-body, e.g., because
the request has a valid Content-Length field, uses Transfer-Encoding:
chunked or a multipart body.
Any Content-Length greater than or equal to zero is a valid value.
Section 4.4 describes how to determine the length of a message-body
if a Content-Length is not given.
Note: The meaning of this field is significantly different from the
corresponding definition in MIME, where it is an optional field
used within the "message/external-body" content-type. In HTTP, it
SHOULD be sent whenever the message's length can be determined
prior to being transferred.
14.15 Content-Location
The Content-Location entity-header field may be used to supply the
resource location for the entity enclosed in the message. In the case
where a resource has multiple entities associated with it, and those
entities actually have separate locations by which they might be
individually accessed, the server should provide a Content-Location
for the particular variant which is returned. In addition, a server
SHOULD provide a Content-Location for the resource corresponding to
the response entity.
Content-Location = "Content-Location" ":"
( absoluteURI | relativeURI )
If no Content-Base header field is present, the value of Content-
Location also defines the base URL for the entity (see section
14.11).
The Content-Location value is not a replacement for the original
requested URI; it is only a statement of the location of the resource
corresponding to this particular entity at the time of the request.
Future requests MAY use the Content-Location URI if the desire is to
identify the source of that particular entity.
A cache cannot assume that an entity with a Content-Location
different from the URI used to retrieve it can be used to respond to
later requests on that Content-Location URI. However, the Content-
Location can be used to differentiate between multiple entities
retrieved from a single requested resource, as described in section
13.6.
If the Content-Location is a relative URI, the URI is interpreted
relative to any Content-Base URI provided in the response. If no
Content-Base is provided, the relative URI is interpreted relative to
the Request-URI.
14.16 Content-MD5
The Content-MD5 entity-header field, as defined in RFC1864 [23], is
an MD5 digest of the entity-body for the purpose of providing an
end-to-end message integrity check (MIC) of the entity-body. (Note: a
MIC is good for detecting accidental modification of the entity-body
in transit, but is not proof against malicious attacks.)
Content-MD5 = "Content-MD5" ":" md5-digest
md5-digest = <base64 of 128 bit MD5 digest as per RFC1864>
The Content-MD5 header field may be generated by an origin server to
function as an integrity check of the entity-body. Only origin
servers may generate the Content-MD5 header field; proxies and
gateways MUST NOT generate it, as this would defeat its value as an
end-to-end integrity check. Any recipient of the entity-body,
including gateways and proxies, MAY check that the digest value in
this header field matches that of the entity-body as received.
The MD5 digest is computed based on the content of the entity-body,
including any Content-Encoding that has been applied, but not
including any Transfer-Encoding that may have been applied to the
message-body. If the message is received with a Transfer-Encoding,
that encoding must be removed prior to checking the Content-MD5 value
against the received entity.
This has the result that the digest is computed on the octets of the
entity-body exactly as, and in the order that, they would be sent if
no Transfer-Encoding were being applied.
HTTP extends RFC1864 to permit the digest to be computed for MIME
composite media-types (e.g., multipart/* and message/rfc822), but
this does not change how the digest is computed as defined in the
preceding paragraph.
Note: There are several consequences of this. The entity-body for
composite types may contain many body-parts, each with its own MIME
and HTTP headers (including Content-MD5, Content-Transfer-Encoding,
and Content-Encoding headers). If a body-part has a Content-
Transfer-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 included in the Content-MD5 digest as is -- i.e.,
after the application. The Transfer-Encoding header field is not
allowed within body-parts.
Note: while the definition of Content-MD5 is exactly the same for
HTTP as in RFC1864 for MIME entity-bodies, there are several ways
in which the application of Content-MD5 to HTTP entity-bodies
differs from its application to MIME entity-bodies. One is that
HTTP, unlike MIME, does not use Content-Transfer-Encoding, and does
use Transfer-Encoding and Content-Encoding. Another is that HTTP
more frequently uses binary content types than MIME, so it is worth
noting that, in such cases, the byte order used to compute the
digest is the transmission byte order defined for the type. Lastly,
HTTP allows transmission of text types with any of several line
break conventions and not just the canonical form using CRLF.
Conversion of all line breaks to CRLF should not be done before
computing or checking the digest: the line break convention used in
the text actually transmitted should be left unaltered when
computing the digest.
14.17 Content-Range
The Content-Range entity-header is sent with a partial entity-body to
specify where in the full entity-body the partial body should be
inserted. It also indicates the total size of the full entity-body.
When a server returns a partial response to a client, it must
describe both the extent of the range covered by the response, and
the length of the entire entity-body.
Content-Range = "Content-Range" ":" content-range-spec