Changeset 441


Ignore:
Timestamp:
Jan 31, 2009, 12:56:49 PM (11 years ago)
Author:
julian.reschke@…
Message:

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

Location:
draft-ietf-httpbis/latest-roy
Files:
8 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest-roy/p1-messaging.html

    r437 r441  
    221221  margin-right: 0em;
    222222  padding-left: 0em;
     223  page-break-before: avoid;
    223224}
    224225li.indline0 {
     
    381382      <link rel="Appendix" title="D Collected ABNF" href="#rfc.section.D">
    382383      <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.400, 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/">
    384385      <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/">
    385386      <meta name="DC.Creator" content="Fielding, R.">
     
    477478         <tr>
    478479            <td class="header left"></td>
    479             <td class="header right">December 11, 2008</td>
     480            <td class="header right">December 2008</td>
    480481         </tr>
    481482      </table>
     
    711712      <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>
    712713      <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), HEXDIG
     714         <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
    714715            (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).
    715716         </p>
  • draft-ietf-httpbis/latest-roy/p2-semantics.html

    r437 r441  
    221221  margin-right: 0em;
    222222  padding-left: 0em;
     223  page-break-before: avoid;
    223224}
    224225li.indline0 {
     
    380381      <link rel="Appendix" title="B Collected ABNF" href="#rfc.section.B">
    381382      <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.400, 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/">
    383384      <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/">
    384385      <meta name="DC.Creator" content="Fielding, R.">
     
    477478         <tr>
    478479            <td class="header left"></td>
    479             <td class="header right">December 11, 2008</td>
     480            <td class="header right">December 2008</td>
    480481         </tr>
    481482      </table>
     
    678679      </p>
    679680      <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<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), HEXDIG
     681      <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
    681682         (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), VCHAR (any visible USASCII character),
    682683         and WSP (whitespace).
  • draft-ietf-httpbis/latest-roy/p3-payload.html

    r437 r441  
    228228  margin-right: 0em;
    229229  padding-left: 0em;
     230  page-break-before: avoid;
    230231}
    231232li.indline0 {
     
    388389      <link rel="Appendix" title="D Collected ABNF" href="#rfc.section.D">
    389390      <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.400, 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/">
    391392      <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/">
    392393      <meta name="DC.Creator" content="Fielding, R.">
     
    484485         <tr>
    485486            <td class="header left"></td>
    486             <td class="header right">December 11, 2008</td>
     487            <td class="header right">December 2008</td>
    487488         </tr>
    488489      </table>
     
    638639      </p>
    639640      <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<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), HEXDIG
     641      <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
    641642         (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), VCHAR (any visible USASCII character),
    642643         and WSP (whitespace).
  • draft-ietf-httpbis/latest-roy/p4-conditional.html

    r437 r441  
    221221  margin-right: 0em;
    222222  padding-left: 0em;
     223  page-break-before: avoid;
    223224}
    224225li.indline0 {
     
    377378      <link rel="Appendix" title="B Collected ABNF" href="#rfc.section.B">
    378379      <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.400, 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/">
    380381      <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/">
    381382      <meta name="DC.Creator" content="Fielding, R.">
     
    473474         <tr>
    474475            <td class="header left"></td>
    475             <td class="header right">December 11, 2008</td>
     476            <td class="header right">December 2008</td>
    476477         </tr>
    477478      </table>
     
    586587      </p>
    587588      <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<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), HEXDIG
     589      <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
    589590         (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), VCHAR (any visible USASCII character),
    590591         and WSP (whitespace).
  • draft-ietf-httpbis/latest-roy/p5-range.html

    r437 r441  
    221221  margin-right: 0em;
    222222  padding-left: 0em;
     223  page-break-before: avoid;
    223224}
    224225li.indline0 {
     
    377378      <link rel="Appendix" title="C Collected ABNF" href="#rfc.section.C">
    378379      <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.400, 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/">
    380381      <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/">
    381382      <meta name="DC.Creator" content="Fielding, R.">
     
    473474         <tr>
    474475            <td class="header left"></td>
    475             <td class="header right">December 11, 2008</td>
     476            <td class="header right">December 2008</td>
    476477         </tr>
    477478      </table>
     
    590591      </p>
    591592      <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<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), HEXDIG
     593      <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
    593594         (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), VCHAR (any visible USASCII character),
    594595         and WSP (whitespace).
  • draft-ietf-httpbis/latest-roy/p6-cache.html

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

    r437 r441  
    382382        </t>
    383383        <t>Note that in normal operation, most caches will not store a response that has neither a
    384           cache validator nor an explicitly expiration time, as such responses are not usually
     384          cache validator nor an explicit expiration time, as such responses are not usually
    385385          useful to store. However, caches are not prohibited from storing such responses.</t>
    386386
     
    388388          title="Storing Incomplete Responses">
    389389          <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, the
     390            than specified in a Content-Length header) &MAY; store the response <cref source="JRE">Indeed? Is this new?</cref>. However, the
    391391            cache &MUST; treat this as a partial response &partial;. Partial responses
    392392            &MAY; be combined as described in &combining-byte-ranges;; the result might be a
     
    451451        <t>HTTP caching works best when caches can entirely avoid making requests to the origin
    452452          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>
    454454        <t>Expiration applies only to responses taken from a cache and not to first-hand responses.
    455455          It cannot be used to force a user agent to refresh its display or reload a resource; its
     
    457457          the difference between caches and history mechanisms.</t>
    458458        <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 <xref
    460             target="header.expires" /> or the max-age response cache directive <xref
    461             target="cache-response-directive" />. Generally, origin servers will assign future
     459          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
    462462          explicit expiration times to responses in the belief that the entity is not likely to
    463463          change in a semantically significant way before the expiration time is reached. This
     
    512512              attach a Warning header with a 113 warn-code to the response if its current_age is
    513513              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;, the
     514            <t>Also, if the response has a Last-Modified header (&header-last-modified;), the
    515515              heuristic expiration value &SHOULD; be no more than some fraction of the interval
    516516              since that time. A typical setting of this fraction might be 10%.</t>
     
    610610          <t>Otherwise, caches &SHOULD-NOT; return stale responses.</t>
    611611          <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>
    613613          <t>If a cache receives a first-hand response (either an entire response, or a 304 (Not
    614614            Modified) response) that it would normally forward to the requesting client, and the
     
    627627        <t>HTTP's conditional request mechanism, defined in &conditional;, is used to avoid
    628628          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 or
     629          response includes one or more "cache validators", such as the field values of an ETag or
    630630          Last-Modified header field, then a validating GET request &SHOULD; be made conditional
    631631          to those field values. The server checks the conditional request's validator against the
     
    682682      <section anchor="caching.negotiated.responses" title="Caching Negotiated Responses">
    683683        <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, alters
     684          by the presence of a Vary header field (<xref target="header.vary" />) in a response, alters
    685685          the conditions and procedure by which a cache can use the response for subsequent
    686686          requests.</t>
     
    17921792        <t>A case was missed in the Cache-Control model of HTTP/1.1; s-maxage was introduced to add
    17931793          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>
    17951795        <t>Transfer-coding and message lengths all interact in ways that required fixing exactly
    17961796          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  
    221221  margin-right: 0em;
    222222  padding-left: 0em;
     223  page-break-before: avoid;
    223224}
    224225li.indline0 {
     
    374375      <link rel="Appendix" title="B Collected ABNF" href="#rfc.section.B">
    375376      <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.400, 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/">
    377378      <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/">
    378379      <meta name="DC.Creator" content="Fielding, R.">
     
    471472         <tr>
    472473            <td class="header left"></td>
    473             <td class="header right">December 11, 2008</td>
     474            <td class="header right">December 2008</td>
    474475         </tr>
    475476      </table>
     
    577578      </p>
    578579      <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<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), HEXDIG
     580      <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
    580581         (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), VCHAR (any visible USASCII character),
    581582         and WSP (whitespace).
Note: See TracChangeset for help on using the changeset viewer.