![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
Changeset 609 for draft-ietf-httpbis/latest/p6-cache.html
- Timestamp:
- 13/07/09 08:30:27 (13 years ago)
- File:
-
- 1 edited
-
draft-ietf-httpbis/latest/p6-cache.html (modified) (12 diffs)
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p6-cache.html
r604 r609 473 473 <tr> 474 474 <td class="header left"></td> 475 <td class="header right">July 1 0, 2009</td>475 <td class="header right">July 13, 2009</td> 476 476 </tr> 477 477 </table> … … 871 871 </p> 872 872 <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> 873 <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" 874 or "revalidating." Doing so potentially avoids the overhead of retransmitting the response body when the stored response is 875 valid. 876 </p> 877 <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 878 header field, then a validating request <em class="bcp14">SHOULD</em> be made conditional to those field values. 879 </p> 880 <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>. 881 </p> 882 <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 883 the stored response. <span class="comment" id="rfc.comment.5">[<a href="#rfc.comment.5" class="smpl">rfc.comment.5</a>: Should there be a requirement here?]</span> 884 </p> 885 <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 (which <em class="bcp14">SHOULD</em> include the 111 warn-code; see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section 3.6</a>) 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>). 873 <p id="rfc.section.2.4.p.1">When a cache has one or more stored responses for a requested URI, but cannot serve any of them (e.g., because they are not 874 fresh, or one cannot be selected; see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2.6</a>), it can use the conditional request mechanism <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a> in the forwarded request to give the origin server an opportunity to both select a valid stored response to be used, and to 875 update it. This process is known as "validating" or "revalidating" the stored response. 876 </p> 877 <p id="rfc.section.2.4.p.2">When sending such a conditional request, the cache <em class="bcp14">SHOULD</em> add an If-Modified-Since header whose value is that of the Last-Modified header from the selected (see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2.6</a>) stored response, if available. 878 </p> 879 <p id="rfc.section.2.4.p.3">Additionally, the cache <em class="bcp14">SHOULD</em> add an If-None-Match header whose value is that of the ETag header(s) from all responses stored for the requested URI, if 880 present. However, 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 881 response. 882 </p> 883 <p id="rfc.section.2.4.p.4">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>. 884 </p> 885 <p id="rfc.section.2.4.p.5">A full response (i.e., one with a response body) indicates that none of the stored responses nominated in the conditional 886 request is suitable. Instead, the full response is used both to satisfy the request and replace the stored response. <span class="comment" id="rfc.comment.5">[<a href="#rfc.comment.5" class="smpl">rfc.comment.5</a>: Should there be a requirement here?]</span> 887 </p> 888 <p id="rfc.section.2.4.p.6">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 (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section 2.3.3</a>). 889 </p> 890 <p id="rfc.section.2.4.p.7">If a cache receives a successful response whose Content-Location field matches that of an existing stored response for the 891 same Request-URI, whose entity-tag differs from that of the existing stored response, and whose Date is more recent than that 892 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" id="rfc.comment.6">[<a href="#rfc.comment.6" class="smpl">rfc.comment.6</a>: DISCUSS: Not sure if this is necessary.]</span> 886 893 </p> 887 894 <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> … … 898 905 attacks. 899 906 </p> 900 <p id="rfc.section.2.5.p.4"> <span class="comment" id="rfc.comment. 6">[<a href="#rfc.comment.6" class="smpl">rfc.comment.6</a>: TODO: "host part" needs to be specified better.]</span>907 <p id="rfc.section.2.5.p.4"> <span class="comment" id="rfc.comment.7">[<a href="#rfc.comment.7" class="smpl">rfc.comment.7</a>: TODO: "host part" needs to be specified better.]</span> 901 908 </p> 902 909 <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. … … 908 915 change at the origin server might not have gone through the cache where a response is stored. 909 916 </p> 910 <p id="rfc.section.2.5.p.8"> <span class="comment" id="rfc.comment. 7">[<a href="#rfc.comment.7" class="smpl">rfc.comment.7</a>: TODO: specify that only successful (2xx, 3xx?) responses invalidate.]</span>917 <p id="rfc.section.2.5.p.8"> <span class="comment" id="rfc.comment.8">[<a href="#rfc.comment.8" class="smpl">rfc.comment.8</a>: TODO: specify that only successful (2xx, 3xx?) responses invalidate.]</span> 911 918 </p> 912 919 <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> 913 <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 under which a cache can use the response for subsequent requests. 914 </p> 915 <p id="rfc.section.2.6.p.2">When a cache receives a request that can 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 that response unless all of the selecting request-headers in the presented request match the corresponding stored request-headers 916 from the original request. 917 </p> 918 <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 919 request can be transformed to the selecting request-headers in the second request by adding or removing linear white space <span class="comment" id="rfc.comment.8">[<a href="#rfc.comment.8" class="smpl">rfc.comment.8</a>: [ref]]</span> at places where this is allowed by the corresponding ABNF, and/or combining multiple message-header fields with the same field 920 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" id="DISCUSS-header-specific-canonicalization">[<a href="#DISCUSS-header-specific-canonicalization" class="smpl">DISCUSS-header-specific-canonicalization</a>: Should the matching requirement be relaxed so that it would be ok to use a cached response if the selecting request headers 921 match after header-specific canonicalization? (see <a href="http://trac.tools.ietf.org/wg/httpbis/trac/ticket/147">Issue 147</a>)]</span> 922 </p> 920 <p id="rfc.section.2.6.p.1">When a cache receives a request that can be satisfied by a stored response that has 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 that response unless all of the selecting request-headers nominated by the Vary header match in both the original request 921 (i.e., that associated with the stored response), and the presented request. 922 </p> 923 <p id="rfc.section.2.6.p.2">The selecting request-headers from two requests are defined to match if and only if the selecting request-headers in the first 924 request can be transformed to the selecting request-headers in the second request by adding or removing linear white space <span class="comment" id="rfc.comment.9">[<a href="#rfc.comment.9" class="smpl">rfc.comment.9</a>: [ref]]</span> at places where this is allowed by the corresponding ABNF, and/or combining multiple message-header fields with the same field 925 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>. 926 </p> 927 <p id="rfc.section.2.6.p.3">If a header field is absent from a request, it can only match another request if it is also absent there.</p> 923 928 <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 924 929 by the origin server. 925 930 </p> 926 <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, and <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 927 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>. 928 </p> 929 <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 930 response. 931 </p> 932 <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 933 same Request-URI, whose entity-tag differs from that of the existing stored response, and whose Date is more recent than that 934 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" id="rfc.comment.9">[<a href="#rfc.comment.9" class="smpl">rfc.comment.9</a>: DISCUSS: Not sure if this is necessary.]</span> 931 <p id="rfc.section.2.6.p.5">The stored response with matching selecting request-headers is known as the selected response.</p> 932 <p id="rfc.section.2.6.p.6">If no selected response is available, the cache <em class="bcp14">MAY</em> forward the presented request to the origin server in a conditional request; see <a href="#validation.model" title="Validation Model">Section 2.4</a>. 935 933 </p> 936 934 <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> 937 <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 938 with the new one, so that the updated response can be sent to the client. 939 </p> 940 <p id="rfc.section.2.7.p.2">If the status code is 304 (Not Modified), the cache <em class="bcp14">SHOULD</em> use the stored entity-body as the updated entity-body. If the status code is 206 (Partial Content) and the ETag or Last-Modified 941 headers match exactly, the cache <em class="bcp14">MAY</em> combine the stored entity-body in the stored response with the updated entity-body received in the response and use the result 942 as the updated entity-body (see <a href="p5-range.html#combining.byte.ranges" title="Combining Ranges">Section 4</a> of <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>). 943 </p> 944 <p id="rfc.section.2.7.p.3">The stored response headers are used for the updated response, except that </p> 935 <p id="rfc.section.2.7.p.1">When a cache receives a 304 (Not Modified) response or a 206 (Partial Content) response (in this section, the "new" response"), 936 it needs to created an updated response by combining the stored response with the new one, so that the updated response can 937 be used to satisfy the request. 938 </p> 939 <p id="rfc.section.2.7.p.2">If the new response contains an ETag, it identifies the stored response to use. <span class="comment" id="rfc.comment.10">[<a href="#rfc.comment.10" class="smpl">rfc.comment.10</a>: may need language about Content-Location here]</span><span class="comment" id="rfc.comment.11">[<a href="#rfc.comment.11" class="smpl">rfc.comment.11</a>: cover case where INM with multiple etags was sent]</span> 940 </p> 941 <p id="rfc.section.2.7.p.3">If the status code is 206 (partial content), both the stored and new responses <em class="bcp14">MUST</em> have ETags, and those ETags <em class="bcp14">MUST</em> match using the strong comparison function (see <a href="p4-conditional.html#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). Otherwise, the responses <em class="bcp14">MUST NOT</em> be combined. 942 </p> 943 <p id="rfc.section.2.7.p.4">The stored response headers are used as those of the updated response, except that </p> 945 944 <ul> 946 <li>any stored Warning headers with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning. 3" title="Warning">Section 3.6</a>) <em class="bcp14">MUST</em> be deleted from the stored response and the forwarded response.947 </li> 948 <li>any stored Warning headers with warn-code 2xx <em class="bcp14">MUST</em> be retained in the stored response and the forwarded response.949 </li> 950 <li>any headers provided in the 304 or 206response <em class="bcp14">MUST</em> replace the corresponding headers from the stored response.945 <li>any stored Warning headers with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section 3.6</a>) <em class="bcp14">MUST</em> be deleted from the stored response and the updated response. 946 </li> 947 <li>any stored Warning headers with warn-code 2xx <em class="bcp14">MUST</em> be retained in the stored response and the updated response. 948 </li> 949 <li>any headers provided in the new response <em class="bcp14">MUST</em> replace the corresponding headers from the stored response. 951 950 </li> 952 951 </ul> 953 <p id="rfc.section.2.7.p. 4">A cache <em class="bcp14">MUST</em> also replace any stored headers with corresponding headers received in the incoming response, except for Warning headers as954 described immediately above. If a header field-name in the incoming response matches more than one header in the stored response,955 all such old headers <em class="bcp14">MUST</em> be replaced. It <em class="bcp14">MAY</em> store the combined entity-body.956 </p> 957 <p id="rfc.section.2.7.p. 5"> <span class="comment" id="rfc.comment.10">[<a href="#rfc.comment.10" class="smpl">rfc.comment.10</a>: ISSUE: discuss how to handle HEAD updates]</span>952 <p id="rfc.section.2.7.p.5">If a header field-name in the new response matches more than one header in the stored response, all such stored headers <em class="bcp14">MUST</em> be replaced. 953 </p> 954 <p id="rfc.section.2.7.p.6">The updated response can [[<span class="comment" id="rfc.comment.12">[<a href="#rfc.comment.12" class="smpl">rfc.comment.12</a>: requirement?]</span>]] be used to replace the stored response in cache. In the case of a 206 response, the combined entity-body <em class="bcp14">MAY</em> be stored. 955 </p> 956 <p id="rfc.section.2.7.p.7"> <span class="comment" id="rfc.comment.13">[<a href="#rfc.comment.13" class="smpl">rfc.comment.13</a>: ISSUE: discuss how to handle HEAD updates]</span> 958 957 </p> 959 958 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> … … 1041 1040 time. If max-stale is assigned a value, then the client is willing to accept a response that has exceeded its expiration time 1042 1041 by no more than the specified number of seconds. If no value is assigned to max-stale, then the client is willing to accept 1043 a stale response of any age. <span class="comment" id="rfc.comment.1 1">[<a href="#rfc.comment.11" class="smpl">rfc.comment.11</a>: of any staleness? --mnot]</span></dd>1042 a stale response of any age. <span class="comment" id="rfc.comment.14">[<a href="#rfc.comment.14" class="smpl">rfc.comment.14</a>: of any staleness? --mnot]</span></dd> 1044 1043 </dl> 1045 1044 <p id="rfc.section.3.2.1.p.6"> <span id="rfc.iref.c.8"></span> <span id="rfc.iref.m.3"></span> min-fresh … … 1429 1428 <td>http</td> 1430 1429 <td>standard</td> 1431 <td> <a href="#header.warning" id="rfc.xref.header.warning. 4" title="Warning">Section 3.6</a>1430 <td> <a href="#header.warning" id="rfc.xref.header.warning.3" title="Warning">Section 3.6</a> 1432 1431 </td> 1433 1432 </tr> … … 1545 1544 <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 1546 1545 for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are 1547 computed. (see also <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="#Part3" id="rfc.xref.Part3. 2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> and <a href="#Part5" id="rfc.xref.Part5.4"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) <span class="comment" id="rfc.comment.12">[<a href="#rfc.comment.12" class="smpl">rfc.comment.12</a>: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span>1548 </p> 1549 <p id="rfc.section.A.1.p.3">Proxies should be able to add Content-Length when appropriate. <span class="comment" id="rfc.comment.1 3">[<a href="#rfc.comment.13" class="smpl">rfc.comment.13</a>: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span>1546 computed. (see also <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> and <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) <span class="comment" id="rfc.comment.15">[<a href="#rfc.comment.15" class="smpl">rfc.comment.15</a>: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span> 1547 </p> 1548 <p id="rfc.section.A.1.p.3">Proxies should be able to add Content-Length when appropriate. <span class="comment" id="rfc.comment.16">[<a href="#rfc.comment.16" class="smpl">rfc.comment.16</a>: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span> 1550 1549 </p> 1551 1550 <p id="rfc.section.A.1.p.4">Range request responses would become very verbose if all meta-data were always returned; by allowing the server to only send … … 1554 1553 <p id="rfc.section.A.1.p.5">The Cache-Control: max-age directive was not properly defined for responses. (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section 3.2.2</a>) 1555 1554 </p> 1556 <p id="rfc.section.A.1.p.6">Warnings could be cached incorrectly, or not updated appropriately. (Section <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. 5" 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.1555 <p id="rfc.section.A.1.p.6">Warnings could be cached incorrectly, or not updated appropriately. (Section <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. 1557 1556 </p> 1558 1557 <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 1717 <ul> 1719 1718 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/161">http://tools.ietf.org/wg/httpbis/trac/ticket/161</a>>: "base for numeric protocol elements" 1719 </li> 1720 </ul> 1721 <p id="rfc.section.C.8.p.2">Affected issues: </p> 1722 <ul> 1723 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/37">http://tools.ietf.org/wg/httpbis/trac/ticket/37</a>>: Vary and non-existant headers 1720 1724 </li> 1721 1725 </ul> … … 1803 1807 <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> 1804 1808 <li class="indline1">Vary <a class="iref" href="#rfc.xref.header.vary.1">2.6</a>, <a class="iref" href="#rfc.iref.h.6"><b>3.5</b></a>, <a class="iref" href="#rfc.xref.header.vary.2">5.1</a></li> 1805 <li class="indline1">Warning <a class="iref" href="#rfc.xref.header.warning.1">2.3.3</a>, <a class="iref" href="#rfc.xref.header.warning.2">2. 4</a>, <a class="iref" href="#rfc.xref.header.warning.3">2.7</a>, <a class="iref" href="#rfc.iref.h.7"><b>3.6</b></a>, <a class="iref" href="#rfc.xref.header.warning.4">5.1</a>, <a class="iref" href="#rfc.xref.header.warning.5">A.1</a></li>1809 <li class="indline1">Warning <a class="iref" href="#rfc.xref.header.warning.1">2.3.3</a>, <a class="iref" href="#rfc.xref.header.warning.2">2.7</a>, <a class="iref" href="#rfc.iref.h.7"><b>3.6</b></a>, <a class="iref" href="#rfc.xref.header.warning.3">5.1</a>, <a class="iref" href="#rfc.xref.header.warning.4">A.1</a></li> 1806 1810 </ul> 1807 1811 </li> … … 1877 1881 </ul> 1878 1882 </li> 1879 <li class="indline1"><em>Part3</em> <a class="iref" href="#rfc.xref.Part3.1">2.6</a>, <a class="iref" href="#Part3"><b>8.1</b></a>, <a class="iref" href="#rfc.xref.Part3.2">A.1</a><ul class="ind"> 1880 <li class="indline1"><em>Section 4.1</em> <a class="iref" href="#rfc.xref.Part3.1">2.6</a></li> 1881 </ul> 1882 </li> 1883 <li class="indline1"><em>Part4</em> <a class="iref" href="#rfc.xref.Part4.1">2.3.1.1</a>, <a class="iref" href="#rfc.xref.Part4.2">2.4</a>, <a class="iref" href="#Part4"><b>8.1</b></a><ul class="ind"> 1883 <li class="indline1"><em>Part3</em> <a class="iref" href="#Part3"><b>8.1</b></a>, <a class="iref" href="#rfc.xref.Part3.1">A.1</a></li> 1884 <li class="indline1"><em>Part4</em> <a class="iref" href="#rfc.xref.Part4.1">2.3.1.1</a>, <a class="iref" href="#rfc.xref.Part4.2">2.4</a>, <a class="iref" href="#rfc.xref.Part4.3">2.7</a>, <a class="iref" href="#Part4"><b>8.1</b></a><ul class="ind"> 1885 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.Part4.3">2.7</a></li> 1884 1886 <li class="indline1"><em>Section 6.6</em> <a class="iref" href="#rfc.xref.Part4.1">2.3.1.1</a></li> 1885 1887 </ul> 1886 1888 </li> 1887 <li class="indline1"><em>Part5</em> <a class="iref" href="#rfc.xref.Part5.1">2.1.1</a>, <a class="iref" href="#rfc.xref.Part5.2">2.1.1</a>, <a class="iref" href="# rfc.xref.Part5.3">2.7</a>, <a class="iref" href="#Part5"><b>8.1</b></a>, <a class="iref" href="#rfc.xref.Part5.4">A.1</a><ul class="ind">1888 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.Part5.2">2.1.1</a> , <a class="iref" href="#rfc.xref.Part5.3">2.7</a></li>1889 <li class="indline1"><em>Part5</em> <a class="iref" href="#rfc.xref.Part5.1">2.1.1</a>, <a class="iref" href="#rfc.xref.Part5.2">2.1.1</a>, <a class="iref" href="#Part5"><b>8.1</b></a>, <a class="iref" href="#rfc.xref.Part5.3">A.1</a><ul class="ind"> 1890 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.Part5.2">2.1.1</a></li> 1889 1891 </ul> 1890 1892 </li> … … 1938 1940 </li> 1939 1941 <li class="indline0"><a id="rfc.index.W" href="#rfc.index.W"><b>W</b></a><ul class="ind"> 1940 <li class="indline1">Warning header <a class="iref" href="#rfc.xref.header.warning.1">2.3.3</a>, <a class="iref" href="#rfc.xref.header.warning.2">2. 4</a>, <a class="iref" href="#rfc.xref.header.warning.3">2.7</a>, <a class="iref" href="#rfc.iref.w.1"><b>3.6</b></a>, <a class="iref" href="#rfc.xref.header.warning.4">5.1</a>, <a class="iref" href="#rfc.xref.header.warning.5">A.1</a></li>1942 <li class="indline1">Warning header <a class="iref" href="#rfc.xref.header.warning.1">2.3.3</a>, <a class="iref" href="#rfc.xref.header.warning.2">2.7</a>, <a class="iref" href="#rfc.iref.w.1"><b>3.6</b></a>, <a class="iref" href="#rfc.xref.header.warning.3">5.1</a>, <a class="iref" href="#rfc.xref.header.warning.4">A.1</a></li> 1941 1943 </ul> 1942 1944 </li>
Note: See TracChangeset
for help on using the changeset viewer.
