Source: https://trac.ietf.org/trac/httpbis/browser/draft-ietf-httpbis/latest/p6-cache.html?rev=750
Timestamp: 2020-01-28 22:03:07
Document Index: 22082926

Matched Legal Cases: ['art7', 'art7', 'art 7', 'art7', 'art1', 'art1', 'art 1', 'art1', 'art1', 'art1', 'art 1', 'art1', 'art7', 'art7', 'art 7', 'art7', 'art 1', 'art 2', 'art 3', 'art 4', 'art 5', 'art 7', 'art1', 'art1', 'art 1', 'art1', 'art3', 'art3', 'art 3', 'art3', 'art5', 'art5', 'art 5', 'art5', 'art1']

source: draft-ietf-httpbis/latest/p6-cache.html @ 750
Last change on this file since 750 was 741, checked in by julian.reschke@…, 10 years ago
<meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.497, 2009-12-30 19:57:37, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
<meta name="DC.Date.Issued" scheme="ISO8601" content="2010-01-01">
<td class="left">Expires: July 5, 2010</td>
<td class="right">January 1, 2010</td>
<p>The changes in this draft are summarized in <a href="#changes.since.08" title="Since draft-ietf-httpbis-p6-cache-08">Appendix&nbsp;C.10</a>.
<p>This Internet-Draft will expire in July 5, 2010.</p>
<li>A protocol element (e.g., an entity tag or a Last-Modified time) that is used to find out whether a stored response is an
<li>the "Authorization" header (see <a href="p7-auth.html#header.authorization" title="Authorization">Section 3.1</a> of <a href="#Part7" id="rfc.xref.Part7.1"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>) does not appear in the request, if the cache is shared (unless the "public" directive is present; see <a href="#header.cache-control" id="rfc.xref.header.cache-control.2" title="Cache-Control">Section&nbsp;3.2</a>), and
for this. (see &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/196">http://tools.ietf.org/wg/httpbis/trac/ticket/196</a>&gt;)]</span>), and
<li>the presented request and stored response are free from directives that would prevent its use (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.3" title="Cache-Control">Section&nbsp;3.2</a> and <a href="#header.pragma" id="rfc.xref.header.pragma.1" title="Pragma">Section&nbsp;3.4</a>), and
using either the Expires header (<a href="#header.expires" id="rfc.xref.header.expires.2" title="Expires">Section&nbsp;3.3</a>) or the max-age response cache directive (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>). Generally, origin servers will assign future explicit expiration times to responses in the belief that the entity is not
was generated (see <a href="p1-messaging.html#header.date" title="Date">Section 9.3</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The term "date_value" denotes the value of the Date header, in a form appropriate for arithmetic operations.
name following the rules about header fields in <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
<p id="rfc.section.2.7.p.2">If the new response contains an ETag, it identifies the stored response to use. <span class="comment" id="rfc.comment.9">[<a href="#rfc.comment.9" class="smpl">rfc.comment.9</a>: may need language about Content-Location here]</span><span class="comment" id="rfc.comment.10">[<a href="#rfc.comment.10" class="smpl">rfc.comment.10</a>: cover case where INM with multiple etags was sent]</span>
<p id="rfc.section.2.7.p.6">The updated response can [[<span class="comment" id="rfc.comment.11">[<a href="#rfc.comment.11" class="smpl">rfc.comment.11</a>: requirement?]</span>]] be used to replace the stored response in cache. In the case of a 206 response, the combined entity-body <em class="bcp14">MAY</em> be stored.
<p id="rfc.section.2.7.p.7"> <span class="comment" id="rfc.comment.12">[<a href="#rfc.comment.12" class="smpl">rfc.comment.12</a>: ISSUE: discuss how to handle HEAD updates]</span>
<p id="rfc.section.3.2.p.1">The "Cache-Control" general-header field is used to specify directives that <em class="bcp14">MUST</em> be obeyed by all caches along the request/response chain. Such cache directives are unidirectional in that the presence of
a directive in a request does not imply that the same directive is to be given in the response.
a stale response of any age. <span class="comment" id="rfc.comment.13">[<a href="#rfc.comment.13" class="smpl">rfc.comment.13</a>: of any staleness? --mnot]</span></li>
<li>The no-transform request directive indicates that an intermediate cache or proxy <em class="bcp14">MUST NOT</em> change the Content-Encoding, Content-Range or Content-Type request headers, nor the request entity-body.
<li>The public response directive indicates that the response <em class="bcp14">MAY</em> be cached, even if it would normally be non-cacheable or cacheable only within a non-shared cache. (See also Authorization, <a href="p7-auth.html#header.authorization" title="Authorization">Section 3.1</a> of <a href="#Part7" id="rfc.xref.Part7.2"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, for additional details.)
<li> <b>Note:</b> This usage of the word private only controls where the response may be stored, and cannot ensure the privacy of the message
<li>Servers <em class="bcp14">SHOULD</em> send the must-revalidate directive if and only if failure to validate a request on the entity could result in incorrect operation,
<li>The no-transform response directive indicates that an intermediate cache or proxy <em class="bcp14">MUST NOT</em> change the Content-Encoding, Content-Range or Content-Type response headers, nor the response entity-body.
<p id="rfc.section.3.5.p.2">Caches use this information, in part, to determine whether a stored response can be used to satisfy a given request; see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.6</a>. determines, while the response is fresh, whether a cache is permitted to use the response to reply to a subsequent request
without validation; see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.6</a>.
<li>2xx Warnings describe some aspect of the entity body or entity headers that is not rectified by a validation (for example,
<li><em class="bcp14">MUST</em> be added by an intermediate cache or proxy if it applies any transformation changing the content-coding (as specified in the
<td class="left"> <a href="#header.age" id="rfc.xref.header.age.2" title="Age">Section&nbsp;3.1</a>
<td class="left"> <a href="#header.cache-control" id="rfc.xref.header.cache-control.4" title="Cache-Control">Section&nbsp;3.2</a>
<td class="top"><a href="mailto:fielding@gbiv.com" title="Day Software">Fielding, R., Ed.</a>, <a href="mailto:jg@laptop.org" title="One Laptop per Child">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems, Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. F. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-latest">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p1-messaging-latest (work in progress), January&nbsp;2010.
<td class="top"><a href="mailto:fielding@gbiv.com" title="Day Software">Fielding, R., Ed.</a>, <a href="mailto:jg@laptop.org" title="One Laptop per Child">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems, Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. F. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-latest">HTTP/1.1, part 2: Message Semantics</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p2-semantics-latest (work in progress), January&nbsp;2010.
<td class="top"><a href="mailto:fielding@gbiv.com" title="Day Software">Fielding, R., Ed.</a>, <a href="mailto:jg@laptop.org" title="One Laptop per Child">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems, Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. F. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-latest">HTTP/1.1, part 3: Message Payload and Content Negotiation</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p3-payload-latest (work in progress), January&nbsp;2010.
<td class="top"><a href="mailto:fielding@gbiv.com" title="Day Software">Fielding, R., Ed.</a>, <a href="mailto:jg@laptop.org" title="One Laptop per Child">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems, Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. F. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-latest">HTTP/1.1, part 4: Conditional Requests</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p4-conditional-latest (work in progress), January&nbsp;2010.
<td class="top"><a href="mailto:fielding@gbiv.com" title="Day Software">Fielding, R., Ed.</a>, <a href="mailto:jg@laptop.org" title="One Laptop per Child">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems, Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. F. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-latest">HTTP/1.1, part 5: Range Requests and Partial Responses</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p5-range-latest (work in progress), January&nbsp;2010.
<td class="top"><a href="mailto:fielding@gbiv.com" title="Day Software">Fielding, R., Ed.</a>, <a href="mailto:jg@laptop.org" title="One Laptop per Child">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems, Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. F. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-latest">HTTP/1.1, part 7: Authentication</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p7-auth-latest (work in progress), January&nbsp;2010.
<p id="rfc.section.A.1.p.1">A case was missed in the Cache-Control model of HTTP/1.1; s-maxage was introduced to add this missing case. (Sections <a href="#response.cacheability" title="Response Cacheability">2.1</a>, <a href="#header.cache-control" id="rfc.xref.header.cache-control.5" title="Cache-Control">3.2</a>).
computed. (see also <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> and <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) <span class="comment" id="rfc.comment.14">[<a href="#rfc.comment.14" class="smpl">rfc.comment.14</a>: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span>
<p id="rfc.section.A.1.p.3">Proxies should be able to add Content-Length when appropriate. <span class="comment" id="rfc.comment.15">[<a href="#rfc.comment.15" class="smpl">rfc.comment.15</a>: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span>
<p id="rfc.section.A.1.p.6">Warnings could be cached incorrectly, or not updated appropriately. (Section <a href="#expiration.model" title="Freshness Model">2.3</a>, <a href="#combining.headers" title="Combining Responses">2.7</a>, <a href="#header.cache-control" id="rfc.xref.header.cache-control.6" title="Cache-Control">3.2</a>, and <a href="#header.warning" id="rfc.xref.header.warning.4" title="Warning">3.6</a>) Warning also needed to be a general header, as PUT or other methods may have need for it in requests.
<p id="rfc.section.A.2.p.1">Remove requirement to consider Content-Location in successful responses in order to determine the appropriate response to
<p id="rfc.section.A.2.p.2">Clarify denial of service attack avoidance requirement. (<a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section&nbsp;2.5</a>)
<p id="rfc.section.A.2.p.3">Do not mention RFC 2047 encoding and multiple languages in Warning headers anymore, as these aspects never were implemented.
<li class="indline1">Cache-Control header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.cache-control.1">2.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.2">2.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.3">2.2</a>, <a class="iref" href="#rfc.iref.c.3"><b>3.2</b></a>, <a class="iref" href="#rfc.xref.header.cache-control.4">5.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.5">A.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.6">A.1</a></li>
<li class="indline1">Expires header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.expires.1">2.1</a>, <a class="iref" href="#rfc.xref.header.expires.2">2.3</a>, <a class="iref" href="#rfc.xref.header.expires.3">2.3.1</a>, <a class="iref" href="#rfc.iref.e.2"><b>3.3</b></a>, <a class="iref" href="#rfc.xref.header.expires.4">5.1</a></li>
<li class="indline1">Cache-Control&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.cache-control.1">2.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.2">2.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.3">2.2</a>, <a class="iref" href="#rfc.iref.h.3"><b>3.2</b></a>, <a class="iref" href="#rfc.xref.header.cache-control.4">5.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.5">A.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.6">A.1</a></li>
<li class="indline1">Expires&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.expires.1">2.1</a>, <a class="iref" href="#rfc.xref.header.expires.2">2.3</a>, <a class="iref" href="#rfc.xref.header.expires.3">2.3.1</a>, <a class="iref" href="#rfc.iref.h.4"><b>3.3</b></a>, <a class="iref" href="#rfc.xref.header.expires.4">5.1</a></li>
<li class="indline1">Warning&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.warning.1">2.3.3</a>, <a class="iref" href="#rfc.xref.header.warning.2">2.7</a>, <a class="iref" href="#rfc.iref.h.7"><b>3.6</b></a>, <a class="iref" href="#rfc.xref.header.warning.3">5.1</a>, <a class="iref" href="#rfc.xref.header.warning.4">A.1</a>, <a class="iref" href="#rfc.xref.header.warning.5">A.2</a></li>
<li class="indline1"><em>Section 9.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.11">2.3.2</a></li>
<li class="indline1">Warning header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.warning.1">2.3.3</a>, <a class="iref" href="#rfc.xref.header.warning.2">2.7</a>, <a class="iref" href="#rfc.iref.w.1"><b>3.6</b></a>, <a class="iref" href="#rfc.xref.header.warning.3">5.1</a>, <a class="iref" href="#rfc.xref.header.warning.4">A.1</a>, <a class="iref" href="#rfc.xref.header.warning.5">A.2</a></li>