Ignore:
Timestamp:
Jul 24, 2010, 8:27:25 AM (9 years ago)
Author:
julian.reschke@…
Message:

regen HTML

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p6-cache.html

    r931 r939  
    780780         </li>
    781781      </ul>
    782       <p id="rfc.section.2.2.p.2">When a stored response is used to satisfy a request, caches <em class="bcp14">MUST</em> include a single Age header field (<a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section&nbsp;3.1</a>) in the response with a value equal to the stored response's current_age; see <a href="#age.calculations" title="Calculating Age">Section&nbsp;2.3.2</a>. <span class="comment" id="DISCUSS-includes-validated">[<a href="#DISCUSS-includes-validated" class="smpl">DISCUSS-includes-validated</a>: this currently includes successfully validated responses.]</span>
     782      <p id="rfc.section.2.2.p.2">When a stored response is used to satisfy a request without validation, caches <em class="bcp14">MUST</em> include a single Age header field (<a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section&nbsp;3.1</a>) in the response with a value equal to the stored response's current_age; see <a href="#age.calculations" title="Calculating Age">Section&nbsp;2.3.2</a>.
    783783      </p>
    784784      <p id="rfc.section.2.2.p.3">Requests with methods that are unsafe (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) <em class="bcp14">MUST</em> be written through the cache to the origin server; i.e., a cache must not reply to such a request before having forwarded
     
    948948      <p id="rfc.section.2.5.p.3">An invalidation based on a URI from a Location or Content-Location header <em class="bcp14">MUST NOT</em> be performed if the host part of that URI differs from the host part in the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). This helps prevent denial of service attacks.
    949949      </p>
    950       <p id="rfc.section.2.5.p.4"> <span class="comment" id="TODO-def-host-part">[<a href="#TODO-def-host-part" class="smpl">TODO-def-host-part</a>: "host part" needs to be specified better.]</span>
    951       </p>
    952       <p id="rfc.section.2.5.p.5">A cache that passes through requests for methods it does not understand <em class="bcp14">SHOULD</em> invalidate the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    953       </p>
    954       <p id="rfc.section.2.5.p.6">Here, "invalidate" means that the cache will either remove all stored responses related to the Effective Request URI, or will
     950      <p id="rfc.section.2.5.p.4">A cache that passes through requests for methods it does not understand <em class="bcp14">SHOULD</em> invalidate the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     951      </p>
     952      <p id="rfc.section.2.5.p.5">Here, "invalidate" means that the cache will either remove all stored responses related to the Effective Request URI, or will
    955953         mark these as "invalid" and in need of a mandatory validation before they can be returned in response to a subsequent request.
    956954      </p>
    957       <p id="rfc.section.2.5.p.7">Note that this does not guarantee that all appropriate responses are invalidated. For example, the request that caused the
     955      <p id="rfc.section.2.5.p.6">Note that this does not guarantee that all appropriate responses are invalidated. For example, the request that caused the
    958956         change at the origin server might not have gone through the cache where a response is stored.
    959       </p>
    960       <p id="rfc.section.2.5.p.8"> <span class="comment" id="TODO-spec-success-invalidate">[<a href="#TODO-spec-success-invalidate" class="smpl">TODO-spec-success-invalidate</a>: specify that only successful (2xx, 3xx?) responses invalidate.]</span>
    961957      </p>
    962958      <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a>&nbsp;<a id="caching.authenticated.responses" href="#caching.authenticated.responses">Shared Caching of Authenticated Responses</a></h2>
     
    996992      <p id="rfc.section.2.8.p.1">When a cache receives a 304 (Not Modified) response or a 206 (Partial Content) response (in this section, the "new" response"),
    997993         it needs to created an updated response by combining the stored response with the new one, so that the updated response can
    998          be used to satisfy the request.
    999       </p>
    1000       <p id="rfc.section.2.8.p.2">If the new response contains an ETag, it identifies the stored response to use. <span class="comment" id="TODO-mention-CL">[<a href="#TODO-mention-CL" class="smpl">TODO-mention-CL</a>: might need language about Content-Location here]</span>
    1001       </p>
    1002       <p id="rfc.section.2.8.p.3">If the status code is 206 (partial content), both the stored and new responses <em class="bcp14">MUST</em> have validators, and those validators <em class="bcp14">MUST</em> match using the strong comparison function (see <a href="p4-conditional.html#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). Otherwise, the responses <em class="bcp14">MUST NOT</em> be combined.
     994         be used to satisfy the request, and potentially update the cached response.
     995      </p>
     996      <p id="rfc.section.2.8.p.2">If the new response contains an ETag, it identifies the stored response to use. <span class="comment" id="TODO-mention-CL">[<a href="#TODO-mention-CL" class="smpl">TODO-mention-CL</a>: might need language about Content-Location here]</span><span class="comment" id="TODO-select-for-combine">[<a href="#TODO-select-for-combine" class="smpl">TODO-select-for-combine</a>: Shouldn't this be the selected response?]</span>
     997      </p>
     998      <p id="rfc.section.2.8.p.3">If the new response's status code is 206 (partial content), both the stored and new responses <em class="bcp14">MUST</em> have validators, and those validators <em class="bcp14">MUST</em> match using the strong comparison function (see <a href="p4-conditional.html#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). Otherwise, the responses <em class="bcp14">MUST NOT</em> be combined.
    1003999      </p>
    10041000      <p id="rfc.section.2.8.p.4">The stored response headers are used as those of the updated response, except that </p>
    10051001      <ul>
    1006          <li>any stored Warning headers with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section&nbsp;3.6</a>) <em class="bcp14">MUST</em> be deleted from the stored response and the updated response.
    1007          </li>
    1008          <li>any stored Warning headers with warn-code 2xx <em class="bcp14">MUST</em> be retained in the stored response and the updated response.
    1009          </li>
    1010          <li>any headers provided in the new response <em class="bcp14">MUST</em> replace the corresponding headers from the stored response.
    1011          </li>
    1012       </ul>
    1013       <p id="rfc.section.2.8.p.5">If a header field-name in the new response matches more than one header in the stored response, all such stored headers <em class="bcp14">MUST</em> be replaced.
    1014       </p>
    1015       <p id="rfc.section.2.8.p.6">The updated response can <span class="comment" id="TODO-is-req">[<a href="#TODO-is-req" class="smpl">TODO-is-req</a>: requirement?]</span> be used to replace the stored response in cache. In the case of a 206 response, the combined representation <em class="bcp14">MAY</em> be stored.
     1002         <li>any stored Warning headers with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section&nbsp;3.6</a>) <em class="bcp14">MUST</em> be deleted.
     1003         </li>
     1004         <li>any stored Warning headers with warn-code 2xx <em class="bcp14">MUST</em> be retained.
     1005         </li>
     1006         <li>any other headers provided in the new response <em class="bcp14">MUST</em> replace all instances of the corresponding headers from the stored response.
     1007         </li>
     1008      </ul>
     1009      <p id="rfc.section.2.8.p.5">The updated response headers <em class="bcp14">MUST</em> be used to replace those of the stored response in cache (unless the stored response is removed from cache). In the case of
     1010         a 206 response, the combined representation <em class="bcp14">MAY</em> be stored.
    10161011      </p>
    10171012      <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
     
    11011096            time. If max-stale is assigned a value, then the client is willing to accept a response that has exceeded its expiration time
    11021097            by no more than the specified number of seconds. If no value is assigned to max-stale, then the client is willing to accept
    1103             a stale response of any age. <span class="comment" id="TODO-staleness">[<a href="#TODO-staleness" class="smpl">TODO-staleness</a>: of any staleness? --mnot]</span></li>
     1098            a stale response of any age.
     1099         </li>
    11041100      </ul>
    11051101      <p id="rfc.section.3.2.1.p.6"> <dfn>min-fresh</dfn>  <span id="rfc.iref.c.8"></span>  <span id="rfc.iref.m.3"></span> 
     
    19071903         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/223">http://tools.ietf.org/wg/httpbis/trac/ticket/223</a>&gt;: "Allowing heuristic caching for new status codes"
    19081904         </li>
     1905         <li>Clean up TODOs and prose in "Combining Responses."</li>
    19091906      </ul>
    19101907      <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1>
Note: See TracChangeset for help on using the changeset viewer.