Source: https://greenbytes.com/tech/webdav/draft-ietf-httpbis-p6-cache-06.html
Timestamp: 2020-01-24 22:27:13
Document Index: 148538742

Matched Legal Cases: ['art4', 'art3', 'art1', 'art5', 'art1', 'art 7', 'art1', 'art3', 'art5']

[rfc.comment.2: TODO: define method cacheability for GET, HEAD and POST in p2-semantics.] ¶
When a stored response is used to satisfy a request, caches MUST include a single Age header field Section 3.1 in the response with a value equal to the stored response's current_age; see Section 2.3.2. [rfc.comment.3: DISCUSS: this currently includes successfully validated responses.] ¶
[rfc.comment.4: TODO: end-to-end and hop-by-hop headers, non-modifiable headers removed; re-spec in p1] ¶
If an origin server wishes to force a cache to validate every request, it can assign an explicit expiration time in the past. This means that the response is always stale, so that caches should validate it before using it for subsequent requests. [rfc.comment.5: This wording may cause confusion, because the response may still be served stale.] ¶
[rfc.comment.6: ISSUE: there are not requirements directly applying to cache-request-directives and freshness.] ¶
[rfc.comment.7: REVIEW: took away HTTP/1.0 query string heuristic uncacheability.] ¶
Checking with the origin server to see if a stale or otherwise unusable cached response can be reused is called "validating" or "revalidating." Doing so potentially avoids the overhead of retransmitting the response body when the stored response is valid.¶
HTTP's conditional request mechanism [Part4] is used for this purpose. When a stored response includes one or more validators, such as the field values of an ETag or Last-Modified header field, then a validating request SHOULD be made conditional to those field values.¶
If instead the cache receives a full response (i.e., one with a response body), it is used to satisfy the request and replace the stored response. [rfc.comment.8: Should there be a requirement here?] ¶
If a cache receives a 5xx response while attempting to validate a response, 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 stored response (which SHOULD include the 111 warn-code; see Section 3.6) unless the stored response includes the "must-revalidate" cache directive (see Section 2.3.3).¶
The following HTTP methods MUST cause a cache to invalidate the Request-URI as well as the Location and Content-Location headers (if present): ¶
[rfc.comment.9: TODO: "host part" needs to be specified better.] ¶
[rfc.comment.10: TODO: specify that only successful (2xx, 3xx?) responses invalidate.] ¶
Use of server-driven content negotiation (Section 4.1 of [Part3] ) alters the conditions under which a cache can use the response for subsequent requests.¶
When a cache receives a request that can be satisfied by a stored response that includes a Vary header field (Section 3.5), it MUST NOT use that response unless all of the selecting request-headers in the presented request match the corresponding stored request-headers from the original request.¶
The selecting request-headers from two requests are defined to match if and only if the selecting request-headers in the first request can be transformed to the selecting request-headers in the second request by adding or removing linear white space [rfc.comment.11: [ref]] at places where this is allowed by the corresponding ABNF, and/or combining multiple message-header fields with the same field name following the rules about message headers in Section 4.2 of [Part1] . [rfc.comment.12: DISCUSS: header-specific canonicalisation] ¶
If no stored response matches, the cache MAY forward the presented request to the origin server in a conditional request, and SHOULD include all ETags stored with potentially suitable responses in an If-None-Match request header. If the server responds with 304 (Not Modified) and includes an entity tag or Content-Location that indicates the entity to be used, that cached response MUST be used to satisfy the presented request, and SHOULD be used to update the corresponding stored response; see Section 2.7.¶
If any of the stored responses contains only partial content, its entity-tag SHOULD NOT be included in the If-None-Match header field unless the request is for a range that would be fully satisfied by that stored response.¶
If a cache receives a successful response whose Content-Location field matches that of an existing stored response for the same Request-URI, whose entity-tag differs from that of the existing stored response, and whose Date is more recent than that of the existing response, the existing response SHOULD NOT be returned in response to future requests and SHOULD be deleted from the cache.[rfc.comment.13: DISCUSS: Not sure if this is necessary.] ¶
When a cache receives a 304 (Not Modified) response or a 206 (Partial Content) response, it needs to update the stored response with the new one, so that the updated response can be sent to the client.¶
If the status code is 304 (Not Modified), the cache SHOULD use the stored entity-body as the updated entity-body. If the status code is 206 (Partial Content) and the ETag or Last-Modified headers match exactly, the cache MAY combine the stored entity-body in the stored response with the updated entity-body received in the response and use the result as the updated entity-body (see Section 4 of [Part5] ).¶
The stored response headers are used for the updated response, except that ¶
A cache MUST also replace any stored headers with corresponding headers received in the incoming response, except for Warning headers as described immediately above. If a header field-name in the incoming response matches more than one header in the stored response, all such old headers MUST be replaced. It MAY store the combined entity-body.¶
[rfc.comment.14: ISSUE: discuss how to handle HEAD updates] ¶
Age field-values are non-negative decimal integers, representing time in seconds.¶
The field-value is an absolute date and time as defined by HTTP-date in Section 3.2.1 of [Part1] ; it MUST be sent in rfc1123-date format.¶
Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., and J. Reschke, Ed., “HTTP/1.1, part 7: Authentication”, Internet-Draft draft-ietf-httpbis-p7-auth-06 (work in progress), March 2009.
Transfer-coding and message lengths all interact in ways that required fixing exactly when chunked encoding is used (to allow for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are computed. (see also [Part1] , [Part3] and [Part5] ) [rfc.comment.16: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre] ¶
Proxies should be able to add Content-Length when appropriate. [rfc.comment.17: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre] ¶