Ignore:
Timestamp:
31/01/09 20:56:49 (11 years ago)
Author:
julian.reschke@…
Message:

re-generate HTML, P6: fix a few formatting issues, add a few crefs

File:
1 edited

Legend:

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

    r437 r441  
    224224  margin-right: 0em;
    225225  padding-left: 0em;
     226  page-break-before: avoid;
    226227}
    227228li.indline0 {
     
    378379      <link rel="Appendix" title="A Compatibility with Previous Versions" href="#rfc.section.A">
    379380      <link rel="Appendix" title="B Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.B">
    380       <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.400, 2008-10-10 14:04:14, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
     381      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.415, 2009-01-29 15:06:08, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
    381382      <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/">
    382383      <meta name="DC.Creator" content="Fielding, R.">
     
    474475         <tr>
    475476            <td class="header left"></td>
    476             <td class="header right">December 11, 2008</td>
     477            <td class="header right">December 2008</td>
    477478         </tr>
    478479      </table>
     
    687688         </li>
    688689      </ul>
    689       <p id="rfc.section.3.1.p.2">Note that in normal operation, most caches will not store a response that has neither a cache validator nor an explicitly
    690          expiration time, as such responses are not usually useful to store. However, caches are not prohibited from storing such responses.
     690      <p id="rfc.section.3.1.p.2">Note that in normal operation, most caches will not store a response that has neither a cache validator nor an explicit expiration
     691         time, as such responses are not usually useful to store. However, caches are not prohibited from storing such responses.
    691692      </p>
    692693      <h3 id="rfc.section.3.1.1"><a href="#rfc.section.3.1.1">3.1.1</a>&nbsp;<a id="errors.or.incomplete.response.cache.behavior" href="#errors.or.incomplete.response.cache.behavior">Storing Incomplete Responses</a></h3>
    693       <p id="rfc.section.3.1.1.p.1">A cache that receives an incomplete response (for example, with fewer bytes of data than specified in a Content-Length header) <em class="bcp14">MAY</em> store the response. However, the cache <em class="bcp14">MUST</em> treat this as a partial response <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. Partial responses <em class="bcp14">MAY</em> be combined as described in <a href="p5-range.html#combining.byte.ranges" title="Combining Ranges">Section 4</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>; the result might be a full response or might still be partial. A cache <em class="bcp14">MUST NOT</em> return a partial response to a client without explicitly marking it as such using the 206 (Partial Content) status code.
     694      <p id="rfc.section.3.1.1.p.1">A cache that receives an incomplete response (for example, with fewer bytes of data than specified in a Content-Length header) <em class="bcp14">MAY</em> store the response <span class="comment">[rfc.comment.1: Indeed? Is this new? --JRE]</span>. However, the cache <em class="bcp14">MUST</em> treat this as a partial response <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. Partial responses <em class="bcp14">MAY</em> be combined as described in <a href="p5-range.html#combining.byte.ranges" title="Combining Ranges">Section 4</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>; the result might be a full response or might still be partial. A cache <em class="bcp14">MUST NOT</em> return a partial response to a client without explicitly marking it as such using the 206 (Partial Content) status code.
    694695      </p>
    695696      <p id="rfc.section.3.1.1.p.2">A cache that does not support the Range and Content-Range headers <em class="bcp14">MUST NOT</em> store incomplete or partial responses.
     
    699700      </p>
    700701      <ul>
    701          <li>the presented request-URI and that of the stored response match (see <span class="comment">[rfc.comment.1: TBD]</span>), and
     702         <li>the presented request-URI and that of the stored response match (see <span class="comment">[rfc.comment.2: TBD]</span>), and
    702703         </li>
    703704         <li>selecting headers nominated by the stored response (if any) match (see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;3.6</a>), and
     
    708709         </li>
    709710      </ul>
    710       <p id="rfc.section.3.2.p.2"> <span class="comment">[rfc.comment.2: ISSUE: This doesn't specify whether the request method is part of the cache key.]</span>
     711      <p id="rfc.section.3.2.p.2"> <span class="comment">[rfc.comment.3: ISSUE: This doesn't specify whether the request method is part of the cache key.]</span>
    711712      </p>
    712713      <p id="rfc.section.3.2.p.3">A shared cache <em class="bcp14">MAY</em> return a stored response, provided that:
     
    726727      <p id="rfc.section.3.2.p.7">In the process of determining whether a stored response is fresh or not, a cache <em class="bcp14">MAY</em> validate that response (see <a href="#validation.model" title="Validation Model">Section&nbsp;3.4</a>).
    727728      </p>
    728       <p id="rfc.section.3.2.p.8"> <span class="comment">[rfc.comment.3: TODO: end-to-end and hop-by-hop headers, non-modifiable headers removed; re-spec in p1]</span>
     729      <p id="rfc.section.3.2.p.8"> <span class="comment">[rfc.comment.4: TODO: end-to-end and hop-by-hop headers, non-modifiable headers removed; re-spec in p1]</span>
    729730      </p>
    730731      <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a id="expiration.model" href="#expiration.model">Freshness Model</a></h2>
    731732      <p id="rfc.section.3.3.p.1">HTTP caching works best when caches can entirely avoid making requests to the origin server. When a response is "fresh" in
    732733         the cache, it can be used to satisfy subsequent requests without contacting the origin server. This is also referred to as
    733          "expiration."
     734         "expiration."<span class="comment">[rfc.comment.5: What exactly is called 'expiration'? --JRE]</span>.
    734735      </p>
    735736      <p id="rfc.section.3.3.p.2">Expiration applies only to responses taken from a cache and not to first-hand responses. It cannot be used to force a user
     
    737738      </p>
    738739      <p id="rfc.section.3.3.p.3">The primary mechanism for avoiding requests is for an origin server to provide an explicit expiration time in the future,
    739          using either the Expires header <a href="#header.expires" id="rfc.xref.header.expires.1" title="Expires">Section&nbsp;4.3</a> or the max-age response cache directive <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;4.2.2</a>. Generally, origin servers will assign future explicit expiration times to responses in the belief that the entity is not
     740         using either the Expires header (<a href="#header.expires" id="rfc.xref.header.expires.1" title="Expires">Section&nbsp;4.3</a>) or the max-age response cache directive (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;4.2.2</a>). Generally, origin servers will assign future explicit expiration times to responses in the belief that the entity is not
    740741         likely to change in a semantically significant way before the expiration time is reached. This normally preserves cache correctness,
    741742         as long as the server's expiration times are carefully chosen.
     
    756757         with the effect of either increasing or loosening constraints on freshness. See <a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;4.2.1</a>.
    757758      </p>
    758       <p id="rfc.section.3.3.p.10"> <span class="comment">[rfc.comment.4: ISSUE: there are not requirements directly applying to cache-request-directives and freshness.]</span>
     759      <p id="rfc.section.3.3.p.10"> <span class="comment">[rfc.comment.6: ISSUE: there are not requirements directly applying to cache-request-directives and freshness.]</span>
    759760      </p>
    760761      <h3 id="rfc.section.3.3.1"><a href="#rfc.section.3.3.1">3.3.1</a>&nbsp;<a id="calculating.freshness.lifetime" href="#calculating.freshness.lifetime">Calculating Freshness Lifetime</a></h3>
     
    778779         not already present.
    779780      </p>
    780       <p id="rfc.section.3.3.1.1.p.3">Also, if the response has a Last-Modified header <a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 6.6</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, the heuristic expiration value <em class="bcp14">SHOULD</em> be no more than some fraction of the interval since that time. A typical setting of this fraction might be 10%.
    781       </p>
    782       <p id="rfc.section.3.3.1.1.p.4"> <span class="comment">[rfc.comment.5: REVIEW: took away HTTP/1.0 query string heuristic uncacheability.]</span>
     781      <p id="rfc.section.3.3.1.1.p.3">Also, if the response has a Last-Modified header (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 6.6</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>), the heuristic expiration value <em class="bcp14">SHOULD</em> be no more than some fraction of the interval since that time. A typical setting of this fraction might be 10%.
     782      </p>
     783      <p id="rfc.section.3.3.1.1.p.4"> <span class="comment">[rfc.comment.7: REVIEW: took away HTTP/1.0 query string heuristic uncacheability.]</span>
    783784      </p>
    784785      <h3 id="rfc.section.3.3.2"><a href="#rfc.section.3.3.2">3.3.2</a>&nbsp;<a id="age.calculations" href="#age.calculations">Calculating Age</a></h3>
     
    850851      <p id="rfc.section.3.3.3.p.4">Otherwise, caches <em class="bcp14">SHOULD NOT</em> return stale responses.
    851852      </p>
    852       <p id="rfc.section.3.3.3.p.5">Stale responses <em class="bcp14">SHOULD</em> have a Warning header with the 110 warn-code (see <a href="#header.warning" id="rfc.xref.header.warning.1" title="Warning">4.6</a>).
     853      <p id="rfc.section.3.3.3.p.5">Stale responses <em class="bcp14">SHOULD</em> have a Warning header with the 110 warn-code (see <a href="#header.warning" id="rfc.xref.header.warning.1" title="Warning">Section&nbsp;4.6</a>).
    853854      </p>
    854855      <p id="rfc.section.3.3.3.p.6">If a cache receives a first-hand response (either an entire response, or a 304 (Not Modified) response) that it would normally
     
    860861      </p>
    861862      <p id="rfc.section.3.4.p.2">HTTP's conditional request mechanism, defined in <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, is used to avoid retransmitting the response payload when the stored response is valid. When a stored response includes
    862          one or more "cache validators," such as the field values of an ETag or Last-Modified header field, then a validating GET request <em class="bcp14">SHOULD</em> be made conditional to those field values. The server checks the conditional request's validator against the current state
     863         one or more "cache validators", such as the field values of an ETag or Last-Modified header field, then a validating GET request <em class="bcp14">SHOULD</em> be made conditional to those field values. The server checks the conditional request's validator against the current state
    863864         of the requested resource and, if they match, the server responds with a 304 (Not Modified) status code to indicate that the
    864865         stored response can be refreshed and reused without retransmitting the response payload. If the validator does not match the
     
    884885         attacks.
    885886      </p>
    886       <p id="rfc.section.3.5.p.4"> <span class="comment">[rfc.comment.6: TODO: "host part" needs to be specified better.]</span>
     887      <p id="rfc.section.3.5.p.4"> <span class="comment">[rfc.comment.8: TODO: "host part" needs to be specified better.]</span>
    887888      </p>
    888889      <p id="rfc.section.3.5.p.5">A cache that passes through requests for methods it does not understand <em class="bcp14">SHOULD</em> invalidate the Request-URI.
     
    894895         change at the origin server might not have gone through the cache where a response is stored.
    895896      </p>
    896       <p id="rfc.section.3.5.p.8"> <span class="comment">[rfc.comment.7: TODO: specify that only successful (2xx, 3xx?) responses invalidate.]</span>
     897      <p id="rfc.section.3.5.p.8"> <span class="comment">[rfc.comment.9: TODO: specify that only successful (2xx, 3xx?) responses invalidate.]</span>
    897898      </p>
    898899      <h2 id="rfc.section.3.6"><a href="#rfc.section.3.6">3.6</a>&nbsp;<a id="caching.negotiated.responses" href="#caching.negotiated.responses">Caching Negotiated Responses</a></h2>
    899       <p id="rfc.section.3.6.p.1">Use of server-driven content negotiation (<a href="p3-payload.html#server-driven.negotiation" title="Server-driven Negotiation">Section 4.1</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), as indicated by the presence of a Vary header field <a href="#header.vary" id="rfc.xref.header.vary.1" title="Vary">Section&nbsp;4.5</a> in a response, alters the conditions and procedure by which a cache can use the response for subsequent requests.
     900      <p id="rfc.section.3.6.p.1">Use of server-driven content negotiation (<a href="p3-payload.html#server-driven.negotiation" title="Server-driven Negotiation">Section 4.1</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), as indicated by the presence of a Vary header field (<a href="#header.vary" id="rfc.xref.header.vary.1" title="Vary">Section&nbsp;4.5</a>) in a response, alters the conditions and procedure by which a cache can use the response for subsequent requests.
    900901      </p>
    901902      <p id="rfc.section.3.6.p.2">When the cache receives a subsequent request which may be satisfied by a stored responses that include a Vary header field,
     
    904905      </p>
    905906      <p id="rfc.section.3.6.p.3">The selecting request-headers from two requests are defined to match if and only if the selecting request-headers in the first
    906          request can be transformed to the selecting request-headers in the second request by adding or removing linear white space <span class="comment">[rfc.comment.8: [ref]]</span> at places where this is allowed by the corresponding ABNF, and/or combining multiple message-header fields with the same field
     907         request can be transformed to the selecting request-headers in the second request by adding or removing linear white space <span class="comment">[rfc.comment.10: [ref]]</span> at places where this is allowed by the corresponding ABNF, and/or combining multiple message-header fields with the same field
    907908         name following the rules about message headers in <a href="p1-messaging.html#message.headers" title="Message Headers">Section 4.2</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>.
    908909      </p>
     
    927928         of the existing response, the existing response <em class="bcp14">SHOULD NOT</em> be returned in response to future requests and <em class="bcp14">SHOULD</em> be deleted from the cache.
    928929      </p>
    929       <p id="rfc.section.3.6.p.9"> <span class="comment">[rfc.comment.9: TODO: this still needs work.]</span>
     930      <p id="rfc.section.3.6.p.9"> <span class="comment">[rfc.comment.11: TODO: this still needs work.]</span>
    930931      </p>
    931932      <h2 id="rfc.section.3.7"><a href="#rfc.section.3.7">3.7</a>&nbsp;<a id="combining.headers" href="#combining.headers">Combining Responses</a></h2>
     
    950951         such old headers <em class="bcp14">MUST</em> be replaced. it <em class="bcp14">MAY</em> store the combined entity-body.
    951952      </p>
    952       <p id="rfc.section.3.7.p.5"><span class="comment">[rfc.comment.10: ISSUE: discuss how to handle HEAD updates]</span></p>
     953      <p id="rfc.section.3.7.p.5"><span class="comment">[rfc.comment.12: ISSUE: discuss how to handle HEAD updates]</span></p>
    953954      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
    954955      <p id="rfc.section.4.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to caching.</p>
     
    15291530      <h1 id="rfc.section.A"><a href="#rfc.section.A">A.</a>&nbsp;<a id="compatibility" href="#compatibility">Compatibility with Previous Versions</a></h1>
    15301531      <h2 id="rfc.section.A.1"><a href="#rfc.section.A.1">A.1</a>&nbsp;<a id="changes.from.rfc.2068" href="#changes.from.rfc.2068">Changes from RFC 2068</a></h2>
    1531       <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">3.1</a>, <a href="#header.cache-control" id="rfc.xref.header.cache-control.6" title="Cache-Control">4.2</a>.
     1532      <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">3.1</a>, <a href="#header.cache-control" id="rfc.xref.header.cache-control.6" title="Cache-Control">4.2</a>).
    15321533      </p>
    15331534      <p id="rfc.section.A.1.p.2">Transfer-coding and message lengths all interact in ways that required fixing exactly when chunked encoding is used (to allow
Note: See TracChangeset for help on using the changeset viewer.