Fielding, et. al. Standards Track [Page 85]
RFC 2068 HTTP/1.1 January 1997
o If only a Last-Modified value has been provided by the origin
server, SHOULD use that value in non-subrange cache-conditional
requests (using If-Modified-Since).
o If only a Last-Modified value has been provided by an HTTP/1.0
origin server, MAY use that value in subrange cache-conditional
requests (using If-Unmodified-Since:). The user agent should
provide a way to disable this, in case of difficulty.
o If both an entity tag and a Last-Modified value have been
provided by the origin server, SHOULD use both validators in
cache-conditional requests. This allows both HTTP/1.0 and
HTTP/1.1 caches to respond appropriately.
An HTTP/1.1 cache, upon receiving a request, MUST use the most
restrictive validator when deciding whether the client's cache entry
matches the cache's own cache entry. This is only an issue when the
request contains both an entity tag and a last-modified-date
validator (If-Modified-Since or If-Unmodified-Since).
A note on rationale: The general principle behind these rules is
that HTTP/1.1 servers and clients should transmit as much non-
redundant information as is available in their responses and
requests. HTTP/1.1 systems receiving this information will make the
most conservative assumptions about the validators they receive.
HTTP/1.0 clients and caches will ignore entity tags. Generally,
last-modified values received or used by these systems will support
transparent and efficient caching, and so HTTP/1.1 origin servers
should provide Last-Modified values. In those rare cases where the
use of a Last-Modified value as a validator by an HTTP/1.0 system
could result in a serious problem, then HTTP/1.1 origin servers
should not provide one.
13.3.5 Non-validating Conditionals
The principle behind entity tags is that only the service author
knows the semantics of a resource well enough to select an
appropriate cache validation mechanism, and the specification of any
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) are never
used for purposes of validating a cache entry.
13.4 Response Cachability
Unless specifically constrained by a Cache-Control (section 14.9)
directive, a caching system may always store a successful response
(see section 13.8) as a cache entry, may return it without validation
if it is fresh, and may return it after successful validation. If
Fielding, et. al. Standards Track [Page 86]
RFC 2068 HTTP/1.1 January 1997
there is neither a cache validator nor an explicit expiration time
associated with a response, we do not expect it to be cached, but
certain caches may violate this expectation (for example, when little
or no network connectivity is available). A client can usually detect
that such a response was taken from a cache by comparing the Date
header to the current time.
Note that some HTTP/1.0 caches are known to violate this
expectation without providing any Warning.
However, in some cases it may be inappropriate for a cache to retain
an entity, or to return it in response to a subsequent request. This
may be because absolute semantic transparency is deemed necessary by
the service author, or because of security or privacy considerations.
Certain Cache-Control directives are therefore provided so that the
server can indicate that certain resource entities, or portions
thereof, may not be cached regardless of other considerations.
Note that section 14.8 normally prevents a shared cache from saving
and returning a response to a previous request if that request
included an Authorization header.
A response received with a status code of 200, 203, 206, 300, 301 or
410 may be stored by a cache and used in reply to a subsequent
request, subject to the expiration mechanism, unless a Cache-Control
directive prohibits caching. However, a cache that does not support
the Range and Content-Range headers MUST NOT cache 206 (Partial
Content) responses.
A response received with any other status code 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 (section
14.21); a "max-age", "must-revalidate", "proxy-revalidate", "public"
or "private" Cache-Control directive (section 14.9).
13.5 Constructing Responses From Caches
The purpose of an HTTP cache is to store information received in
response to requests, for use in responding to future requests. In
many cases, a cache simply returns the appropriate parts of a
response to the requester. However, if the cache holds a cache entry
based on a previous response, it may have to combine parts of a new
response with what is held in the cache entry.
Fielding, et. al. Standards Track [Page 87]
RFC 2068 HTTP/1.1 January 1997
13.5.1 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 headers, which must be 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 transmitted in any response formed from a cache entry.
o Hop-by-hop headers, which are meaningful only for a single
transport-level connection, and are not stored by caches or
forwarded by proxies.
The following HTTP/1.1 headers are hop-by-hop headers:
o Connection
o Keep-Alive
o Public
o Proxy-Authenticate
o Transfer-Encoding
o Upgrade
All other headers defined by HTTP/1.1 are end-to-end headers.
Hop-by-hop headers introduced in future versions of HTTP MUST be
listed in a Connection header, as described in section 14.10.
13.5.2 Non-modifiable Headers
Some features of the HTTP/1.1 protocol, such as Digest
Authentication, depend on the value of certain end-to-end headers. A
cache or non-caching proxy SHOULD NOT modify an end-to-end header
unless the definition of that header requires or specifically allows
that.
A cache or non-caching proxy MUST NOT modify any of the following
fields in a request or response, nor may it add any of these fields
if not already present:
o Content-Location
o ETag
o Expires
o Last-Modified
Fielding, et. al. Standards Track [Page 88]
RFC 2068 HTTP/1.1 January 1997
A cache or non-caching proxy MUST NOT modify or add any of the
following fields in a response that contains the no-transform Cache-
Control directive, or in any request:
o Content-Encoding
o Content-Length
o Content-Range
o Content-Type
A cache or non-caching proxy MAY modify or add these fields in a
response that does not include no-transform, but if it does so, it
MUST add a Warning 14 (Transformation applied) if one does not
already appear in the response.
Warning: unnecessary modification of end-to-end headers may cause
authentication failures if stronger authentication mechanisms are
introduced in later versions of HTTP. Such authentication
mechanisms may rely on the values of header fields not listed here.
13.5.3 Combining Headers
When a cache makes a validating request to a server, and the server
provides a 304 (Not Modified) response, the cache must construct a
response to send to the requesting client. The cache uses the
entity-body stored in the cache entry as the 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
headers provided in the 304 response MUST replace the corresponding
headers from the cache entry. Unless the cache decides to remove the
cache entry, it MUST also replace the end-to-end 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
stored with the cache entry. The cache may add Warning headers (see
section 14.45) to this set.
If a header field-name in the incoming response matches more than one
header in the cache entry, all such old headers are replaced.
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.
Fielding, et. al. Standards Track [Page 89]
RFC 2068 HTTP/1.1 January 1997
13.5.4 Combining Byte Ranges
A response may transfer only a subrange of the bytes of an entity-
body, either because the request included one or more Range
specifications, or because a connection was broken prematurely. After
several such transfers, a cache may have received several ranges of
the same entity-body.
If a cache has a stored non-empty set of subranges for an entity, and
an incoming response transfers another subrange, the cache MAY
combine the new subrange with the existing set if both the following
conditions are met:
o Both the incoming response and the cache entry must have a cache
validator.
o The two cache validators must match using the strong comparison
function (see section 13.3.3).
If either requirement is not meant, the cache must use only the most
recent partial response (based on the Date values transmitted with
every response, and using the incoming response if these values are
equal or missing), and must discard the other partial information.
13.6 Caching Negotiated Responses
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 dimensions are used to select among
multiple representations of a cachable response. A cache may use the
selected representation (the entity included with that particular
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 would
be forwarded toward the origin server.
If an entity tag was assigned to the representation, the forwarded
request SHOULD be conditional and include the entity tags in an If-
None-Match header field from all its cache entries for the Request-
URI. This conveys to the server the set of entities currently held by
the 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
entity-tag of the new response matches that of an existing entry, the
Fielding, et. al. Standards Track [Page 90]
RFC 2068 HTTP/1.1 January 1997
new response SHOULD be used to update the header fields of the
existing entry, and the result MUST be returned to the client.
The Vary header field may also inform 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 cache relays the new request
to the origin server in a conditional request and the server responds
with 304 (Not Modified), including an entity tag or Content-Location
that indicates which entity should be used.
If any of the existing cache entries contains only partial content
for the associated entity, its entity-tag SHOULD NOT be included in
the If-None-Match header unless the request is for a range that would
be fully satisfied by that entry.
If a cache receives a successful response whose Content-Location
field matches that of an existing cache entry for the same Request-
URI, whose entity-tag differs from that of the existing entry, and
whose Date is more recent than that of the existing entry, the
existing entry SHOULD NOT be returned in response to future requests,
and should be deleted from the cache.
13.7 Shared and Non-Shared Caches
For reasons of security and privacy, it is necessary to make a
distinction between "shared" and "non-shared" caches. A non-shared
cache is one that is accessible only to a single user. Accessibility
in this case SHOULD be enforced by appropriate security mechanisms.
All other caches are considered to be "shared." Other sections of
this specification place certain constraints on the operation of
shared caches in order to prevent loss of privacy or failure of
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,
Fielding, et. al. Standards Track [Page 91]
RFC 2068 HTTP/1.1 January 1997
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.
Fielding, et. al. Standards Track [Page 92]
RFC 2068 HTTP/1.1 January 1997
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.
Fielding, et. al. Standards Track [Page 93]
RFC 2068 HTTP/1.1 January 1997
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.
Fielding, et. al. Standards Track [Page 94]
RFC 2068 HTTP/1.1 January 1997
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."
Fielding, et. al. Standards Track [Page 95]
RFC 2068 HTTP/1.1 January 1997
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,
Fielding, et. al. Standards Track [Page 96]
RFC 2068 HTTP/1.1 January 1997
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.
Fielding, et. al. Standards Track [Page 97]
RFC 2068 HTTP/1.1 January 1997
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
Fielding, et. al. Standards Track [Page 98]
RFC 2068 HTTP/1.1 January 1997
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.
Fielding, et. al. Standards Track [Page 99]
RFC 2068 HTTP/1.1 January 1997
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.
谁翻译了别忘了给我发一份 xzjxu@126.com
