Source: https://trac.ietf.org/trac/httpbis/browser/draft-ietf-httpbis/latest/p6-cache.html?rev=1398
Timestamp: 2020-01-18 00:33:08
Document Index: 271622038

Matched Legal Cases: ['art1', 'art1', 'art 1', 'art1', 'art1', 'art1', 'art 1', 'art1', 'art1', 'art1', 'art 1', 'art1', 'art1', 'art1', 'art 1', 'art1', 'art2', 'art2', 'art 2', 'art2', 'art2', 'art2', 'art 2', 'art2', 'art2', 'art2', 'art 2', 'art2', 'art4', 'art4', 'art 4', 'art4', 'art1', 'art1', 'art 1', 'art1', 'art2', 'art2', 'art 2', 'art2', 'art1', 'art1', 'art 1', 'art1', 'art1', 'art1', 'art 1', 'art1', 'art1', 'art1', 'art 1', 'art1', 'art1', 'art1', 'art 1', 'art1', 'art1', 'art1', 'art 1', 'art1', 'art1', 'art1', 'art 1', 'art1', 'art 1', 'art 2', 'art 4', 'art 5', 'art 7', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2']

source: draft-ietf-httpbis/latest/p6-cache.html @ 1398
Last change on this file since 1398 was 1396, checked in by julian.reschke@…, 8 years ago
fix ABNF links (see [1393])
content: "August 2011";
content: "Expires February 10, 2012";
<meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.553, 2011-07-27 17:45:31, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
<meta name="dct.issued" scheme="ISO8601" content="2011-08-09">
<td class="left">Expires: February 10, 2012</td>
<td class="right">August 9, 2011</td>
<p>The changes in this draft are summarized in <a href="#changes.since.15" title="Since draft-ietf-httpbis-p6-cache-15">Appendix&nbsp;C.17</a>.
<p>This Internet-Draft will expire on February 10, 2012.</p>
<li>2.4&nbsp;&nbsp;&nbsp;<a href="#validation.model">Validation Model</a></li>
<li>2.9&nbsp;&nbsp;&nbsp;<a href="#freshening.responses">Freshening Responses</a></li>
<li>3.&nbsp;&nbsp;&nbsp;<a href="#header.fields">Header Field Definitions</a><ul>
<li>3.6&nbsp;&nbsp;&nbsp;<a href="#header.warning">Warning</a></li>
<p id="rfc.section.1.4.1.p.1">The core rules below are defined in <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>:
<div id="rfc.figure.u.1"></div><pre class="inline"> <a href="#core.rules" class="smpl">OWS</a> = &lt;OWS, defined in <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>&gt;
<a href="#core.rules" class="smpl">quoted-string</a> = &lt;quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>&gt;
<a href="#core.rules" class="smpl">token</a> = &lt;token, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>&gt;
its subsequent calculations overflows, it <em class="bcp14">MUST</em> consider the value to be 2147483648 (2<sup>31</sup>). Recipients parsing a delta-seconds value <em class="bcp14">SHOULD</em> use an arithmetic type of at least 31 bits of range, and senders <em class="bcp14">MUST NOT</em> send delta-seconds with a value greater than 2147483648.
<p id="rfc.section.2.p.1">Proper cache operation preserves the semantics of HTTP transfers (<a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) while eliminating the transfer of information already held in the cache. Although caching is an entirely <em class="bcp14">OPTIONAL</em> feature of HTTP, we assume that reusing the cached response is desirable and that such reuse is the default behavior when
<p id="rfc.section.2.2.p.4">A cache <em class="bcp14">MUST</em> write through requests with methods that are unsafe (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) to the origin server; i.e., a cache must not generate a reply to such a request before having forwarded the request and
to be used (including the following in <a href="p2-semantics.html#status.codes" title="Status Code Definitions">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>: 200, 203, 206, 300, 301 and 410), a cache <em class="bcp14">MAY</em> calculate a heuristic expiration time. A cache <em class="bcp14">MUST NOT</em> use heuristics to determine freshness for responses with status codes that do not explicitly allow it.
<p id="rfc.section.2.3.1.1.p.3">Also, if the response has a Last-Modified header field (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2.2</a> of <a href="#Part4" id="rfc.xref.Part4.4"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>), a cache <em class="bcp14">SHOULD NOT</em> use a heuristic expiration value that is more than some fraction of the interval since that time. A typical setting of this
fraction might be 10%.
operations. See <a href="p1-messaging.html#header.date" title="Date">Section 9.3</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the definition of the Date header field, and for requirements regarding responses without it.
</pre><p id="rfc.section.2.3.2.p.13">Additional rules for requirements on parsing and encoding of dates and other potential problems with date encodings include:</p>
<p id="rfc.section.2.3.2.p.14"> </p>
<p id="rfc.section.2.3.3.p.3">A cache <em class="bcp14">SHOULD NOT</em> return stale responses unless it is disconnected (i.e., it cannot contact the origin server or otherwise find a forward path)
forward to the requesting client, and the received response is no longer fresh, the cache <em class="bcp14">SHOULD</em> forward it to the requesting client without adding a new Warning (but without removing any existing Warning header fields).
A cache <em class="bcp14">SHOULD NOT</em> attempt to validate a response simply because that response became stale in transit.
<p id="rfc.section.2.4.p.2">When sending such a conditional request, a cache <em class="bcp14">SHOULD</em> add an If-Modified-Since header field whose value is that of the Last-Modified header field from the selected (see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.7</a>) stored response, if available.
<p id="rfc.section.2.4.p.3">Additionally, a cache <em class="bcp14">SHOULD</em> add an If-None-Match header field whose value is that of the ETag header field(s) from all responses stored for the requested
URI, if present. However, if any of the stored responses contains only partial content, the cache <em class="bcp14">SHOULD NOT</em> include its entity-tag in the If-None-Match header field unless the request is for a range that would be fully satisfied by
<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="#freshening.responses" title="Freshening Responses">Section&nbsp;2.9</a>.
request is suitable. Instead, a cache <em class="bcp14">SHOULD</em> use the full response to satisfy the request and <em class="bcp14">MAY</em> replace the stored response(s).
<p id="rfc.section.2.5.p.1">Because unsafe request methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) such as PUT, POST or DELETE have the potential for changing state on the origin server, intervening caches can use them
<p id="rfc.section.2.5.p.2">A cache <em class="bcp14">MUST</em> invalidate the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</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>) as well as the URI(s) in the Location and Content-Location header fields (if present) when a non-error response to a request
in the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). This helps prevent denial of service attacks.
<p id="rfc.section.2.5.p.4">A cache <em class="bcp14">SHOULD</em> invalidate the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) when it receives a non-error response to a request with a method whose safety is unknown.
<li>combining multiple header fields with the same field name (see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>)
<p id="rfc.section.2.7.p.7">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&nbsp;2.4</a>.
<h2 id="rfc.section.2.9"><a href="#rfc.section.2.9">2.9</a>&nbsp;<a id="freshening.responses" href="#freshening.responses">Freshening Responses</a></h2>
<p id="rfc.section.2.9.p.1">When a cache receives a 304 (Not Modified) response and already has one or more stored 200 (OK) responses for the same cache
<p id="rfc.section.2.9.p.2">If a stored response is selected for update, the cache <em class="bcp14">MUST</em>:
<li>A server <em class="bcp14">SHOULD</em> send the must-revalidate directive if and only if failure to validate a request on the representation could result in incorrect
<p id="rfc.section.3.3.p.3">The field-value is an absolute date and time as defined by HTTP-date in <a href="p1-messaging.html#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>; a sender <em class="bcp14">MUST</em> use the rfc1123-date format.
<p id="rfc.section.3.3.p.7">A server <em class="bcp14">SHOULD NOT</em> send Expires dates more than one year in the future.
<p id="rfc.section.3.3.p.8">A cache <em class="bcp14">MUST</em> treat other invalid date formats, especially including the value "0", as in the past (i.e., "already expired").
<p id="rfc.section.3.4.p.5">When sending a no-cache request, a client <em class="bcp14">SHOULD</em> include both pragma and cache-control directives unless Cache-Control: no-cache is purposefully omitted to target other Cache-Control
response directives at HTTP/1.1 caches. For example:
<p id="rfc.section.3.6.p.7">Systems that generate multiple Warning header fields <em class="bcp14">SHOULD</em> order them with this user agent behavior in mind. New Warning header fields <em class="bcp14">SHOULD</em> be added after any existing Warning headers fields.
<li>A cache <em class="bcp14">SHOULD</em> include this whenever the returned response is stale.
<li>A cache <em class="bcp14">SHOULD</em> include this when returning a stale response because an attempt to validate the response failed, due to an inability to reach
<li>A cache <em class="bcp14">SHOULD</em> b include this if it is intentionally disconnected from the rest of the network for a period of time.
<li>A cache <em class="bcp14">SHOULD</em> include this if it heuristically chose a freshness lifetime greater than 24 hours and the response's age is greater than 24
<li><em class="bcp14">MUST</em> be added by a proxy if it applies any transformation to the representation, such as changing the content-coding, media-type,
<p id="rfc.section.7.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 12</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
<td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-latest">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p1-messaging-latest (work in progress), August&nbsp;2011.
<td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-latest">HTTP/1.1, part 2: Message Semantics</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p2-semantics-latest (work in progress), August&nbsp;2011.
<td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-latest">HTTP/1.1, part 4: Conditional Requests</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p4-conditional-latest (work in progress), August&nbsp;2011.
<td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-latest">HTTP/1.1, part 5: Range Requests and Partial Responses</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p5-range-latest (work in progress), August&nbsp;2011.
<td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-latest">HTTP/1.1, part 7: Authentication</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p7-auth-latest (work in progress), August&nbsp;2011.
<p id="rfc.section.A.p.4">Change ABNF productions for header fields to only define the field value. (<a href="#header.fields" title="Header Field Definitions">Section&nbsp;3</a>)
<p id="rfc.section.C.17.p.1">None yet.</p>
<li>Age header field&nbsp;&nbsp;<a href="#rfc.xref.header.age.1">2.2</a>, <a href="#rfc.xref.header.age.2">2.3.2</a>, <a href="#rfc.iref.a.2"><b>3.1</b></a>, <a href="#rfc.xref.header.age.3">5.2</a></li>
<li>Cache-Control header field&nbsp;&nbsp;<a href="#rfc.xref.header.cache-control.1">2.1</a>, <a href="#rfc.xref.header.cache-control.2">2.2</a>, <a href="#rfc.iref.c.6"><b>3.2</b></a>, <a href="#rfc.xref.header.cache-control.3">5.2</a></li>
<li>Expires header field&nbsp;&nbsp;<a href="#rfc.xref.header.expires.1">2.1</a>, <a href="#rfc.xref.header.expires.2">2.3</a>, <a href="#rfc.xref.header.expires.3">2.3.1</a>, <a href="#rfc.iref.e.2"><b>3.3</b></a>, <a href="#rfc.xref.header.expires.4">5.2</a></li>
<li>Age&nbsp;&nbsp;<a href="#rfc.xref.header.age.1">2.2</a>, <a href="#rfc.xref.header.age.2">2.3.2</a>, <a href="#rfc.iref.h.2"><b>3.1</b></a>, <a href="#rfc.xref.header.age.3">5.2</a></li>
<li>Cache-Control&nbsp;&nbsp;<a href="#rfc.xref.header.cache-control.1">2.1</a>, <a href="#rfc.xref.header.cache-control.2">2.2</a>, <a href="#rfc.iref.h.3"><b>3.2</b></a>, <a href="#rfc.xref.header.cache-control.3">5.2</a></li>
<li>Expires&nbsp;&nbsp;<a href="#rfc.xref.header.expires.1">2.1</a>, <a href="#rfc.xref.header.expires.2">2.3</a>, <a href="#rfc.xref.header.expires.3">2.3.1</a>, <a href="#rfc.iref.h.4"><b>3.3</b></a>, <a href="#rfc.xref.header.expires.4">5.2</a></li>
<li>Pragma&nbsp;&nbsp;<a href="#rfc.xref.header.pragma.1">2.2</a>, <a href="#rfc.xref.header.pragma.2">3.2</a>, <a href="#rfc.iref.h.5"><b>3.4</b></a>, <a href="#rfc.xref.header.pragma.3">5.2</a></li>
<li>Vary&nbsp;&nbsp;<a href="#rfc.xref.header.vary.1">2.7</a>, <a href="#rfc.iref.h.6"><b>3.5</b></a>, <a href="#rfc.xref.header.vary.2">5.2</a></li>
<li>Warning&nbsp;&nbsp;<a href="#rfc.xref.header.warning.1">2.3.3</a>, <a href="#rfc.xref.header.warning.2">2.8</a>, <a href="#rfc.xref.header.warning.3">2.9</a>, <a href="#rfc.iref.h.7"><b>3.6</b></a>, <a href="#rfc.xref.header.warning.4">5.2</a>, <a href="#rfc.xref.header.warning.5">A</a></li>
<li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.4</a>, <a href="#rfc.xref.Part1.2">1.4.1</a>, <a href="#rfc.xref.Part1.3">1.4.1</a>, <a href="#rfc.xref.Part1.4">1.4.1</a>, <a href="#rfc.xref.Part1.5">1.4.1</a>, <a href="#rfc.xref.Part1.6">1.4.2</a>, <a href="#rfc.xref.Part1.7">1.4.2</a>, <a href="#rfc.xref.Part1.8">1.4.2</a>, <a href="#rfc.xref.Part1.9">1.4.2</a>, <a href="#rfc.xref.Part1.10">1.4.2</a>, <a href="#rfc.xref.Part1.11">2.1</a>, <a href="#rfc.xref.Part1.12">2.2</a>, <a href="#rfc.xref.Part1.13">2.3.2</a>, <a href="#rfc.xref.Part1.14">2.5</a>, <a href="#rfc.xref.Part1.15">2.5</a>, <a href="#rfc.xref.Part1.16">2.5</a>, <a href="#rfc.xref.Part1.17">2.7</a>, <a href="#rfc.xref.Part1.18">3.3</a>, <a href="#rfc.xref.Part1.19">7</a>, <a href="#Part1"><b>8.1</b></a><ul>
<li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.4</a></li>
<li><em>Section 1.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.3">1.4.1</a></li>
<li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.6">1.4.2</a>, <a href="#rfc.xref.Part1.17">2.7</a></li>
<li><em>Section 3.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.4">1.4.1</a>, <a href="#rfc.xref.Part1.5">1.4.1</a></li>
<li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.12">2.2</a>, <a href="#rfc.xref.Part1.14">2.5</a>, <a href="#rfc.xref.Part1.15">2.5</a>, <a href="#rfc.xref.Part1.16">2.5</a></li>
<li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.7">1.4.2</a>, <a href="#rfc.xref.Part1.18">3.3</a></li>
<li><em>Section 9.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.13">2.3.2</a></li>
<li><em>Section 9.9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.9">1.4.2</a></li>
<li><em>Section 12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.19">7</a></li>
<li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2</a>, <a href="#rfc.xref.Part2.2">2.2</a>, <a href="#rfc.xref.Part2.3">2.3.1.1</a>, <a href="#rfc.xref.Part2.4">2.5</a>, <a href="#Part2"><b>8.1</b></a><ul>
<li><em>Section 7.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">2.2</a>, <a href="#rfc.xref.Part2.4">2.5</a></li>
<li><em>Section 8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.3.1.1</a></li>
<li>Pragma header field&nbsp;&nbsp;<a href="#rfc.xref.header.pragma.1">2.2</a>, <a href="#rfc.xref.header.pragma.2">3.2</a>, <a href="#rfc.iref.p.5"><b>3.4</b></a>, <a href="#rfc.xref.header.pragma.3">5.2</a></li>
<li><em>RFC5226</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">3.2.3</a>, <a href="#RFC5226"><b>8.2</b></a><ul>
<li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">3.2.3</a></li>
<li>Vary header field&nbsp;&nbsp;<a href="#rfc.xref.header.vary.1">2.7</a>, <a href="#rfc.iref.v.3"><b>3.5</b></a>, <a href="#rfc.xref.header.vary.2">5.2</a></li>
<li>Warning header field&nbsp;&nbsp;<a href="#rfc.xref.header.warning.1">2.3.3</a>, <a href="#rfc.xref.header.warning.2">2.8</a>, <a href="#rfc.xref.header.warning.3">2.9</a>, <a href="#rfc.iref.w.1"><b>3.6</b></a>, <a href="#rfc.xref.header.warning.4">5.2</a>, <a href="#rfc.xref.header.warning.5">A</a></li>