Changeset 441
- Timestamp:
- 31/01/09 20:56:49 (13 years ago)
- Location:
- draft-ietf-httpbis/latest-roy
- Files:
-
- 8 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest-roy/p1-messaging.html
r437 r441 221 221 margin-right: 0em; 222 222 padding-left: 0em; 223 page-break-before: avoid; 223 224 } 224 225 li.indline0 { … … 381 382 <link rel="Appendix" title="D Collected ABNF" href="#rfc.section.D"> 382 383 <link rel="Appendix" title="E Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.E"> 383 <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.4 00, 2008-10-10 14:04:14, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">384 <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/"> 384 385 <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/"> 385 386 <meta name="DC.Creator" content="Fielding, R."> … … 477 478 <tr> 478 479 <td class="header left"></td> 479 <td class="header right">December 11,2008</td>480 <td class="header right">December 2008</td> 480 481 </tr> 481 482 </table> … … 711 712 <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="notation" href="#notation">Syntax Notation</a></h2> 712 713 <div id="core.rules"> 713 <p id="rfc.section.1.2.p.1"> This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>. The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234# section-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG714 <p id="rfc.section.1.2.p.1"> This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>. The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG 714 715 (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), VCHAR (any visible <a href="#USASCII" id="rfc.xref.USASCII.1"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a> character), and WSP (whitespace). 715 716 </p> -
draft-ietf-httpbis/latest-roy/p2-semantics.html
r437 r441 221 221 margin-right: 0em; 222 222 padding-left: 0em; 223 page-break-before: avoid; 223 224 } 224 225 li.indline0 { … … 380 381 <link rel="Appendix" title="B Collected ABNF" href="#rfc.section.B"> 381 382 <link rel="Appendix" title="C Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.C"> 382 <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.4 00, 2008-10-10 14:04:14, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">383 <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/"> 383 384 <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/"> 384 385 <meta name="DC.Creator" content="Fielding, R."> … … 477 478 <tr> 478 479 <td class="header left"></td> 479 <td class="header right">December 11,2008</td>480 <td class="header right">December 2008</td> 480 481 </tr> 481 482 </table> … … 678 679 </p> 679 680 <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="notation" href="#notation">Syntax Notation</a></h2> 680 <p id="rfc.section.1.2.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234# section-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG681 <p id="rfc.section.1.2.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG 681 682 (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), VCHAR (any visible USASCII character), 682 683 and WSP (whitespace). -
draft-ietf-httpbis/latest-roy/p3-payload.html
r437 r441 228 228 margin-right: 0em; 229 229 padding-left: 0em; 230 page-break-before: avoid; 230 231 } 231 232 li.indline0 { … … 388 389 <link rel="Appendix" title="D Collected ABNF" href="#rfc.section.D"> 389 390 <link rel="Appendix" title="E Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.E"> 390 <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.4 00, 2008-10-10 14:04:14, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">391 <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/"> 391 392 <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/"> 392 393 <meta name="DC.Creator" content="Fielding, R."> … … 484 485 <tr> 485 486 <td class="header left"></td> 486 <td class="header right">December 11,2008</td>487 <td class="header right">December 2008</td> 487 488 </tr> 488 489 </table> … … 638 639 </p> 639 640 <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="notation" href="#notation">Syntax Notation</a></h2> 640 <p id="rfc.section.1.2.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234# section-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG641 <p id="rfc.section.1.2.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG 641 642 (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), VCHAR (any visible USASCII character), 642 643 and WSP (whitespace). -
draft-ietf-httpbis/latest-roy/p4-conditional.html
r437 r441 221 221 margin-right: 0em; 222 222 padding-left: 0em; 223 page-break-before: avoid; 223 224 } 224 225 li.indline0 { … … 377 378 <link rel="Appendix" title="B Collected ABNF" href="#rfc.section.B"> 378 379 <link rel="Appendix" title="C Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.C"> 379 <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.4 00, 2008-10-10 14:04:14, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">380 <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/"> 380 381 <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/"> 381 382 <meta name="DC.Creator" content="Fielding, R."> … … 473 474 <tr> 474 475 <td class="header left"></td> 475 <td class="header right">December 11,2008</td>476 <td class="header right">December 2008</td> 476 477 </tr> 477 478 </table> … … 586 587 </p> 587 588 <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="notation" href="#notation">Syntax Notation</a></h2> 588 <p id="rfc.section.1.2.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234# section-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG589 <p id="rfc.section.1.2.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG 589 590 (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), VCHAR (any visible USASCII character), 590 591 and WSP (whitespace). -
draft-ietf-httpbis/latest-roy/p5-range.html
r437 r441 221 221 margin-right: 0em; 222 222 padding-left: 0em; 223 page-break-before: avoid; 223 224 } 224 225 li.indline0 { … … 377 378 <link rel="Appendix" title="C Collected ABNF" href="#rfc.section.C"> 378 379 <link rel="Appendix" title="D Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.D"> 379 <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.4 00, 2008-10-10 14:04:14, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">380 <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/"> 380 381 <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/"> 381 382 <meta name="DC.Creator" content="Fielding, R."> … … 473 474 <tr> 474 475 <td class="header left"></td> 475 <td class="header right">December 11,2008</td>476 <td class="header right">December 2008</td> 476 477 </tr> 477 478 </table> … … 590 591 </p> 591 592 <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="notation" href="#notation">Syntax Notation</a></h2> 592 <p id="rfc.section.1.2.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234# section-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG593 <p id="rfc.section.1.2.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG 593 594 (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), VCHAR (any visible USASCII character), 594 595 and WSP (whitespace). -
draft-ietf-httpbis/latest-roy/p6-cache.html
r437 r441 224 224 margin-right: 0em; 225 225 padding-left: 0em; 226 page-break-before: avoid; 226 227 } 227 228 li.indline0 { … … 378 379 <link rel="Appendix" title="A Compatibility with Previous Versions" href="#rfc.section.A"> 379 380 <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.4 00, 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/"> 381 382 <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/"> 382 383 <meta name="DC.Creator" content="Fielding, R."> … … 474 475 <tr> 475 476 <td class="header left"></td> 476 <td class="header right">December 11,2008</td>477 <td class="header right">December 2008</td> 477 478 </tr> 478 479 </table> … … 687 688 </li> 688 689 </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 explicit ly690 expirationtime, 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. 691 692 </p> 692 693 <h3 id="rfc.section.3.1.1"><a href="#rfc.section.3.1.1">3.1.1</a> <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. 694 695 </p> 695 696 <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. … … 699 700 </p> 700 701 <ul> 701 <li>the presented request-URI and that of the stored response match (see <span class="comment">[rfc.comment. 1: TBD]</span>), and702 <li>the presented request-URI and that of the stored response match (see <span class="comment">[rfc.comment.2: TBD]</span>), and 702 703 </li> 703 704 <li>selecting headers nominated by the stored response (if any) match (see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 3.6</a>), and … … 708 709 </li> 709 710 </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> 711 712 </p> 712 713 <p id="rfc.section.3.2.p.3">A shared cache <em class="bcp14">MAY</em> return a stored response, provided that: … … 726 727 <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 3.4</a>). 727 728 </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> 729 730 </p> 730 731 <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a> <a id="expiration.model" href="#expiration.model">Freshness Model</a></h2> 731 732 <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 732 733 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>. 734 735 </p> 735 736 <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 … … 737 738 </p> 738 739 <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 4.3</a> or the max-age response cache directive <a href="#cache-response-directive" title="Response Cache-Control Directives">Section 4.2.2</a>. Generally, origin servers will assign future explicit expiration times to responses in the belief that the entity is not740 using either the Expires header (<a href="#header.expires" id="rfc.xref.header.expires.1" title="Expires">Section 4.3</a>) or the max-age response cache directive (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section 4.2.2</a>). Generally, origin servers will assign future explicit expiration times to responses in the belief that the entity is not 740 741 likely to change in a semantically significant way before the expiration time is reached. This normally preserves cache correctness, 741 742 as long as the server's expiration times are carefully chosen. … … 756 757 with the effect of either increasing or loosening constraints on freshness. See <a href="#cache-request-directive" title="Request Cache-Control Directives">Section 4.2.1</a>. 757 758 </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> 759 760 </p> 760 761 <h3 id="rfc.section.3.3.1"><a href="#rfc.section.3.3.1">3.3.1</a> <a id="calculating.freshness.lifetime" href="#calculating.freshness.lifetime">Calculating Freshness Lifetime</a></h3> … … 778 779 not already present. 779 780 </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> 783 784 </p> 784 785 <h3 id="rfc.section.3.3.2"><a href="#rfc.section.3.3.2">3.3.2</a> <a id="age.calculations" href="#age.calculations">Calculating Age</a></h3> … … 850 851 <p id="rfc.section.3.3.3.p.4">Otherwise, caches <em class="bcp14">SHOULD NOT</em> return stale responses. 851 852 </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 4.6</a>). 853 854 </p> 854 855 <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 … … 860 861 </p> 861 862 <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 state863 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 864 of the requested resource and, if they match, the server responds with a 304 (Not Modified) status code to indicate that the 864 865 stored response can be refreshed and reused without retransmitting the response payload. If the validator does not match the … … 884 885 attacks. 885 886 </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> 887 888 </p> 888 889 <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. … … 894 895 change at the origin server might not have gone through the cache where a response is stored. 895 896 </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> 897 898 </p> 898 899 <h2 id="rfc.section.3.6"><a href="#rfc.section.3.6">3.6</a> <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 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 4.5</a>) in a response, alters the conditions and procedure by which a cache can use the response for subsequent requests. 900 901 </p> 901 902 <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, … … 904 905 </p> 905 906 <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 field907 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 907 908 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>. 908 909 </p> … … 927 928 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. 928 929 </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> 930 931 </p> 931 932 <h2 id="rfc.section.3.7"><a href="#rfc.section.3.7">3.7</a> <a id="combining.headers" href="#combining.headers">Combining Responses</a></h2> … … 950 951 such old headers <em class="bcp14">MUST</em> be replaced. it <em class="bcp14">MAY</em> store the combined entity-body. 951 952 </p> 952 <p id="rfc.section.3.7.p.5"><span class="comment">[rfc.comment.1 0: 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> 953 954 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> 954 955 <p id="rfc.section.4.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to caching.</p> … … 1529 1530 <h1 id="rfc.section.A"><a href="#rfc.section.A">A.</a> <a id="compatibility" href="#compatibility">Compatibility with Previous Versions</a></h1> 1530 1531 <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> 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>). 1532 1533 </p> 1533 1534 <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 -
draft-ietf-httpbis/latest-roy/p6-cache.xml
r437 r441 382 382 </t> 383 383 <t>Note that in normal operation, most caches will not store a response that has neither a 384 cache validator nor an explicit lyexpiration time, as such responses are not usually384 cache validator nor an explicit expiration time, as such responses are not usually 385 385 useful to store. However, caches are not prohibited from storing such responses.</t> 386 386 … … 388 388 title="Storing Incomplete Responses"> 389 389 <t>A cache that receives an incomplete response (for example, with fewer bytes of data 390 than specified in a Content-Length header) &MAY; store the response . However, the390 than specified in a Content-Length header) &MAY; store the response <cref source="JRE">Indeed? Is this new?</cref>. However, the 391 391 cache &MUST; treat this as a partial response &partial;. Partial responses 392 392 &MAY; be combined as described in &combining-byte-ranges;; the result might be a … … 451 451 <t>HTTP caching works best when caches can entirely avoid making requests to the origin 452 452 server. When a response is "fresh" in the cache, it can be used to satisfy subsequent 453 requests without contacting the origin server. This is also referred to as "expiration."< /t>453 requests without contacting the origin server. This is also referred to as "expiration."<cref source="JRE">What exactly is called 'expiration'?</cref>.</t> 454 454 <t>Expiration applies only to responses taken from a cache and not to first-hand responses. 455 455 It cannot be used to force a user agent to refresh its display or reload a resource; its … … 457 457 the difference between caches and history mechanisms.</t> 458 458 <t>The primary mechanism for avoiding requests is for an origin server to provide an 459 explicit expiration time in the future, using either the Expires header <xref460 target="header.expires" /> or the max-age response cache directive<xref461 target="cache-response-directive" /> . Generally, origin servers will assign future459 explicit expiration time in the future, using either the Expires header (<xref 460 target="header.expires" />) or the max-age response cache directive (<xref 461 target="cache-response-directive" />). Generally, origin servers will assign future 462 462 explicit expiration times to responses in the belief that the entity is not likely to 463 463 change in a semantically significant way before the expiration time is reached. This … … 512 512 attach a Warning header with a 113 warn-code to the response if its current_age is 513 513 more than 24 hours and such a warning is not already present.</t> 514 <t>Also, if the response has a Last-Modified header &header-last-modified;, the514 <t>Also, if the response has a Last-Modified header (&header-last-modified;), the 515 515 heuristic expiration value &SHOULD; be no more than some fraction of the interval 516 516 since that time. A typical setting of this fraction might be 10%.</t> … … 610 610 <t>Otherwise, caches &SHOULD-NOT; return stale responses.</t> 611 611 <t>Stale responses &SHOULD; have a Warning header with the 110 warn-code (see <xref 612 format="counter"target="header.warning" />).</t>612 target="header.warning" />).</t> 613 613 <t>If a cache receives a first-hand response (either an entire response, or a 304 (Not 614 614 Modified) response) that it would normally forward to the requesting client, and the … … 627 627 <t>HTTP's conditional request mechanism, defined in &conditional;, is used to avoid 628 628 retransmitting the response payload when the stored response is valid. When a stored 629 response includes one or more "cache validators ,"such as the field values of an ETag or629 response includes one or more "cache validators", such as the field values of an ETag or 630 630 Last-Modified header field, then a validating GET request &SHOULD; be made conditional 631 631 to those field values. The server checks the conditional request's validator against the … … 682 682 <section anchor="caching.negotiated.responses" title="Caching Negotiated Responses"> 683 683 <t>Use of server-driven content negotiation (&server-driven-negotiation;), as indicated 684 by the presence of a Vary header field <xref target="header.vary" />in a response, alters684 by the presence of a Vary header field (<xref target="header.vary" />) in a response, alters 685 685 the conditions and procedure by which a cache can use the response for subsequent 686 686 requests.</t> … … 1792 1792 <t>A case was missed in the Cache-Control model of HTTP/1.1; s-maxage was introduced to add 1793 1793 this missing case. (Sections <xref format="counter" target="response.cacheability" />, 1794 <xref format="counter" target="header.cache-control" /> .</t>1794 <xref format="counter" target="header.cache-control" />).</t> 1795 1795 <t>Transfer-coding and message lengths all interact in ways that required fixing exactly 1796 1796 when chunked encoding is used (to allow for transfer encoding that may not be self -
draft-ietf-httpbis/latest-roy/p7-auth.html
r437 r441 221 221 margin-right: 0em; 222 222 padding-left: 0em; 223 page-break-before: avoid; 223 224 } 224 225 li.indline0 { … … 374 375 <link rel="Appendix" title="B Collected ABNF" href="#rfc.section.B"> 375 376 <link rel="Appendix" title="C Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.C"> 376 <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.4 00, 2008-10-10 14:04:14, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">377 <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/"> 377 378 <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/"> 378 379 <meta name="DC.Creator" content="Fielding, R."> … … 471 472 <tr> 472 473 <td class="header left"></td> 473 <td class="header right">December 11,2008</td>474 <td class="header right">December 2008</td> 474 475 </tr> 475 476 </table> … … 577 578 </p> 578 579 <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="notation" href="#notation">Syntax Notation</a></h2> 579 <p id="rfc.section.1.2.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234# section-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG580 <p id="rfc.section.1.2.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG 580 581 (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), VCHAR (any visible USASCII character), 581 582 and WSP (whitespace).
Note: See TracChangeset
for help on using the changeset viewer.