Changeset 500 for draft-ietf-httpbis
- Timestamp:
- 04/03/09 07:40:49 (13 years ago)
- Location:
- draft-ietf-httpbis/latest-roy
- Files:
-
- 10 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest-roy/p1-messaging.html
r462 r500 471 471 <tr> 472 472 <td class="header left"></td> 473 <td class="header right">March 2, 2009</td>473 <td class="header right">March 4, 2009</td> 474 474 </tr> 475 475 </table> … … 1378 1378 </dl> 1379 1379 <p id="rfc.section.5.1.2.p.18">HTTP does not place a pre-defined limit on the length of a request-target. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the 414 (URI Too Long) status if the received request-target 1380 would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 Request-targetToo Long">Section 8.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).1380 would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 8.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 1381 1381 </p> 1382 1382 <p id="rfc.section.5.1.2.p.19">Various ad-hoc limitations on request-target length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support request-target lengths of 8000 or more OCTETs. … … 2649 2649 <div id="rfc.figure.u.65"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS 2650 2650 2651 <a href="#abnf.dependencies" class="smpl">Cache-Control</a> = <Cache-Control, defined in [Part6], Section 3.4>2651 <a href="#abnf.dependencies" class="smpl">Cache-Control</a> = <Cache-Control, defined in [Part6], Section 15.4> 2652 2652 <a href="#chunked.transfer.encoding" class="smpl">Chunked-Body</a> = *chunk last-chunk trailer-part CRLF 2653 2653 <a href="#header.connection" class="smpl">Connection</a> = "Connection:" OWS Connection-v … … 2673 2673 <a href="#rule.whitespace" class="smpl">OWS</a> = *( [ obs-fold ] WSP ) 2674 2674 2675 <a href="#abnf.dependencies" class="smpl">Pragma</a> = <Pragma, defined in [Part6], Section 3.4>2675 <a href="#abnf.dependencies" class="smpl">Pragma</a> = <Pragma, defined in [Part6], Section 15.4> 2676 2676 2677 2677 <a href="#rule.whitespace" class="smpl">RWS</a> = 1*( [ obs-fold ] WSP ) … … 2704 2704 ] ) 2705 2705 2706 <a href="#abnf.dependencies" class="smpl">Warning</a> = <Warning, defined in [Part6], Section 3.6>2706 <a href="#abnf.dependencies" class="smpl">Warning</a> = <Warning, defined in [Part6], Section 15.6> 2707 2707 2708 2708 <a href="#uri" class="smpl">absolute-URI</a> = <absolute-URI, defined in [RFC3986], Section 4.3> -
draft-ietf-httpbis/latest-roy/p1-messaging.xml
r462 r500 4436 4436 <x:ref>BWS</x:ref> = OWS 4437 4437 4438 <x:ref>Cache-Control</x:ref> = <Cache-Control, defined in [Part6], Section 3.4>4438 <x:ref>Cache-Control</x:ref> = <Cache-Control, defined in [Part6], Section 15.4> 4439 4439 <x:ref>Chunked-Body</x:ref> = *chunk last-chunk trailer-part CRLF 4440 4440 <x:ref>Connection</x:ref> = "Connection:" OWS Connection-v … … 4460 4460 <x:ref>OWS</x:ref> = *( [ obs-fold ] WSP ) 4461 4461 4462 <x:ref>Pragma</x:ref> = <Pragma, defined in [Part6], Section 3.4>4462 <x:ref>Pragma</x:ref> = <Pragma, defined in [Part6], Section 15.4> 4463 4463 4464 4464 <x:ref>RWS</x:ref> = 1*( [ obs-fold ] WSP ) … … 4491 4491 ] ) 4492 4492 4493 <x:ref>Warning</x:ref> = <Warning, defined in [Part6], Section 3.6>4493 <x:ref>Warning</x:ref> = <Warning, defined in [Part6], Section 15.6> 4494 4494 4495 4495 <x:ref>absolute-URI</x:ref> = <absolute-URI, defined in [RFC3986], Section 4.3> -
draft-ietf-httpbis/latest-roy/p2-semantics.html
r462 r500 468 468 <tr> 469 469 <td class="header left"></td> 470 <td class="header right">March 2, 2009</td>470 <td class="header right">March 4, 2009</td> 471 471 </tr> 472 472 </table> … … 592 592 <li class="tocline1">8.4.13 <a href="#status.412">412 Precondition Failed</a></li> 593 593 <li class="tocline1">8.4.14 <a href="#status.413">413 Request Entity Too Large</a></li> 594 <li class="tocline1">8.4.15 <a href="#status.414">414 Request-targetToo Long</a></li>594 <li class="tocline1">8.4.15 <a href="#status.414">414 URI Too Long</a></li> 595 595 <li class="tocline1">8.4.16 <a href="#status.415">415 Unsupported Media Type</a></li> 596 596 <li class="tocline1">8.4.17 <a href="#status.416">416 Requested Range Not Satisfiable</a></li> … … 825 825 / "412" ; <a href="#status.412" id="rfc.xref.status.412.1" title="412 Precondition Failed">Section 8.4.13</a>: Precondition Failed 826 826 / "413" ; <a href="#status.413" id="rfc.xref.status.413.1" title="413 Request Entity Too Large">Section 8.4.14</a>: Request Entity Too Large 827 / "414" ; <a href="#status.414" id="rfc.xref.status.414.1" title="414 Request-target Too Long">Section 8.4.15</a>: Request-targetToo Long827 / "414" ; <a href="#status.414" id="rfc.xref.status.414.1" title="414 URI Too Long">Section 8.4.15</a>: URI Too Long 828 828 / "415" ; <a href="#status.415" id="rfc.xref.status.415.1" title="415 Unsupported Media Type">Section 8.4.16</a>: Unsupported Media Type 829 829 / "416" ; <a href="#status.416" id="rfc.xref.status.416.1" title="416 Requested Range Not Satisfiable">Section 8.4.17</a>: Requested range not satisfiable … … 1386 1386 <div id="rfc.iref.56"></div> 1387 1387 <div id="rfc.iref.s.33"></div> 1388 <h3 id="rfc.section.8.4.15"><a href="#rfc.section.8.4.15">8.4.15</a> <a id="status.414" href="#status.414">414 Request-targetToo Long</a></h3>1388 <h3 id="rfc.section.8.4.15"><a href="#rfc.section.8.4.15">8.4.15</a> <a id="status.414" href="#status.414">414 URI Too Long</a></h3> 1389 1389 <p id="rfc.section.8.4.15.p.1">The server is refusing to service the request because the request-target is longer than the server is willing to interpret. 1390 1390 This rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long … … 1904 1904 <tr> 1905 1905 <td>414</td> 1906 <td> Request-targetToo Long</td>1907 <td> <a href="#status.414" id="rfc.xref.status.414.2" title="414 Request-targetToo Long">Section 8.4.15</a>1906 <td>URI Too Long</td> 1907 <td> <a href="#status.414" id="rfc.xref.status.414.2" title="414 URI Too Long">Section 8.4.15</a> 1908 1908 </td> 1909 1909 </tr> … … 2251 2251 <a href="#abnf.dependencies" class="smpl">Accept-Language</a> = <Accept-Language, defined in [Part3], Section 5.4> 2252 2252 <a href="#abnf.dependencies" class="smpl">Accept-Ranges</a> = <Accept-Ranges, defined in [Part5], Section 5.1> 2253 <a href="#abnf.dependencies" class="smpl">Age</a> = <Age, defined in [Part6], Section 3.1>2253 <a href="#abnf.dependencies" class="smpl">Age</a> = <Age, defined in [Part6], Section 15.1> 2254 2254 <a href="#header.allow" class="smpl">Allow</a> = "Allow:" OWS Allow-v 2255 2255 <a href="#header.allow" class="smpl">Allow-v</a> = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ] … … 2312 2312 <a href="#header.user-agent" class="smpl">User-Agent-v</a> = product *( RWS ( product / comment ) ) 2313 2313 2314 <a href="#abnf.dependencies" class="smpl">Vary</a> = <Vary, defined in [Part6], Section 3.5>2314 <a href="#abnf.dependencies" class="smpl">Vary</a> = <Vary, defined in [Part6], Section 15.5> 2315 2315 2316 2316 WWW-Authenticate = … … 2519 2519 <li class="indline1">412 Precondition Failed (status code) <a class="iref" href="#rfc.xref.status.412.1">4</a>, <a class="iref" href="#rfc.iref.54"><b>8.4.13</b></a>, <a class="iref" href="#rfc.xref.status.412.2">10.2</a></li> 2520 2520 <li class="indline1">413 Request Entity Too Large (status code) <a class="iref" href="#rfc.xref.status.413.1">4</a>, <a class="iref" href="#rfc.iref.55"><b>8.4.14</b></a>, <a class="iref" href="#rfc.xref.status.413.2">10.2</a></li> 2521 <li class="indline1">414 Request-targetToo Long (status code) <a class="iref" href="#rfc.xref.status.414.1">4</a>, <a class="iref" href="#rfc.iref.56"><b>8.4.15</b></a>, <a class="iref" href="#rfc.xref.status.414.2">10.2</a></li>2521 <li class="indline1">414 URI Too Long (status code) <a class="iref" href="#rfc.xref.status.414.1">4</a>, <a class="iref" href="#rfc.iref.56"><b>8.4.15</b></a>, <a class="iref" href="#rfc.xref.status.414.2">10.2</a></li> 2522 2522 <li class="indline1">415 Unsupported Media Type (status code) <a class="iref" href="#rfc.xref.status.415.1">4</a>, <a class="iref" href="#rfc.iref.57"><b>8.4.16</b></a>, <a class="iref" href="#rfc.xref.status.415.2">10.2</a></li> 2523 2523 <li class="indline1">416 Requested Range Not Satisfiable (status code) <a class="iref" href="#rfc.xref.status.416.1">4</a>, <a class="iref" href="#rfc.iref.58"><b>8.4.17</b></a>, <a class="iref" href="#rfc.xref.status.416.2">10.2</a></li> … … 2761 2761 <li class="indline1">412 Precondition Failed <a class="iref" href="#rfc.xref.status.412.1">4</a>, <a class="iref" href="#rfc.iref.s.31"><b>8.4.13</b></a>, <a class="iref" href="#rfc.xref.status.412.2">10.2</a></li> 2762 2762 <li class="indline1">413 Request Entity Too Large <a class="iref" href="#rfc.xref.status.413.1">4</a>, <a class="iref" href="#rfc.iref.s.32"><b>8.4.14</b></a>, <a class="iref" href="#rfc.xref.status.413.2">10.2</a></li> 2763 <li class="indline1">414 Request-targetToo Long <a class="iref" href="#rfc.xref.status.414.1">4</a>, <a class="iref" href="#rfc.iref.s.33"><b>8.4.15</b></a>, <a class="iref" href="#rfc.xref.status.414.2">10.2</a></li>2763 <li class="indline1">414 URI Too Long <a class="iref" href="#rfc.xref.status.414.1">4</a>, <a class="iref" href="#rfc.iref.s.33"><b>8.4.15</b></a>, <a class="iref" href="#rfc.xref.status.414.2">10.2</a></li> 2764 2764 <li class="indline1">415 Unsupported Media Type <a class="iref" href="#rfc.xref.status.415.1">4</a>, <a class="iref" href="#rfc.iref.s.34"><b>8.4.16</b></a>, <a class="iref" href="#rfc.xref.status.415.2">10.2</a></li> 2765 2765 <li class="indline1">416 Requested Range Not Satisfiable <a class="iref" href="#rfc.xref.status.416.1">4</a>, <a class="iref" href="#rfc.iref.s.35"><b>8.4.17</b></a>, <a class="iref" href="#rfc.xref.status.416.2">10.2</a></li> -
draft-ietf-httpbis/latest-roy/p2-semantics.xml
r462 r500 556 556 / "412" ; <xref target="status.412"/>: Precondition Failed 557 557 / "413" ; <xref target="status.413"/>: Request Entity Too Large 558 / "414" ; <xref target="status.414"/>: Request-targetToo Long558 / "414" ; <xref target="status.414"/>: URI Too Long 559 559 / "415" ; <xref target="status.415"/>: Unsupported Media Type 560 560 / "416" ; <xref target="status.416"/>: Requested range not satisfiable … … 1662 1662 </section> 1663 1663 1664 <section title="414 Request-targetToo Long" anchor="status.414">1665 <iref primary="true" item="414 Request-targetToo Long (status code)" x:for-anchor=""/>1666 <iref primary="true" item="Status Codes" subitem="414 Request-targetToo Long" x:for-anchor=""/>1664 <section title="414 URI Too Long" anchor="status.414"> 1665 <iref primary="true" item="414 URI Too Long (status code)" x:for-anchor=""/> 1666 <iref primary="true" item="Status Codes" subitem="414 URI Too Long" x:for-anchor=""/> 1667 1667 <t> 1668 1668 The server is refusing to service the request because the request-target … … 2402 2402 </c> 2403 2403 <c>414</c> 2404 <c> Request-targetToo Long</c>2404 <c>URI Too Long</c> 2405 2405 <c> 2406 2406 <xref target="status.414"/> … … 3213 3213 <x:ref>Accept-Language</x:ref> = <Accept-Language, defined in [Part3], Section 5.4> 3214 3214 <x:ref>Accept-Ranges</x:ref> = <Accept-Ranges, defined in [Part5], Section 5.1> 3215 <x:ref>Age</x:ref> = <Age, defined in [Part6], Section 3.1>3215 <x:ref>Age</x:ref> = <Age, defined in [Part6], Section 15.1> 3216 3216 <x:ref>Allow</x:ref> = "Allow:" OWS Allow-v 3217 3217 <x:ref>Allow-v</x:ref> = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ] … … 3274 3274 <x:ref>User-Agent-v</x:ref> = product *( RWS ( product / comment ) ) 3275 3275 3276 <x:ref>Vary</x:ref> = <Vary, defined in [Part6], Section 3.5>3276 <x:ref>Vary</x:ref> = <Vary, defined in [Part6], Section 15.5> 3277 3277 3278 3278 WWW-Authenticate = … … 3322 3322 </artwork></figure></section> 3323 3323 3324 3325 3324 <section title="Change Log (to be removed by RFC Editor before publication)" anchor="change.log"> 3326 3325 -
draft-ietf-httpbis/latest-roy/p3-payload.html
r462 r500 475 475 <tr> 476 476 <td class="header left"></td> 477 <td class="header right">March 2, 2009</td>477 <td class="header right">March 4, 2009</td> 478 478 </tr> 479 479 </table> … … 1749 1749 <a href="#header.content-type" class="smpl">Content-Type-v</a> = media-type 1750 1750 1751 <a href="#abnf.dependencies" class="smpl">Expires</a> = <Expires, defined in [Part6], Section 3.3>1751 <a href="#abnf.dependencies" class="smpl">Expires</a> = <Expires, defined in [Part6], Section 15.3> 1752 1752 1753 1753 <a href="#abnf.dependencies" class="smpl">Last-Modified</a> = <Last-Modified, defined in [Part4], Section 6.6> -
draft-ietf-httpbis/latest-roy/p3-payload.xml
r462 r500 2667 2667 <x:ref>Content-Type-v</x:ref> = media-type 2668 2668 2669 <x:ref>Expires</x:ref> = <Expires, defined in [Part6], Section 3.3>2669 <x:ref>Expires</x:ref> = <Expires, defined in [Part6], Section 15.3> 2670 2670 2671 2671 <x:ref>Last-Modified</x:ref> = <Last-Modified, defined in [Part4], Section 6.6> -
draft-ietf-httpbis/latest-roy/p4-conditional.html
r461 r500 464 464 <tr> 465 465 <td class="header left"></td> 466 <td class="header right">March 2, 2009</td>466 <td class="header right">March 4, 2009</td> 467 467 </tr> 468 468 </table> -
draft-ietf-httpbis/latest-roy/p5-range.html
r461 r500 464 464 <tr> 465 465 <td class="header left"></td> 466 <td class="header right">March 2, 2009</td>466 <td class="header right">March 4, 2009</td> 467 467 </tr> 468 468 </table> -
draft-ietf-httpbis/latest-roy/p6-cache.html
r463 r500 465 465 <tr> 466 466 <td class="header left"></td> 467 <td class="header right">March 2, 2009</td>467 <td class="header right">March 4, 2009</td> 468 468 </tr> 469 469 </table> … … 523 523 <li class="tocline0">2. <a href="#caching.overview">Cache Operation</a><ul class="toc"> 524 524 <li class="tocline1">2.1 <a href="#response.cacheability">Response Cacheability</a><ul class="toc"> 525 <li class="tocline1">2.1.1 <a href="#errors.or.incomplete.response.cache.behavior">Storing Incomplete Responses</a></li>525 <li class="tocline1">2.1.1 <a href="#errors.or.incomplete.response.cache.behavior">Storing Partial and Incomplete Responses</a></li> 526 526 </ul> 527 527 </li> … … 529 529 <li class="tocline1">2.3 <a href="#expiration.model">Freshness Model</a><ul class="toc"> 530 530 <li class="tocline1">2.3.1 <a href="#calculating.freshness.lifetime">Calculating Freshness Lifetime</a><ul class="toc"> 531 <li class="tocline1">2.3.1.1 <a href="#heuristic.freshness"> Using Heuristic Freshness</a></li>531 <li class="tocline1">2.3.1.1 <a href="#heuristic.freshness">Calculating Heuristic Freshness</a></li> 532 532 </ul> 533 533 </li> … … 645 645 </p> 646 646 <dl class="empty"> 647 <dd>A response is stale if its age has passed its freshness lifetime .</dd>647 <dd>A response is stale if its age has passed its freshness lifetime (either explicit or heuristic).</dd> 648 648 </dl> 649 649 <p id="rfc.section.1.2.p.10"> <span id="rfc.iref.v.1"></span> <dfn>validator</dfn> … … 688 688 </p> 689 689 <ul> 690 <li>the "no-store" cache directive (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.1" title="Cache-Control">Section 3.2</a>) does not appear in request or response headers. 691 </li> 692 <li>the cache understands partial responses, if the response is partial or incomplete (see <a href="#errors.or.incomplete.response.cache.behavior" title="Storing Incomplete Responses">Section 2.1.1</a>). 690 <li>The request method is defined as being cacheable, and</li> 691 <li>the "no-store" cache directive (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.1" title="Cache-Control">Section 3.2</a>) does not appear in request or response headers, and 692 </li> 693 <li>the "private" cache response directive (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.2" title="Cache-Control">Section 3.2</a> does not appear in the response, if the cache is a shared cache, and 694 </li> 695 <li>the cache understands partial responses, if the response is partial or incomplete (see <a href="#errors.or.incomplete.response.cache.behavior" title="Storing Partial and Incomplete Responses">Section 2.1.1</a>). 693 696 </li> 694 697 </ul> … … 696 699 time, as such responses are not usually useful to store. However, caches are not prohibited from storing such responses. 697 700 </p> 698 <h3 id="rfc.section.2.1.1"><a href="#rfc.section.2.1.1">2.1.1</a> <a id="errors.or.incomplete.response.cache.behavior" href="#errors.or.incomplete.response.cache.behavior">Storing Incomplete Responses</a></h3>699 <p id="rfc.section.2.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.701 <h3 id="rfc.section.2.1.1"><a href="#rfc.section.2.1.1">2.1.1</a> <a id="errors.or.incomplete.response.cache.behavior" href="#errors.or.incomplete.response.cache.behavior">Storing Partial and Incomplete Responses</a></h3> 702 <p id="rfc.section.2.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. 700 703 </p> 701 704 <p id="rfc.section.2.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. 702 705 </p> 703 706 <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> <a id="constructing.responses.from.caches" href="#constructing.responses.from.caches">Constructing Responses from Caches</a></h2> 704 <p id="rfc.section.2.2.p.1">For a givenrequest, a non-shared cache <em class="bcp14">MAY</em> return a stored response, provided that:707 <p id="rfc.section.2.2.p.1">For a presented request, a non-shared cache <em class="bcp14">MAY</em> return a stored response, provided that: 705 708 </p> 706 709 <ul> 707 <li>the presented request-URI and that of the stored response match (see <span class="comment">[rfc.comment.2: TBD]</span>), and 708 </li> 709 <li>selecting headers nominated by the stored response (if any) match (see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2.6</a>), and 710 </li> 711 <li>the stored response is either fresh (see <a href="#expiration.model" title="Freshness Model">Section 2.3</a>) or allowed to be served stale (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section 2.3.3</a>), and 712 </li> 713 <li>the presented request and stored response are free from directives that would prevent it (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.2" title="Cache-Control">Section 3.2</a> and <a href="#header.pragma" id="rfc.xref.header.pragma.1" title="Pragma">Section 3.4</a>). 710 <li>The presented Request-URI and that of the stored response match (see <span class="comment">[rfc.comment.1: TBD]</span>), and 711 </li> 712 <li>the request method associated with the stored response allows it to be used for the presented request, and</li> 713 <li>selecting request-headers nominated by the stored response (if any) match those presented (see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2.6</a>), and 714 </li> 715 <li>the stored response is either: 716 <ul> 717 <li>fresh (see <a href="#expiration.model" title="Freshness Model">Section 2.3</a>), or 718 </li> 719 <li>allowed to be served stale (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section 2.3.3</a>), or 720 </li> 721 <li>successfully validated (see <a href="#validation.model" title="Validation Model">Section 2.4</a>). 722 </li> 723 </ul>and 724 </li> 725 <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 3.2</a> and <a href="#header.pragma" id="rfc.xref.header.pragma.1" title="Pragma">Section 3.4</a>). 714 726 </li> 715 727 </ul> 716 <p id="rfc.section.2.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> 717 </p> 718 <p id="rfc.section.2.2.p.3">A shared cache <em class="bcp14">MAY</em> return a stored response, provided that: 728 <p id="rfc.section.2.2.p.2">A shared cache <em class="bcp14">MAY</em> return a stored response, provided that: 719 729 </p> 720 730 <ul> 721 <li> the criteria for non-shared caches above are met (including directives for shared caches; see <a href="#header.cache-control" id="rfc.xref.header.cache-control.3" title="Cache-Control">Section 3.2</a>), and722 </li> 723 <li>the stored response was not associated with an authenticated request (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>), unless explicitly allowed (see <a href="#header.cache-control" id="rfc.xref.header.cache-control. 4" title="Cache-Control">Section 3.2</a>).731 <li>The criteria for non-shared caches above are met (taking into account directives specific to shared caches; see <a href="#header.cache-control" id="rfc.xref.header.cache-control.4" title="Cache-Control">Section 3.2</a>), and 732 </li> 733 <li>the stored response was not associated with an authenticated request (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>), unless explicitly allowed (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.5" title="Cache-Control">Section 3.2</a>). 724 734 </li> 725 735 </ul> 726 <p id="rfc.section.2.2.p.4">All responses satisfied from cache <em class="bcp14">MUST</em> include an appropriate Age header field (<a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section 3.1</a>). 727 </p> 728 <p id="rfc.section.2.2.p.5">All request methods other than GET and HEAD <em class="bcp14">MUST</em> be written through the cache to the origin server. Note that such requests might invalidate already stored responses; see <a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section 2.5</a>. 729 </p> 730 <p id="rfc.section.2.2.p.6">Caches <em class="bcp14">SHOULD</em> use the most recent response (as determined by the Date header) when more than one applicable response is stored. They <em class="bcp14">MAY</em> also send a request with "Cache-Control: max-age=0" or "Cache-Control: no-cache" to disambiguate which response to use. 731 </p> 732 <p id="rfc.section.2.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 2.4</a>). 736 <p id="rfc.section.2.2.p.3"><span class="comment">[rfc.comment.2: TODO: define method cacheability for GET, HEAD and POST in p2-semantics.]</span></p> 737 <p id="rfc.section.2.2.p.4">All responses satisfied from cache include an appropriate Age header field; see <a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section 3.1</a>. <span class="comment">[rfc.comment.3: DISCUSS: this currently includes successfully validated responses.]</span></p> 738 <p id="rfc.section.2.2.p.5">Request 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 739 the request and having received a corresponding response. 740 </p> 741 <p id="rfc.section.2.2.p.6">Also, note that unsafe requests might invalidate already stored responses; see <a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section 2.5</a>. 742 </p> 743 <p id="rfc.section.2.2.p.7">Caches <em class="bcp14">SHOULD</em> use the most recent response (as determined by the Date header) when more than one suitable response is stored. They <em class="bcp14">MAY</em> also forward a request with "Cache-Control: max-age=0" or "Cache-Control: no-cache" to disambiguate which response to use. 733 744 </p> 734 745 <p id="rfc.section.2.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> 735 746 </p> 736 747 <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a> <a id="expiration.model" href="#expiration.model">Freshness Model</a></h2> 737 <p id="rfc.section.2.3.p.1">HTTP caching works best when caches can entirely avoid making requests to the origin server. When a response is "fresh" in 738 the cache, it can be used to satisfy subsequent requests without contacting the origin server. This is also referred to as 739 "expiration."<span class="comment">[rfc.comment.5: What exactly is called 'expiration'? --JRE]</span>. 740 </p> 741 <p id="rfc.section.2.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 742 agent to refresh its display or reload a resource; its semantics apply only to caches. See <a href="#history.lists" title="History Lists">Section 4</a> for an explanation of the difference between caches and history mechanisms. 743 </p> 744 <p id="rfc.section.2.3.p.3">The primary mechanism for avoiding requests is for an origin server to provide an explicit expiration time in the future, 748 <p id="rfc.section.2.3.p.1">When a response is "fresh" in the cache, it can be used to satisfy subsequent requests without contacting the origin server, 749 thereby improving efficiency. 750 </p> 751 <p id="rfc.section.2.3.p.2">The primary mechanism for determining freshness is for an origin server to provide an explicit expiration time in the future, 745 752 using either the Expires header (<a href="#header.expires" id="rfc.xref.header.expires.1" title="Expires">Section 3.3</a>) or the max-age response cache directive (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section 3.2.2</a>). Generally, origin servers will assign future explicit expiration times to responses in the belief that the entity is not 746 likely to change in a semantically significant way before the expiration time is reached. This normally preserves cache correctness, 747 as long as the server's expiration times are carefully chosen. 748 </p> 749 <p id="rfc.section.2.3.p.4">If an origin server wishes to force a cache to validate every request, it <em class="bcp14">MAY</em> assign an explicit expiration time in the past. This means that the response is always stale, so that caches should validate 750 it before using it for subsequent requests. 751 </p> 752 <p id="rfc.section.2.3.p.5">Since origin servers do not always provide explicit expiration times, HTTP caches may assign heuristic expiration times when 753 they are not specified, employing algorithms that use other header values (such as the Last-Modified time) to estimate a plausible 754 expiration time. The HTTP/1.1 specification does not provide specific algorithms, but does impose worst-case constraints on 755 their results. 756 </p> 757 <p id="rfc.section.2.3.p.6">The calculation to determine if a response has expired is:</p> 753 likely to change in a semantically significant way before the expiration time is reached. 754 </p> 755 <p id="rfc.section.2.3.p.3">If an origin server wishes to force a cache to validate every request, it <em class="bcp14">MAY</em> assign an explicit expiration time in the past. This means that the response is always stale, so that caches should validate 756 it before using it for subsequent requests. <span class="comment">[rfc.comment.5: This wording may cause confusion, because the response may still be served stale.]</span></p> 757 <p id="rfc.section.2.3.p.4">Since origin servers do not always provide explicit expiration times, HTTP caches may also assign heuristic expiration times 758 when they are not specified, employing algorithms that use other header values (such as the Last-Modified time) to estimate 759 a plausible expiration time. The HTTP/1.1 specification does not provide specific algorithms, but does impose worst-case constraints 760 on their results. 761 </p> 762 <p id="rfc.section.2.3.p.5">The calculation to determine if a response is fresh is:</p> 758 763 <div id="rfc.figure.u.3"></div> <pre class="text"> response_is_fresh = (freshness_lifetime > current_age) 759 </pre> <p id="rfc.section.2.3.p. 8">The freshness_lifetime is defined in <a href="#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 2.3.1</a>; the current_age is defined in <a href="#age.calculations" title="Calculating Age">Section 2.3.2</a>.760 </p> 761 <p id="rfc.section.2.3.p. 9">Additionally, clients may need to influence freshness calculation. They can do this using several request cache directives,764 </pre> <p id="rfc.section.2.3.p.7">The freshness_lifetime is defined in <a href="#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 2.3.1</a>; the current_age is defined in <a href="#age.calculations" title="Calculating Age">Section 2.3.2</a>. 765 </p> 766 <p id="rfc.section.2.3.p.8">Additionally, clients may need to influence freshness calculation. They can do this using several request cache directives, 762 767 with the effect of either increasing or loosening constraints on freshness. See <a href="#cache-request-directive" title="Request Cache-Control Directives">Section 3.2.1</a>. 768 </p> 769 <p id="rfc.section.2.3.p.9">Note that reshness applies only to cache operation; it cannot be used to force a user agent to refresh its display or reload 770 a resource. See <a href="#history.lists" title="History Lists">Section 4</a> for an explanation of the difference between caches and history mechanisms. 763 771 </p> 764 772 <p id="rfc.section.2.3.p.10"> <span class="comment">[rfc.comment.6: ISSUE: there are not requirements directly applying to cache-request-directives and freshness.]</span> … … 773 781 <li>If the Expires response header (<a href="#header.expires" id="rfc.xref.header.expires.2" title="Expires">Section 3.3</a>) is present, use its value minus the value of the Date response header, or 774 782 </li> 775 <li>Otherwise, no explicit expiration time is present in the response, but a heuristic may be used; see <a href="#heuristic.freshness" title=" Using Heuristic Freshness">Section 2.3.1.1</a>.783 <li>Otherwise, no explicit expiration time is present in the response, but a heuristic may be used; see <a href="#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a>. 776 784 </li> 777 785 </ul> 778 786 <p id="rfc.section.2.3.1.p.2">Note that this calculation is not vulnerable to clock skew, since all of the information comes from the origin server.</p> 779 <h4 id="rfc.section.2.3.1.1"><a href="#rfc.section.2.3.1.1">2.3.1.1</a> <a id="heuristic.freshness" href="#heuristic.freshness"> Using Heuristic Freshness</a></h4>787 <h4 id="rfc.section.2.3.1.1"><a href="#rfc.section.2.3.1.1">2.3.1.1</a> <a id="heuristic.freshness" href="#heuristic.freshness">Calculating Heuristic Freshness</a></h4> 780 788 <p id="rfc.section.2.3.1.1.p.1">If no explicit expiration time is present in a stored response that has a status code of 200, 203, 206, 300, 301 or 410, a 781 789 heuristic expiration time <em class="bcp14">MAY</em> be calculated. Heuristics <em class="bcp14">MUST NOT</em> be used for other response status codes. … … 794 802 path from the origin server, plus the amount of time it has been in transit along network paths. 795 803 </p> 796 <p id="rfc.section.2.3.2.p.2">When a response is generated from a stored response, the cache <em class="bcp14">MUST</em> include a single Age header field in the response with a value equal to the stored response's current_age, calculated using804 <p id="rfc.section.2.3.2.p.2">When a stored response is used to satisfy a request, the cache <em class="bcp14">MUST</em> include a single Age header field in the response with a value equal to the stored response's current_age, calculated using 797 805 the algorithm described in this section. 798 806 </p> … … 848 856 but is not fresh according to the calculations in <a href="#expiration.model" title="Freshness Model">Section 2.3</a>. 849 857 </p> 850 <p id="rfc.section.2.3.3.p.2">Caches <em class="bcp14">MUST NOT</em> return a stale response if it is prohibited by an explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache 858 <p id="rfc.section.2.3.3.p.2">Caches <em class="bcp14">MAY</em> return a stale response if disconnected or explicitly allowed (e.g., the max-stale request directive; see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section 3.2.1</a>). 859 </p> 860 <p id="rfc.section.2.3.3.p.3">Otherwise, caches <em class="bcp14">SHOULD NOT</em> return stale responses. 861 </p> 862 <p id="rfc.section.2.3.3.p.4">Caches <em class="bcp14">MUST NOT</em> return a stale response if it is prohibited by an explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache 851 863 directive, a "must-revalidate" cache-response-directive, or an applicable "s-maxage" or "proxy-revalidate" cache-response-directive; 852 864 see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section 3.2.2</a>). 853 865 </p> 854 <p id="rfc.section.2.3.3.p.3">Caches <em class="bcp14">MAY</em> return a stale response if disconnected or explicitly allowed (e.g., the max-stale request directive; see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section 3.2.1</a>).855 </p>856 <p id="rfc.section.2.3.3.p.4">Otherwise, caches <em class="bcp14">SHOULD NOT</em> return stale responses.857 </p>858 866 <p id="rfc.section.2.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 3.6</a>). 859 867 </p> … … 862 870 </p> 863 871 <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a> <a id="validation.model" href="#validation.model">Validation Model</a></h2> 864 <p id="rfc.section.2.4.p.1">When a cache has a stale response that it would like to use, it <em class="bcp14">SHOULD</em> first check with the origin server (or possibly an intermediate cache with a fresh response) to see if it is still usable. 865 This is called "validating" or "revalidating" the stored response. 866 </p> 867 <p id="rfc.section.2.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 868 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 869 of the requested resource and, if they match, the server responds with a 304 (Not Modified) status code to indicate that the 870 stored response can be refreshed and reused without retransmitting the response payload. If the validator does not match the 871 current state of the requested resource, then the server returns a full response, including payload, so that the request can 872 be satisfied and the stored response supplanted without the need for an additional network round-trip. 873 </p> 874 <p id="rfc.section.2.4.p.3">See <a href="#combining.headers" title="Combining Responses">Section 2.7</a> regarding combining cached headers with those in a 304 response. 875 </p> 876 <p id="rfc.section.2.4.p.4">If a cache receives a 5xx response while attempting to validate a response, it <em class="bcp14">MAY</em> either forward this response to the requesting client, or act as if the server failed to respond. In the latter case, it <em class="bcp14">MAY</em> return a previously received response unless the stored response includes the "must-revalidate" cache directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section 3.2.2</a>). 872 <p id="rfc.section.2.4.p.1">Checking with the origin server to see if a stale or otherwise unusable cached response can be reused is called "validating" 873 or "revalidating." Doing so potentially avoids the overhead of retransmitting the response body when the stored response is 874 valid. 875 </p> 876 <p id="rfc.section.2.4.p.2">HTTP's conditional request mechanism <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a> 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 877 header field, then a validating request <em class="bcp14">SHOULD</em> be made conditional to those field values. 878 </p> 879 <p id="rfc.section.2.4.p.3">A 304 (Not Modified) response status code indicates that the stored response can be updated and reused; see <a href="#combining.headers" title="Combining Responses">Section 2.7</a>. 880 </p> 881 <p id="rfc.section.2.4.p.4">If instead the cache receives a full response (i.e., one with a response body), it is used to satisfy the request and replace 882 the stored response. <span class="comment">[rfc.comment.8: Should there be a requirement here?]</span></p> 883 <p id="rfc.section.2.4.p.5">If a cache receives a 5xx response while attempting to validate a response, it <em class="bcp14">MAY</em> either forward this response to the requesting client, or act as if the server failed to respond. In the latter case, it <em class="bcp14">MAY</em> return a previously stored response unless the stored response includes the "must-revalidate" cache directive (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section 2.3.3</a>). 877 884 </p> 878 885 <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a> <a id="invalidation.after.updates.or.deletions" href="#invalidation.after.updates.or.deletions">Request Methods that Invalidate</a></h2> 879 <p id="rfc.section.2.5.p.1">Because unsafe methods <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> have the potential for changing state on the origin server, intervening caches have the opportunity to use them to keep their 880 contents up-to-date. 886 <p id="rfc.section.2.5.p.1">Because unsafe methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) have the potential for changing state on the origin server, intervening caches can use them to keep their contents up-to-date. 881 887 </p> 882 888 <p id="rfc.section.2.5.p.2">The following HTTP methods <em class="bcp14">MUST</em> cause a cache to invalidate the Request-URI as well as the Location and Content-Location headers (if present): … … 890 896 attacks. 891 897 </p> 892 <p id="rfc.section.2.5.p.4"> <span class="comment">[rfc.comment. 8: TODO: "host part" needs to be specified better.]</span>898 <p id="rfc.section.2.5.p.4"> <span class="comment">[rfc.comment.9: TODO: "host part" needs to be specified better.]</span> 893 899 </p> 894 900 <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 Request-URI. … … 900 906 change at the origin server might not have gone through the cache where a response is stored. 901 907 </p> 902 <p id="rfc.section.2.5.p.8"> <span class="comment">[rfc.comment. 9: TODO: specify that only successful (2xx, 3xx?) responses invalidate.]</span>908 <p id="rfc.section.2.5.p.8"> <span class="comment">[rfc.comment.10: TODO: specify that only successful (2xx, 3xx?) responses invalidate.]</span> 903 909 </p> 904 910 <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a> <a id="caching.negotiated.responses" href="#caching.negotiated.responses">Caching Negotiated Responses</a></h2> 905 <p id="rfc.section.2.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 3.5</a>) in a response, alters the conditions and procedure by which a cache can use the response for subsequent requests. 906 </p> 907 <p id="rfc.section.2.6.p.2">When the cache receives a subsequent request which may be satisfied by a stored responses that include a Vary header field, 908 it <em class="bcp14">MUST NOT</em> use it to satisfy the request unless all of the selecting request-headers present in the new request match the corresponding 909 stored request-headers from the original request. 911 <p id="rfc.section.2.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>) alters the conditions and procedure by which a cache can use the response for subsequent requests. 912 </p> 913 <p id="rfc.section.2.6.p.2">When the cache receives a request which may be satisfied by a stored response that includes a Vary header field <a href="#header.vary" id="rfc.xref.header.vary.1" title="Vary">Section 3.5</a>, it <em class="bcp14">MUST NOT</em> use the stored response to satisfy the request unless all of the selecting request-headers present in the new request match 914 the corresponding stored request-headers from the original request. 910 915 </p> 911 916 <p id="rfc.section.2.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 912 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 913 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.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 914 </p> 915 <p id="rfc.section.2.6.p.4">A Vary header field-value of "*" always fails to match, and subsequent requests on that resource can only be properly interpreted 917 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.11: [ref]]</span> at places where this is allowed by the corresponding ABNF, and/or combining multiple message-header fields with the same field 918 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.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. <span class="comment">[rfc.comment.12: DISCUSS: header-specific canonicalisation]</span></p> 919 <p id="rfc.section.2.6.p.4">A Vary header field-value of "*" always fails to match, and subsequent requests to that resource can only be properly interpreted 916 920 by the origin server. 917 921 </p> 918 <p id="rfc.section.2.6.p.5">If the selecting request header fields for the stored response do not match the selecting request header fields of the new 919 request, then the cache <em class="bcp14">MUST NOT</em> use the stored response to satisfy the request unless it first relays the new request to the origin server in a conditional 920 request and the server responds with 304 (Not Modified), including an entity tag or Content-Location that indicates the entity 921 to be used. 922 </p> 923 <p id="rfc.section.2.6.p.6">If one or more applicable stored response has an entity tag, the forwarded request <em class="bcp14">SHOULD</em> be conditional and include all of these entity tags in an If-None-Match header field. This conveys to the server the set of 924 entities currently stored by the cache, so that if any one of these entities matches the requested entity, the server can 925 use the ETag header field in its 304 (Not Modified) response to tell the cache which stored response is appropriate. If the 926 entity-tag of the new response matches that of an existing stored resopnse, the new response <em class="bcp14">SHOULD</em> be used to update its header fields, and the result <em class="bcp14">MUST</em> be returned to the client. 927 </p> 928 <p id="rfc.section.2.6.p.7">If any of the existing stored responses contains only partial content for the associated entity, its entity-tag <em class="bcp14">SHOULD NOT</em> be included in the If-None-Match header field unless the request is for a range that would be fully satisfied by that stored 922 <p id="rfc.section.2.6.p.5">If no stored response matches, the cache <em class="bcp14">MAY</em> forward the presented request to the origin server in a conditional request, which <em class="bcp14">SHOULD</em> include all ETags stored with potentially suitable responses in an If-None-Match request header. If the server responds with 923 304 (Not Modified) and includes an entity tag or Content-Location that indicates the entity to be used, that cached response <em class="bcp14">MUST</em> be used to satisfy the presented request, and <em class="bcp14">SHOULD</em> be used to update the corresponding stored response; see <a href="#combining.headers" title="Combining Responses">Section 2.7</a>. 924 </p> 925 <p id="rfc.section.2.6.p.6">If any of the stored responses contains only partial content, its entity-tag <em class="bcp14">SHOULD NOT</em> be included in the If-None-Match header field unless the request is for a range that would be fully satisfied by that stored 929 926 response. 930 927 </p> 931 <p id="rfc.section.2.6.p. 8">If a cache receives a successful response whose Content-Location field matches that of an existing stored response for the928 <p id="rfc.section.2.6.p.7">If a cache receives a successful response whose Content-Location field matches that of an existing stored response for the 932 929 same Request-URI, whose entity-tag differs from that of the existing stored response, and whose Date is more recent than that 933 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. 934 </p> 935 <p id="rfc.section.2.6.p.9"> <span class="comment">[rfc.comment.11: TODO: this still needs work.]</span> 936 </p> 930 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.<span class="comment">[rfc.comment.13: DISCUSS: Not sure if this is necessary.]</span></p> 937 931 <h2 id="rfc.section.2.7"><a href="#rfc.section.2.7">2.7</a> <a id="combining.headers" href="#combining.headers">Combining Responses</a></h2> 938 932 <p id="rfc.section.2.7.p.1">When a cache receives a 304 (Not Modified) response or a 206 (Partial Content) response, it needs to update the stored response … … 956 950 such old headers <em class="bcp14">MUST</em> be replaced. it <em class="bcp14">MAY</em> store the combined entity-body. 957 951 </p> 958 <p id="rfc.section.2.7.p.5"><span class="comment">[rfc.comment.1 2: ISSUE: discuss how to handle HEAD updates]</span></p>952 <p id="rfc.section.2.7.p.5"><span class="comment">[rfc.comment.14: ISSUE: discuss how to handle HEAD updates]</span></p> 959 953 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> 960 954 <p id="rfc.section.3.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to caching.</p> … … 1405 1399 <td>http</td> 1406 1400 <td>standard</td> 1407 <td> <a href="#header.cache-control" id="rfc.xref.header.cache-control. 5" title="Cache-Control">Section 3.2</a>1401 <td> <a href="#header.cache-control" id="rfc.xref.header.cache-control.6" title="Cache-Control">Section 3.2</a> 1408 1402 </td> 1409 1403 </tr> … … 1542 1536 <h1 id="rfc.section.A"><a href="#rfc.section.A">A.</a> <a id="compatibility" href="#compatibility">Compatibility with Previous Versions</a></h1> 1543 1537 <h2 id="rfc.section.A.1"><a href="#rfc.section.A.1">A.1</a> <a id="changes.from.rfc.2068" href="#changes.from.rfc.2068">Changes from RFC 2068</a></h2> 1544 <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. 6" title="Cache-Control">3.2</a>).1538 <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.7" title="Cache-Control">3.2</a>). 1545 1539 </p> 1546 1540 <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 … … 1553 1547 </p> 1554 1548 <p id="rfc.section.A.1.p.5">The Cache-Control: max-age directive was not properly defined for responses.</p> 1555 <p id="rfc.section.A.1.p.6">Warnings could be cached incorrectly, or not updated appropriately. <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. 7" 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.1549 <p id="rfc.section.A.1.p.6">Warnings could be cached incorrectly, or not updated appropriately. <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.8" 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. 1556 1550 </p> 1557 1551 <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2> … … 1718 1712 </ul> 1719 1713 </li> 1720 <li class="indline1">Cache-Control header <a class="iref" href="#rfc.xref.header.cache-control.1">2.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.2">2. 2</a>, <a class="iref" href="#rfc.xref.header.cache-control.3">2.2</a>, <a class="iref" href="#rfc.xref.header.cache-control.4">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.5">5.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.6">A.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.7">A.1</a></li>1714 <li class="indline1">Cache-Control header <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.xref.header.cache-control.4">2.2</a>, <a class="iref" href="#rfc.xref.header.cache-control.5">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.6">5.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.7">A.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.8">A.1</a></li> 1721 1715 <li class="indline1">cacheable <a class="iref" href="#rfc.iref.c.2">1.2</a></li> 1722 1716 </ul> … … 1767 1761 <ul class="ind"> 1768 1762 <li class="indline1">Age <a class="iref" href="#rfc.xref.header.age.1">2.2</a>, <a class="iref" href="#rfc.iref.h.2"><b>3.1</b></a>, <a class="iref" href="#rfc.xref.header.age.2">5.1</a></li> 1769 <li class="indline1">Cache-Control <a class="iref" href="#rfc.xref.header.cache-control.1">2.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.2">2. 2</a>, <a class="iref" href="#rfc.xref.header.cache-control.3">2.2</a>, <a class="iref" href="#rfc.xref.header.cache-control.4">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.5">5.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.6">A.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.7">A.1</a></li>1763 <li class="indline1">Cache-Control <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.xref.header.cache-control.4">2.2</a>, <a class="iref" href="#rfc.xref.header.cache-control.5">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.6">5.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.7">A.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.8">A.1</a></li> 1770 1764 <li class="indline1">Expires <a class="iref" href="#rfc.xref.header.expires.1">2.3</a>, <a class="iref" href="#rfc.xref.header.expires.2">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.3">5.1</a></li> 1771 1765 <li class="indline1">Pragma <a class="iref" href="#rfc.xref.header.pragma.1">2.2</a>, <a class="iref" href="#rfc.xref.header.pragma.2">3.2</a>, <a class="iref" href="#rfc.iref.h.5"><b>3.4</b></a>, <a class="iref" href="#rfc.xref.header.pragma.3">5.1</a></li> … … 1841 1835 </ul> 1842 1836 </li> 1843 <li class="indline1"><em>Part2</em> <a class="iref" href="#rfc.xref.Part2.1">2. 5</a>, <a class="iref" href="#Part2"><b>8.1</b></a><ul class="ind">1844 <li class="indline1"><em>Section 7.1.1</em> <a class="iref" href="#rfc.xref.Part2.1">2. 5</a></li>1837 <li class="indline1"><em>Part2</em> <a class="iref" href="#rfc.xref.Part2.1">2.2</a>, <a class="iref" href="#rfc.xref.Part2.2">2.5</a>, <a class="iref" href="#Part2"><b>8.1</b></a><ul class="ind"> 1838 <li class="indline1"><em>Section 7.1.1</em> <a class="iref" href="#rfc.xref.Part2.1">2.2</a>, <a class="iref" href="#rfc.xref.Part2.2">2.5</a></li> 1845 1839 </ul> 1846 1840 </li> -
draft-ietf-httpbis/latest-roy/p7-auth.html
r461 r500 462 462 <tr> 463 463 <td class="header left"></td> 464 <td class="header right">March 2, 2009</td>464 <td class="header right">March 4, 2009</td> 465 465 </tr> 466 466 </table>
Note: See TracChangeset
for help on using the changeset viewer.