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.