Changeset 1375
- Timestamp:
- 04/08/11 05:44:42 (11 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 4 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1373 r1375 572 572 <li>3.2 <a href="#header.fields">Header Fields</a></li> 573 573 <li>3.3 <a href="#message.body">Message Body</a></li> 574 <li>3.4 <a href="#general.header.fields">General Header Fields</a></li> 574 <li>3.4 <a href="#incomplete.messages">Incomplete Messages</a></li> 575 <li>3.5 <a href="#general.header.fields">General Header Fields</a></li> 575 576 </ul> 576 577 </li> … … 1372 1373 knowledge can be in the form of specific user configuration or by remembering the version of a prior received response. 1373 1374 </p> 1374 <p id="rfc.section.3.3.p.15">Request messages that are prematurely terminated, possibly due to a cancelled connection or a server-imposed time-out exception, <em class="bcp14">MUST</em> result in closure of the connection; sending an HTTP/1.1 error response prior to closing the connection is <em class="bcp14">OPTIONAL</em>. Response messages that are prematurely terminated, usually by closure of the connection prior to receiving the expected 1375 number of octets or by failure to decode a transfer-encoded message-body, <em class="bcp14">MUST</em> be recorded as incomplete. A user agent <em class="bcp14">MUST NOT</em> render an incomplete response message-body as if it were complete (i.e., some indication must be given to the user that an 1376 error occurred). Cache requirements for incomplete responses are defined in <a href="p6-cache.html#errors.or.incomplete.response.cache.behavior" title="Storing Partial and Incomplete Responses">Section 2.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. 1377 </p> 1378 <p id="rfc.section.3.3.p.16">A server <em class="bcp14">MUST</em> read the entire request message-body or close the connection after sending its response, since otherwise the remaining data 1375 <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a> <a id="incomplete.messages" href="#incomplete.messages">Incomplete Messages</a></h2> 1376 <p id="rfc.section.3.4.p.1">Request messages that are prematurely terminated, possibly due to a cancelled connection or a server-imposed time-out exception, <em class="bcp14">MUST</em> result in closure of the connection; sending an HTTP/1.1 error response prior to closing the connection is <em class="bcp14">OPTIONAL</em>. 1377 </p> 1378 <p id="rfc.section.3.4.p.2">Response messages that are prematurely terminated, usually by closure of the connection prior to receiving the expected number 1379 of octets or by failure to decode a transfer-encoded message-body, <em class="bcp14">MUST</em> be recorded as incomplete. A response that terminates in the middle of the header block (before the empty line is received) 1380 cannot be assumed to convey the full semantics of the response and <em class="bcp14">MUST NOT</em> be stored by a cache. 1381 </p> 1382 <p id="rfc.section.3.4.p.3">A message-body that uses the chunked transfer encoding is incomplete if the zero-sized chunk that terminates the encoding 1383 has not been received. A message that uses a valid Content-Length is incomplete if the size of the message-body received (in 1384 octets) is less than the value given by Content-Length. A response that has neither chunked transfer encoding nor Content-Length 1385 is terminated by closure of the connection, and thus is considered complete regardless of the number of message-body octets 1386 received, provided that the header block was received intact. 1387 </p> 1388 <p id="rfc.section.3.4.p.4">A user agent <em class="bcp14">MUST NOT</em> render an incomplete response message-body as if it were complete (i.e., some indication must be given to the user that an 1389 error occurred). Cache requirements for incomplete responses are defined in <a href="p6-cache.html#response.cacheability" title="Response Cacheability">Section 2.1</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. 1390 </p> 1391 <p id="rfc.section.3.4.p.5">A server <em class="bcp14">MUST</em> read the entire request message-body or close the connection after sending its response, since otherwise the remaining data 1379 1392 on a persistent connection would be misinterpreted as the next request. Likewise, a client <em class="bcp14">MUST</em> read the entire response message-body if it intends to reuse the same connection for a subsequent request. Pipelining multiple 1380 1393 requests on a connection is described in <a href="#pipelining" title="Pipelining">Section 7.1.2.2</a>. 1381 1394 </p> 1382 <h2 id="rfc.section.3. 4"><a href="#rfc.section.3.4">3.4</a> <a id="general.header.fields" href="#general.header.fields">General Header Fields</a></h2>1383 <p id="rfc.section.3. 4.p.1">There are a few header fields which have general applicability for both request and response messages, but which do not apply1395 <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a> <a id="general.header.fields" href="#general.header.fields">General Header Fields</a></h2> 1396 <p id="rfc.section.3.5.p.1">There are a few header fields which have general applicability for both request and response messages, but which do not apply 1384 1397 to the payload being transferred. These header fields apply only to the message being transmitted. 1385 1398 </p> … … 3664 3677 <li>compress (Coding Format) <a href="#rfc.iref.c.8">6.2.2.1</a></li> 3665 3678 <li>connection <a href="#rfc.iref.c.2"><b>2.1</b></a></li> 3666 <li>Connection header field <a href="#rfc.xref.header.connection.1">2.4</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3. 4</a>, <a href="#rfc.xref.header.connection.4">7.1.2</a>, <a href="#rfc.xref.header.connection.5">7.1.3</a>, <a href="#rfc.xref.header.connection.6">7.1.3.1</a>, <a href="#rfc.iref.c.12"><b>9.1</b></a>, <a href="#rfc.xref.header.connection.7">9.5</a>, <a href="#rfc.xref.header.connection.8">9.8</a>, <a href="#rfc.xref.header.connection.9">10.1</a>, <a href="#rfc.xref.header.connection.10">10.1</a>, <a href="#rfc.xref.header.connection.11">B.1.2</a>, <a href="#rfc.xref.header.connection.12">B.2</a></li>3679 <li>Connection header field <a href="#rfc.xref.header.connection.1">2.4</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.5</a>, <a href="#rfc.xref.header.connection.4">7.1.2</a>, <a href="#rfc.xref.header.connection.5">7.1.3</a>, <a href="#rfc.xref.header.connection.6">7.1.3.1</a>, <a href="#rfc.iref.c.12"><b>9.1</b></a>, <a href="#rfc.xref.header.connection.7">9.5</a>, <a href="#rfc.xref.header.connection.8">9.8</a>, <a href="#rfc.xref.header.connection.9">10.1</a>, <a href="#rfc.xref.header.connection.10">10.1</a>, <a href="#rfc.xref.header.connection.11">B.1.2</a>, <a href="#rfc.xref.header.connection.12">B.2</a></li> 3667 3680 <li>Content-Length header field <a href="#rfc.xref.header.content-length.1">3.3</a>, <a href="#rfc.iref.c.13"><b>9.2</b></a>, <a href="#rfc.xref.header.content-length.2">10.1</a></li> 3668 3681 </ul> 3669 3682 </li> 3670 3683 <li><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul> 3671 <li>Date header field <a href="#rfc.xref.header.date.1">3. 4</a>, <a href="#rfc.iref.d.3"><b>9.3</b></a>, <a href="#rfc.xref.header.date.2">10.1</a></li>3684 <li>Date header field <a href="#rfc.xref.header.date.1">3.5</a>, <a href="#rfc.iref.d.3"><b>9.3</b></a>, <a href="#rfc.xref.header.date.2">10.1</a></li> 3672 3685 <li>deflate (Coding Format) <a href="#rfc.iref.d.2">6.2.2.2</a></li> 3673 3686 <li>downstream <a href="#rfc.iref.d.1"><b>2.4</b></a></li> … … 3797 3810 <li>Header Fields 3798 3811 <ul> 3799 <li>Connection <a href="#rfc.xref.header.connection.1">2.4</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3. 4</a>, <a href="#rfc.xref.header.connection.4">7.1.2</a>, <a href="#rfc.xref.header.connection.5">7.1.3</a>, <a href="#rfc.xref.header.connection.6">7.1.3.1</a>, <a href="#rfc.iref.h.6"><b>9.1</b></a>, <a href="#rfc.xref.header.connection.7">9.5</a>, <a href="#rfc.xref.header.connection.8">9.8</a>, <a href="#rfc.xref.header.connection.9">10.1</a>, <a href="#rfc.xref.header.connection.10">10.1</a>, <a href="#rfc.xref.header.connection.11">B.1.2</a>, <a href="#rfc.xref.header.connection.12">B.2</a></li>3812 <li>Connection <a href="#rfc.xref.header.connection.1">2.4</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.5</a>, <a href="#rfc.xref.header.connection.4">7.1.2</a>, <a href="#rfc.xref.header.connection.5">7.1.3</a>, <a href="#rfc.xref.header.connection.6">7.1.3.1</a>, <a href="#rfc.iref.h.6"><b>9.1</b></a>, <a href="#rfc.xref.header.connection.7">9.5</a>, <a href="#rfc.xref.header.connection.8">9.8</a>, <a href="#rfc.xref.header.connection.9">10.1</a>, <a href="#rfc.xref.header.connection.10">10.1</a>, <a href="#rfc.xref.header.connection.11">B.1.2</a>, <a href="#rfc.xref.header.connection.12">B.2</a></li> 3800 3813 <li>Content-Length <a href="#rfc.xref.header.content-length.1">3.3</a>, <a href="#rfc.iref.h.7"><b>9.2</b></a>, <a href="#rfc.xref.header.content-length.2">10.1</a></li> 3801 <li>Date <a href="#rfc.xref.header.date.1">3. 4</a>, <a href="#rfc.iref.h.8"><b>9.3</b></a>, <a href="#rfc.xref.header.date.2">10.1</a></li>3814 <li>Date <a href="#rfc.xref.header.date.1">3.5</a>, <a href="#rfc.iref.h.8"><b>9.3</b></a>, <a href="#rfc.xref.header.date.2">10.1</a></li> 3802 3815 <li>Host <a href="#rfc.xref.header.host.1">4.3</a>, <a href="#rfc.iref.h.10"><b>9.4</b></a>, <a href="#rfc.xref.header.host.2">10.1</a>, <a href="#rfc.xref.header.host.3">B.1.1</a></li> 3803 3816 <li>TE <a href="#rfc.xref.header.te.1">6.2</a>, <a href="#rfc.xref.header.te.2">6.2.1</a>, <a href="#rfc.xref.header.te.3">6.4</a>, <a href="#rfc.iref.h.11"><b>9.5</b></a>, <a href="#rfc.xref.header.te.4">10.1</a></li> 3804 <li>Trailer <a href="#rfc.xref.header.trailer.1">3. 4</a>, <a href="#rfc.xref.header.trailer.2">6.2.1</a>, <a href="#rfc.iref.h.12"><b>9.6</b></a>, <a href="#rfc.xref.header.trailer.3">10.1</a></li>3805 <li>Transfer-Encoding <a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.xref.header.transfer-encoding.2">3. 4</a>, <a href="#rfc.xref.header.transfer-encoding.3">6.2</a>, <a href="#rfc.iref.h.13"><b>9.7</b></a>, <a href="#rfc.xref.header.transfer-encoding.4">10.1</a></li>3806 <li>Upgrade <a href="#rfc.xref.header.upgrade.1">3. 4</a>, <a href="#rfc.iref.h.14"><b>9.8</b></a>, <a href="#rfc.xref.header.upgrade.2">10.1</a>, <a href="#rfc.xref.header.upgrade.3">B.2</a></li>3807 <li>Via <a href="#rfc.xref.header.via.1">2.4</a>, <a href="#rfc.xref.header.via.2">3. 4</a>, <a href="#rfc.iref.h.15"><b>9.9</b></a>, <a href="#rfc.xref.header.via.3">10.1</a></li>3817 <li>Trailer <a href="#rfc.xref.header.trailer.1">3.5</a>, <a href="#rfc.xref.header.trailer.2">6.2.1</a>, <a href="#rfc.iref.h.12"><b>9.6</b></a>, <a href="#rfc.xref.header.trailer.3">10.1</a></li> 3818 <li>Transfer-Encoding <a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.xref.header.transfer-encoding.2">3.5</a>, <a href="#rfc.xref.header.transfer-encoding.3">6.2</a>, <a href="#rfc.iref.h.13"><b>9.7</b></a>, <a href="#rfc.xref.header.transfer-encoding.4">10.1</a></li> 3819 <li>Upgrade <a href="#rfc.xref.header.upgrade.1">3.5</a>, <a href="#rfc.iref.h.14"><b>9.8</b></a>, <a href="#rfc.xref.header.upgrade.2">10.1</a>, <a href="#rfc.xref.header.upgrade.3">B.2</a></li> 3820 <li>Via <a href="#rfc.xref.header.via.1">2.4</a>, <a href="#rfc.xref.header.via.2">3.5</a>, <a href="#rfc.iref.h.15"><b>9.9</b></a>, <a href="#rfc.xref.header.via.3">10.1</a></li> 3808 3821 </ul> 3809 3822 </li> … … 3869 3882 </ul> 3870 3883 </li> 3871 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">2.4</a>, <a href="#rfc.xref.Part6.2">2.5</a>, <a href="#rfc.xref.Part6.3">2.7.2</a>, <a href="#rfc.xref.Part6.4">3. 3</a>, <a href="#rfc.xref.Part6.5">7.1.3.2</a>, <a href="#rfc.xref.Part6.6">9.1</a>, <a href="#Part6"><b>13.1</b></a><ul>3884 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">2.4</a>, <a href="#rfc.xref.Part6.2">2.5</a>, <a href="#rfc.xref.Part6.3">2.7.2</a>, <a href="#rfc.xref.Part6.4">3.4</a>, <a href="#rfc.xref.Part6.5">7.1.3.2</a>, <a href="#rfc.xref.Part6.6">9.1</a>, <a href="#Part6"><b>13.1</b></a><ul> 3872 3885 <li><em>Section 2</em> <a href="#rfc.xref.Part6.2">2.5</a></li> 3873 <li><em>Section 2.1 .1</em> <a href="#rfc.xref.Part6.4">3.3</a></li>3886 <li><em>Section 2.1</em> <a href="#rfc.xref.Part6.4">3.4</a></li> 3874 3887 <li><em>Section 3.2</em> <a href="#rfc.xref.Part6.3">2.7.2</a>, <a href="#rfc.xref.Part6.6">9.1</a></li> 3875 3888 <li><em>Section 3.6</em> <a href="#rfc.xref.Part6.1">2.4</a>, <a href="#rfc.xref.Part6.5">7.1.3.2</a></li> … … 3964 3977 <li>TE header field <a href="#rfc.xref.header.te.1">6.2</a>, <a href="#rfc.xref.header.te.2">6.2.1</a>, <a href="#rfc.xref.header.te.3">6.4</a>, <a href="#rfc.iref.t.5"><b>9.5</b></a>, <a href="#rfc.xref.header.te.4">10.1</a></li> 3965 3978 <li><em>Tou1998</em> <a href="#rfc.xref.Tou1998.1">7.1.1</a>, <a href="#Tou1998"><b>13.2</b></a></li> 3966 <li>Trailer header field <a href="#rfc.xref.header.trailer.1">3. 4</a>, <a href="#rfc.xref.header.trailer.2">6.2.1</a>, <a href="#rfc.iref.t.6"><b>9.6</b></a>, <a href="#rfc.xref.header.trailer.3">10.1</a></li>3967 <li>Transfer-Encoding header field <a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.xref.header.transfer-encoding.2">3. 4</a>, <a href="#rfc.xref.header.transfer-encoding.3">6.2</a>, <a href="#rfc.iref.t.7"><b>9.7</b></a>, <a href="#rfc.xref.header.transfer-encoding.4">10.1</a></li>3979 <li>Trailer header field <a href="#rfc.xref.header.trailer.1">3.5</a>, <a href="#rfc.xref.header.trailer.2">6.2.1</a>, <a href="#rfc.iref.t.6"><b>9.6</b></a>, <a href="#rfc.xref.header.trailer.3">10.1</a></li> 3980 <li>Transfer-Encoding header field <a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.xref.header.transfer-encoding.2">3.5</a>, <a href="#rfc.xref.header.transfer-encoding.3">6.2</a>, <a href="#rfc.iref.t.7"><b>9.7</b></a>, <a href="#rfc.xref.header.transfer-encoding.4">10.1</a></li> 3968 3981 <li>transforming proxy <a href="#rfc.iref.t.1"><b>2.4</b></a></li> 3969 3982 <li>transparent proxy <a href="#rfc.iref.t.3"><b>2.4</b></a></li> … … 3972 3985 </li> 3973 3986 <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul> 3974 <li>Upgrade header field <a href="#rfc.xref.header.upgrade.1">3. 4</a>, <a href="#rfc.iref.u.5"><b>9.8</b></a>, <a href="#rfc.xref.header.upgrade.2">10.1</a>, <a href="#rfc.xref.header.upgrade.3">B.2</a></li>3987 <li>Upgrade header field <a href="#rfc.xref.header.upgrade.1">3.5</a>, <a href="#rfc.iref.u.5"><b>9.8</b></a>, <a href="#rfc.xref.header.upgrade.2">10.1</a>, <a href="#rfc.xref.header.upgrade.3">B.2</a></li> 3975 3988 <li>upstream <a href="#rfc.iref.u.2"><b>2.4</b></a></li> 3976 3989 <li>URI scheme … … 3985 3998 </li> 3986 3999 <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul> 3987 <li>Via header field <a href="#rfc.xref.header.via.1">2.4</a>, <a href="#rfc.xref.header.via.2">3. 4</a>, <a href="#rfc.iref.v.1"><b>9.9</b></a>, <a href="#rfc.xref.header.via.3">10.1</a></li>4000 <li>Via header field <a href="#rfc.xref.header.via.1">2.4</a>, <a href="#rfc.xref.header.via.2">3.5</a>, <a href="#rfc.iref.v.1"><b>9.9</b></a>, <a href="#rfc.xref.header.via.3">10.1</a></li> 3988 4001 </ul> 3989 4002 </li> -
draft-ietf-httpbis/latest/p2-semantics.html
r1373 r1375 1265 1265 </li> 1266 1266 <li>If the response status code is 204, 206, or 304 and the request method was GET or HEAD, the response payload is a partial 1267 representation of the target resource (see <a href="p6-cache.html#combining.responses" title="Combining Responses">Section 2.8</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).1267 representation of the target resource. 1268 1268 </li> 1269 1269 <li>If the response has a Content-Location header field, and that URI is the same as the effective request URI, the response payload … … 1349 1349 to reject the request. 1350 1350 </p> 1351 <p id="rfc.section.7.3.p.6">The response to a GET request is cacheable and <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests (see <a href="#Part6" id="rfc.xref.Part6. 6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).1351 <p id="rfc.section.7.3.p.6">The response to a GET request is cacheable and <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests (see <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1352 1352 </p> 1353 1353 <p id="rfc.section.7.3.p.7">See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section 11.2</a> for security considerations when used for forms. … … 1360 1360 hypertext links for validity, accessibility, and recent modification. 1361 1361 </p> 1362 <p id="rfc.section.7.4.p.2">The response to a HEAD request is cacheable and <em class="bcp14">MAY</em> be used to satisfy a subsequent HEAD request; see <a href="#Part6" id="rfc.xref.Part6. 7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. It also <em class="bcp14">MAY</em> be used to update a previously cached representation from that resource; if the new field values indicate that the cached1362 <p id="rfc.section.7.4.p.2">The response to a HEAD request is cacheable and <em class="bcp14">MAY</em> be used to satisfy a subsequent HEAD request; see <a href="#Part6" id="rfc.xref.Part6.6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. It also <em class="bcp14">MAY</em> be used to update a previously cached representation from that resource; if the new field values indicate that the cached 1363 1363 representation differs from the current representation (as would be indicated by a change in Content-Length, ETag or Last-Modified), 1364 1364 then the cache <em class="bcp14">MUST</em> treat the cache entry as stale. … … 1389 1389 a Location header field (see <a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section 9.4</a>). 1390 1390 </p> 1391 <p id="rfc.section.7.5.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 2.3.1</a> of <a href="#Part6" id="rfc.xref.Part6. 8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header field (see <a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.1391 <p id="rfc.section.7.5.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 2.3.1</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header field (see <a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests. 1392 1392 </p> 1393 1393 <p id="rfc.section.7.5.p.6">Note that POST caching is not widely implemented. However, the 303 (See Other) response can be used to direct the user agent … … 1454 1454 </p> 1455 1455 <p id="rfc.section.7.6.p.11">Responses to the PUT method are not cacheable. If a PUT request passes through a cache that has one or more stored responses 1456 for the effective request URI, those stored responses will be invalidated (see <a href="p6-cache.html#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section 2.5</a> of <a href="#Part6" id="rfc.xref.Part6. 9"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).1456 for the effective request URI, those stored responses will be invalidated (see <a href="p6-cache.html#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section 2.5</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1457 1457 </p> 1458 1458 <div id="rfc.iref.d.1"></div> … … 1471 1471 </p> 1472 1472 <p id="rfc.section.7.7.p.4">Responses to the DELETE method are not cacheable. If a DELETE request passes through a cache that has one or more stored responses 1473 for the effective request URI, those stored responses will be invalidated (see <a href="p6-cache.html#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section 2.5</a> of <a href="#Part6" id="rfc.xref.Part6. 10"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).1473 for the effective request URI, those stored responses will be invalidated (see <a href="p6-cache.html#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section 2.5</a> of <a href="#Part6" id="rfc.xref.Part6.9"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1474 1474 </p> 1475 1475 <h2 id="rfc.section.7.8"><a href="#rfc.section.7.8">7.8</a> <a id="TRACE" href="#TRACE">TRACE</a></h2> … … 1574 1574 <dd>a representation containing the request message as received by the end server.</dd> 1575 1575 </dl> 1576 <p id="rfc.section.8.2.1.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.1 1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 200 responses.1576 <p id="rfc.section.8.2.1.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.10"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 200 responses. 1577 1577 </p> 1578 1578 <div id="rfc.iref.25"></div> … … 1603 1603 <div id="rfc.iref.s.7"></div> 1604 1604 <h3 id="rfc.section.8.2.4"><a href="#rfc.section.8.2.4">8.2.4</a> <a id="status.203" href="#status.203">203 Non-Authoritative Information</a></h3> 1605 <p id="rfc.section.8.2.4.p.1">The representation in the response has been transformed or otherwise modified by a transforming proxy (<a href="p1-messaging.html#intermediaries" title="Intermediaries">Section 2.4</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Note that the behaviour of transforming intermediaries is controlled by the no-transform Cache-Control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.1 2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).1605 <p id="rfc.section.8.2.4.p.1">The representation in the response has been transformed or otherwise modified by a transforming proxy (<a href="p1-messaging.html#intermediaries" title="Intermediaries">Section 2.4</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Note that the behaviour of transforming intermediaries is controlled by the no-transform Cache-Control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.11"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1606 1606 </p> 1607 1607 <p id="rfc.section.8.2.4.p.2">This status code is only appropriate when the response status code would have been 200 (OK) otherwise. When the status code 1608 before transformation would have been different, the 214 Transformation Applied warn-code (<a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.1 3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) is appropriate.1609 </p> 1610 <p id="rfc.section.8.2.4.p.3">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.1 4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 203 responses.1608 before transformation would have been different, the 214 Transformation Applied warn-code (<a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) is appropriate. 1609 </p> 1610 <p id="rfc.section.8.2.4.p.3">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.13"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 203 responses. 1611 1611 </p> 1612 1612 <div id="rfc.iref.28"></div> … … 1646 1646 defined in <a href="p5-range.html#status.206" title="206 Partial Content">Section 3.1</a> of <a href="#Part5" id="rfc.xref.Part5.8"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. 1647 1647 </p> 1648 <p id="rfc.section.8.2.7.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.1 5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 206 responses.1648 <p id="rfc.section.8.2.7.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.14"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 206 responses. 1649 1649 </p> 1650 1650 <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a> <a id="status.3xx" href="#status.3xx">Redirection 3xx</a></h2> … … 1670 1670 <p id="rfc.section.8.3.1.p.3">If the server has a preferred choice of representation, it <em class="bcp14">SHOULD</em> include the specific URI for that representation in the Location field; user agents <em class="bcp14">MAY</em> use the Location field value for automatic redirection. 1671 1671 </p> 1672 <p id="rfc.section.8.3.1.p.4">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.1 6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 300 responses.1672 <p id="rfc.section.8.3.1.p.4">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.15"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 300 responses. 1673 1673 </p> 1674 1674 <div id="rfc.iref.32"></div> … … 1678 1678 request URI to one or more of the new references returned by the server, where possible. 1679 1679 </p> 1680 <p id="rfc.section.8.3.2.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.1 7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 301 responses.1680 <p id="rfc.section.8.3.2.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.16"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 301 responses. 1681 1681 </p> 1682 1682 <p id="rfc.section.8.3.2.p.3">The new permanent URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the representation of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s). … … 1851 1851 — that is left to the discretion of the server owner. 1852 1852 </p> 1853 <p id="rfc.section.8.4.11.p.3">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.1 8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 410 responses.1853 <p id="rfc.section.8.4.11.p.3">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.17"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 410 responses. 1854 1854 </p> 1855 1855 <div id="rfc.iref.50"></div> … … 3275 3275 </ul> 3276 3276 </li> 3277 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">2.2.1</a>, <a href="#rfc.xref.Part6.2">4.2.1</a>, <a href="#rfc.xref.Part6.3">5</a>, <a href="#rfc.xref.Part6.4">5</a>, <a href="#rfc.xref.Part6.5">6.1</a>, <a href="#rfc.xref.Part6.6">7.3</a>, <a href="#rfc.xref.Part6.7">7.4</a>, <a href="#rfc.xref.Part6.8">7.5</a>, <a href="#rfc.xref.Part6.9">7.6</a>, <a href="#rfc.xref.Part6.10">7.7</a>, <a href="#rfc.xref.Part6.11">8.2.1</a>, <a href="#rfc.xref.Part6.12">8.2.4</a>, <a href="#rfc.xref.Part6.13">8.2.4</a>, <a href="#rfc.xref.Part6.14">8.2.4</a>, <a href="#rfc.xref.Part6.15">8.2.7</a>, <a href="#rfc.xref.Part6.16">8.3.1</a>, <a href="#rfc.xref.Part6.17">8.3.2</a>, <a href="#rfc.xref.Part6.18">8.4.11</a>, <a href="#Part6"><b>13.1</b></a><ul> 3278 <li><em>Section 2.3.1</em> <a href="#rfc.xref.Part6.8">7.5</a></li> 3279 <li><em>Section 2.3.1.1</em> <a href="#rfc.xref.Part6.11">8.2.1</a>, <a href="#rfc.xref.Part6.14">8.2.4</a>, <a href="#rfc.xref.Part6.15">8.2.7</a>, <a href="#rfc.xref.Part6.16">8.3.1</a>, <a href="#rfc.xref.Part6.17">8.3.2</a>, <a href="#rfc.xref.Part6.18">8.4.11</a></li> 3280 <li><em>Section 2.5</em> <a href="#rfc.xref.Part6.9">7.6</a>, <a href="#rfc.xref.Part6.10">7.7</a></li> 3281 <li><em>Section 2.8</em> <a href="#rfc.xref.Part6.5">6.1</a></li> 3277 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">2.2.1</a>, <a href="#rfc.xref.Part6.2">4.2.1</a>, <a href="#rfc.xref.Part6.3">5</a>, <a href="#rfc.xref.Part6.4">5</a>, <a href="#rfc.xref.Part6.5">7.3</a>, <a href="#rfc.xref.Part6.6">7.4</a>, <a href="#rfc.xref.Part6.7">7.5</a>, <a href="#rfc.xref.Part6.8">7.6</a>, <a href="#rfc.xref.Part6.9">7.7</a>, <a href="#rfc.xref.Part6.10">8.2.1</a>, <a href="#rfc.xref.Part6.11">8.2.4</a>, <a href="#rfc.xref.Part6.12">8.2.4</a>, <a href="#rfc.xref.Part6.13">8.2.4</a>, <a href="#rfc.xref.Part6.14">8.2.7</a>, <a href="#rfc.xref.Part6.15">8.3.1</a>, <a href="#rfc.xref.Part6.16">8.3.2</a>, <a href="#rfc.xref.Part6.17">8.4.11</a>, <a href="#Part6"><b>13.1</b></a><ul> 3278 <li><em>Section 2.3.1</em> <a href="#rfc.xref.Part6.7">7.5</a></li> 3279 <li><em>Section 2.3.1.1</em> <a href="#rfc.xref.Part6.10">8.2.1</a>, <a href="#rfc.xref.Part6.13">8.2.4</a>, <a href="#rfc.xref.Part6.14">8.2.7</a>, <a href="#rfc.xref.Part6.15">8.3.1</a>, <a href="#rfc.xref.Part6.16">8.3.2</a>, <a href="#rfc.xref.Part6.17">8.4.11</a></li> 3280 <li><em>Section 2.5</em> <a href="#rfc.xref.Part6.8">7.6</a>, <a href="#rfc.xref.Part6.9">7.7</a></li> 3282 3281 <li><em>Section 3.1</em> <a href="#rfc.xref.Part6.3">5</a></li> 3283 <li><em>Section 3.2</em> <a href="#rfc.xref.Part6.1 2">8.2.4</a></li>3282 <li><em>Section 3.2</em> <a href="#rfc.xref.Part6.11">8.2.4</a></li> 3284 3283 <li><em>Section 3.5</em> <a href="#rfc.xref.Part6.4">5</a></li> 3285 <li><em>Section 3.6</em> <a href="#rfc.xref.Part6.1 3">8.2.4</a></li>3284 <li><em>Section 3.6</em> <a href="#rfc.xref.Part6.12">8.2.4</a></li> 3286 3285 </ul> 3287 3286 </li> -
draft-ietf-httpbis/latest/p5-range.html
r1373 r1375 611 611 </ul> 612 612 <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a id="introduction" href="#introduction">Introduction</a></h1> 613 <p id="rfc.section.1.p.1">HTTP clients often encounter interrupted data transfers as a result of cancelled requests or dropped connections. When a c ache613 <p id="rfc.section.1.p.1">HTTP clients often encounter interrupted data transfers as a result of cancelled requests or dropped connections. When a client 614 614 has stored a partial representation, it is desirable to request the remainder of that representation in a subsequent request 615 615 rather than transfer the entire representation. There are also a number of Web applications that benefit from being able to … … 694 694 <p id="rfc.section.3.1.p.3">If the 206 response is the result of an If-Range request, the response <em class="bcp14">SHOULD NOT</em> include other representation header fields. Otherwise, the response <em class="bcp14">MUST</em> include all of the representation header fields that would have been returned with a 200 (OK) response to the same request. 695 695 </p> 696 <p id="rfc.section.3.1.p.4">A cache <em class="bcp14">MUST NOT</em> combine a 206 response with other previously cached content if the ETag or Last-Modified header fields do not match exactly,697 see <a href="#combining.byte.ranges" title="Combining Ranges">Section 4</a>.698 </p>699 <p id="rfc.section.3.1.p.5">A cache that does not support the Range and Content-Range header fields <em class="bcp14">MUST NOT</em> cache 206 (Partial Content) responses. Furthermore, if a response uses a range unit that is not understood by the cache, then700 it <em class="bcp14">MUST NOT</em> be cached either.701 </p>702 696 <div id="rfc.iref.4"></div> 703 697 <div id="rfc.iref.s.2"></div> … … 710 704 </p> 711 705 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="combining.byte.ranges" href="#combining.byte.ranges">Combining Ranges</a></h1> 712 <p id="rfc.section.4.p.1">A response might transfer only a subrange of a representation, either because the request included one or more Range specifications, 713 or because a connection closed prematurely. After several such transfers, a cache might have received several ranges of the 714 same representation. 715 </p> 716 <p id="rfc.section.4.p.2">If a cache has a stored non-empty set of subranges for a representation, and an incoming response transfers another subrange, 717 the cache <em class="bcp14">MAY</em> combine the new subrange with the existing set if both the following conditions are met: 718 </p> 719 <ul> 720 <li>Both the incoming response and the cache entry have a cache validator.</li> 721 <li>The two cache validators match using the strong comparison function (see <a href="p4-conditional.html#weak.and.strong.validators" title="Weak versus Strong">Section 2.2.2</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). 722 </li> 723 </ul> 724 <p id="rfc.section.4.p.3">If either requirement is not met, the cache <em class="bcp14">MUST</em> use only the most recent partial response (based on the Date values transmitted with every response, and using the incoming 725 response if these values are equal or missing), and <em class="bcp14">MUST</em> discard the other partial information. 706 <p id="rfc.section.4.p.1">A response might transfer only a subrange of a representation if the connection closed prematurely or if the request used 707 one or more Range specifications. After several such transfers, a client might have received several ranges of the same representation. 708 These ranges can only be safely combined if they all have in common the same strong validator, where "strong validator" is 709 defined to be either an entity-tag that is not marked as weak (<a href="p4-conditional.html#header.etag" title="ETag">Section 2.2</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) or, if no entity-tag is provided, a Last-Modified value that is strong in the sense defined by <a href="p4-conditional.html#lastmod.comparison" title="Comparison">Section 2.1.2</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>. 710 </p> 711 <p id="rfc.section.4.p.2">When a client receives an incomplete 200 (OK) or 206 (Partial Content) response and already has one or more stored responses 712 for the same method and effective request URI, all of the stored responses with the same strong validator <em class="bcp14">MAY</em> be combined with the partial content in this new response. If none of the stored responses contain the same strong validator, 713 then this new response corresponds to a new representation and <em class="bcp14">MUST NOT</em> be combined with the existing stored responses. 714 </p> 715 <p id="rfc.section.4.p.3">If the new response is an incomplete 200 (OK) response, then the header fields of that new response are used for any combined 716 response and replace those of the matching stored responses. 717 </p> 718 <p id="rfc.section.4.p.4">If the new response is a 206 (Partial Content) response and at least one of the matching stored responses is a 200 (OK), then 719 the combined response header fields consist of the most recent 200 response's header fields. If all of the matching stored 720 responses are 206 responses, then the stored response with the most header fields is used as the source of header fields for 721 the combined response, except that the client <em class="bcp14">MUST</em> use other header fields provided in the new response, aside from Content-Range, to replace all instances of the corresponding 722 header fields in the stored response. 723 </p> 724 <p id="rfc.section.4.p.5">The combined response message-body consists of the union of partial content ranges in the new response and each of the selected 725 responses. If the union consists of the entire range of the representation, then the combined response <em class="bcp14">MUST</em> be recorded as a complete 200 (OK) response with a Content-Length header field that reflects the complete length. Otherwise, 726 the combined response(s) <em class="bcp14">MUST</em> include a Content-Range header field describing the included range(s) and be recorded as incomplete. If the union consists 727 of a discontinuous range of the representation, then the client <em class="bcp14">MAY</em> store it as either a multipart range response or as multiple 206 responses with one continuous range each. 726 728 </p> 727 729 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> … … 825 827 <div id="rfc.iref.h.3"></div> 826 828 <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a> <a id="header.if-range" href="#header.if-range">If-Range</a></h2> 827 <p id="rfc.section.5.3.p.1">If a client has a partial copy of a representation in its cache, and wishes to have an up-to-date copy of the entire representation828 in its cache, it could use the Range header field with a conditional GET (using either or both of If-Unmodified-Since and829 If-Match.) However, if the condition fails because the representation has been modified, the client would then have to make830 a second request toobtain the entire current representation.829 <p id="rfc.section.5.3.p.1">If a client has a partial copy of a representation and wishes to have an up-to-date copy of the entire representation, it 830 could use the Range header field with a conditional GET (using either or both of If-Unmodified-Since and If-Match.) However, 831 if the condition fails because the representation has been modified, the client would then have to make a second request to 832 obtain the entire current representation. 831 833 </p> 832 834 <p id="rfc.section.5.3.p.2">The "If-Range" header field allows a client to "short-circuit" the second request. Informally, its meaning is "if the representation … … 834 836 </p> 835 837 <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.11"></span> <a href="#header.if-range" class="smpl">If-Range</a> = <a href="#abnf.dependencies" class="smpl">entity-tag</a> / <a href="#abnf.dependencies" class="smpl">HTTP-date</a> 836 </pre><p id="rfc.section.5.3.p.4"> Only a strong validator (<a href="p4-conditional.html#weak.and.strong.validators" title="Weak versus Strong">Section 2.2.2</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) is usable for range retrieval, since otherwise the client might end up with an internally inconsistent representation. Clients <em class="bcp14">MUST NOT</em> use weak validators in range requests. A cache or origin server receiving a conditional range request <em class="bcp14">MUST</em> use the strong comparison function to evaluate the condition.837 </p>838 < p id="rfc.section.5.3.p.5">If the client has no entity-tag for a representation, but does have a Last-Modified date, it <em class="bcp14">MAY</em> use that date in an If-Range header field. (The server can distinguish between a valid HTTP-date and any form of entity-tag839 by examining no more than two characters.) The If-Range header field <em class="bcp14">SHOULD</em> only be used together with a Range header field, and <em class="bcp14">MUST</em> be ignored if the request does not include a Range header field, or if the server does not support the sub-range operation.840 </p>841 < p id="rfc.section.5.3.p.6">If a client wishes to perform a sub-range retrieval on a value for which it has only a Last-Modified time and no opaque validator,842 it <em class="bcp14">MAY</em> do this only if the Last-Modified time is strong in the sense described in <a href="p4-conditional.html#lastmod.comparison" title="Comparison">Section 2.1.2</a> of <a href="#Part4" id="rfc.xref.Part4.4"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.843 </p> 844 <p id="rfc.section.5.3.p.7">If the entity-tag given in the If-Range header field matches the current cache validator for the representation, then the845 server <em class="bcp14">SHOULD</em> provide the specified sub-range of the representation using a 206 (Partial Content) response. If the cache validator does846 not match, then the server <em class="bcp14">SHOULD</em> returnthe entire representation using a 200 (OK) response.838 </pre><p id="rfc.section.5.3.p.4">Clients <em class="bcp14">MUST NOT</em> use an entity-tag marked as weak in an If-Range field value and <em class="bcp14">MUST NOT</em> use a Last-Modified date in an If-Range field value unless it has no entity-tag for the representation and the Last-Modified 839 date it does have for the representation is strong in the sense defined by <a href="p4-conditional.html#lastmod.comparison" title="Comparison">Section 2.1.2</a> of <a href="#Part4" id="rfc.xref.Part4.4"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>. 840 </p> 841 <p id="rfc.section.5.3.p.5">A server that evaluates a conditional range request that is applicable to one of its representations <em class="bcp14">MUST</em> evaluate the condition as false if the entity-tag used as a validator is marked as weak or, when an HTTP-date is used as the 842 validator, if the date value is not strong in the sense defined by <a href="p4-conditional.html#lastmod.comparison" title="Comparison">Section 2.1.2</a> of <a href="#Part4" id="rfc.xref.Part4.5"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>. (A server can distinguish between a valid HTTP-date and any form of entity-tag by examining the first two characters.) 843 </p> 844 <p id="rfc.section.5.3.p.6">The If-Range header field <em class="bcp14">SHOULD</em> only be sent by clients together with a Range header field. The If-Range header field <em class="bcp14">MUST</em> be ignored if it is received in a request that does not include a Range header field. The If-Range header field <em class="bcp14">MUST</em> be ignored by a server that does not support the sub-range operation. 845 </p> 846 <p id="rfc.section.5.3.p.7">If the validator given in the If-Range header field matches the current validator for the selected representation of the target 847 resource, then the server <em class="bcp14">SHOULD</em> send the specified sub-range of the representation using a 206 (Partial Content) response. If the validator does not match, 848 then the server <em class="bcp14">SHOULD</em> send the entire representation using a 200 (OK) response. 847 849 </p> 848 850 <div id="rfc.iref.r.1"></div> … … 913 915 <a href="#range.retrieval.requests" class="smpl">other-ranges-specifier</a> = <a href="#range.units" class="smpl">other-range-unit</a> "=" <a href="#range.retrieval.requests" class="smpl">other-range-set</a> 914 916 <a href="#range.retrieval.requests" class="smpl">other-range-set</a> = 1*<a href="#notation" class="smpl">CHAR</a> 915 </pre><p id="rfc.section.5.4.2.p.3">A server <em class="bcp14">MAY</em> ignore the Range header field. However, HTTP/1.1 origin servers and intermediate caches ought to support byte ranges when916 possible, since Range supports efficient recovery from partially failed transfers, and supports efficient partial retrieval917 of largerepresentations.917 </pre><p id="rfc.section.5.4.2.p.3">A server <em class="bcp14">MAY</em> ignore the Range header field. However, origin servers and intermediate caches ought to support byte ranges when possible, 918 since Range supports efficient recovery from partially failed transfers, and supports efficient partial retrieval of large 919 representations. 918 920 </p> 919 921 <p id="rfc.section.5.4.2.p.4">If the server supports the Range header field and the specified range or ranges are appropriate for the representation: </p> … … 1217 1219 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="compatibility" href="#compatibility">Compatibility with Previous Versions</a></h1> 1218 1220 <h2 id="rfc.section.B.1"><a href="#rfc.section.B.1">B.1</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2> 1219 <p id="rfc.section.B.1.p.1">Clarify that it is not ok to use a weak cachevalidator in a 206 response. (<a href="#status.206" id="rfc.xref.status.206.2" title="206 Partial Content">Section 3.1</a>)1221 <p id="rfc.section.B.1.p.1">Clarify that it is not ok to use a weak validator in a 206 response. (<a href="#status.206" id="rfc.xref.status.206.2" title="206 Partial Content">Section 3.1</a>) 1220 1222 </p> 1221 1223 <p id="rfc.section.B.1.p.2">Change ABNF productions for header fields to only define the field value. (<a href="#header.fields" title="Header Field Definitions">Section 5</a>) … … 1486 1488 </ul> 1487 1489 </li> 1488 <li><em>Part4</em> <a href="#rfc.xref.Part4.1">1.2.2</a>, <a href="#rfc.xref.Part4.2">4</a>, <a href="#rfc.xref.Part4.3">5.3</a>, <a href="#rfc.xref.Part4.4">5.3</a>, <a href="#Part4"><b>9.1</b></a><ul> 1489 <li><em>Section 2.1.2</em> <a href="#rfc.xref.Part4.4">5.3</a></li> 1490 <li><em>Section 2.2</em> <a href="#rfc.xref.Part4.1">1.2.2</a></li> 1491 <li><em>Section 2.2.2</em> <a href="#rfc.xref.Part4.2">4</a>, <a href="#rfc.xref.Part4.3">5.3</a></li> 1490 <li><em>Part4</em> <a href="#rfc.xref.Part4.1">1.2.2</a>, <a href="#rfc.xref.Part4.2">4</a>, <a href="#rfc.xref.Part4.3">4</a>, <a href="#rfc.xref.Part4.4">5.3</a>, <a href="#rfc.xref.Part4.5">5.3</a>, <a href="#Part4"><b>9.1</b></a><ul> 1491 <li><em>Section 2.1.2</em> <a href="#rfc.xref.Part4.3">4</a>, <a href="#rfc.xref.Part4.4">5.3</a>, <a href="#rfc.xref.Part4.5">5.3</a></li> 1492 <li><em>Section 2.2</em> <a href="#rfc.xref.Part4.1">1.2.2</a>, <a href="#rfc.xref.Part4.2">4</a></li> 1492 1493 </ul> 1493 1494 </li> -
draft-ietf-httpbis/latest/p6-cache.html
r1373 r1375 556 556 </li> 557 557 <li>2. <a href="#caching.overview">Cache Operation</a><ul> 558 <li>2.1 <a href="#response.cacheability">Response Cacheability</a><ul> 559 <li>2.1.1 <a href="#errors.or.incomplete.response.cache.behavior">Storing Partial and Incomplete Responses</a></li> 560 </ul> 561 </li> 558 <li>2.1 <a href="#response.cacheability">Response Cacheability</a></li> 562 559 <li>2.2 <a href="#constructing.responses.from.caches">Constructing Responses from Caches</a></li> 563 560 <li>2.3 <a href="#expiration.model">Freshness Model</a><ul> … … 574 571 <li>2.6 <a href="#caching.authenticated.responses">Shared Caching of Authenticated Responses</a></li> 575 572 <li>2.7 <a href="#caching.negotiated.responses">Caching Negotiated Responses</a></li> 576 <li>2.8 <a href="#combining.responses">Combining Responses</a></li> 573 <li>2.8 <a href="#combining.responses">Combining Partial Content</a></li> 574 <li>2.9 <a href="#freshening.responses">Freshening Responses</a></li> 577 575 </ul> 578 576 </li> … … 639 637 Any client or server <em class="bcp14">MAY</em> employ a cache, though a cache cannot be used by a server that is acting as a tunnel. 640 638 </p> 641 <p id="rfc.section.1.1.p.2"> Caching would be useless if it did not significantly improve performance. The goal of caching in HTTP/1.1 is to reuse a prior642 re sponse message to satisfy a current request. In some cases, a stored response can be reused without the need for a network643 request, reducing latency and network round-trips; a "freshness" mechanism is used for this purpose (see <a href="#expiration.model" title="Freshness Model">Section 2.3</a>). Even when a new request is required, it is often possible to reuse all or parts of the payload of a prior response to satisfy644 the request, thereby reducing network bandwidth usage; a "validation" mechanism is used for this purpose (see <a href="#validation.model" title="Validation Model">Section 2.4</a>).639 <p id="rfc.section.1.1.p.2">The goal of caching in HTTP/1.1 is to significantly improve performance by reusing a prior response message to satisfy a current 640 request. A stored response is considered "fresh", as defined in <a href="#expiration.model" title="Freshness Model">Section 2.3</a>, if the response can be reused without "validation" (checking with the origin server to see if the cached response remains 641 valid for this request). A fresh cache response can therefore reduce both latency and network transfers each time it is reused. 642 When a cached response is not fresh, it might still be reusable if it can be freshened by validation (<a href="#validation.model" title="Validation Model">Section 2.4</a>) or if the origin is unavailable. 645 643 </p> 646 644 <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="intro.terminology" href="#intro.terminology">Terminology</a></h2> … … 657 655 </p> 658 656 <ul class="empty"> 659 <li>A cache that is accessible tomore than one user; usually (but not always) deployed as part of an intermediary.</li>657 <li>A cache that stores responses to be reused by more than one user; usually (but not always) deployed as part of an intermediary.</li> 660 658 </ul> 661 659 </div> … … 712 710 <ul class="empty"> 713 711 <li>A protocol element (e.g., an entity-tag or a Last-Modified time) that is used to find out whether a stored response is an 714 equivalent copy of a representation. 712 equivalent copy of a representation. See <a href="p4-conditional.html#weak.and.strong.validators" title="Weak versus Strong">Section 2.2.2</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>. 713 </li> 714 </ul> 715 <p id="rfc.section.1.2.p.14"> <span id="rfc.iref.s.3"></span> <span id="rfc.iref.v.2"></span> <dfn>strong validator</dfn> 716 </p> 717 <ul class="empty"> 718 <li>A validator that is defined by the origin server such that its current value will change if the representation body changes; 719 i.e., an entity-tag that is not marked as weak (<a href="p4-conditional.html#header.etag" title="ETag">Section 2.2</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) or, if no entity-tag is provided, a Last-Modified value that is strong in the sense defined by <a href="p4-conditional.html#lastmod.comparison" title="Comparison">Section 2.1.2</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>. 715 720 </li> 716 721 </ul> … … 750 755 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. 751 756 </p> 757 <div id="rfc.iref.c.4"></div> 758 <div id="rfc.iref.c.5"></div> 752 759 <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="caching.overview" href="#caching.overview">Cache Operation</a></h1> 760 <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 761 no requirement or locally-desired configuration prevents it. Therefore, HTTP cache requirements are focused on preventing 762 a cache from either storing a non-reusable response or reusing a stored response inappropriately. 763 </p> 764 <p id="rfc.section.2.p.2">Each <dfn>cache entry</dfn> consists of a cache key and one or more HTTP responses corresponding to prior requests that used the same key. The most common 765 form of cache entry is a successful result of a retrieval request: i.e., a 200 (OK) response containing a representation of 766 the resource identified by the request target. However, it is also possible to cache negative results (e.g., 404 not found), 767 incomplete results (e.g., 206 partial content), and responses to safe methods other than GET if the method's definition allows 768 such caching and defines something suitable for use as a cache key. 769 </p> 770 <p id="rfc.section.2.p.3">The default <dfn>cache key</dfn> consists of the request method and target URI. However, since HTTP caches in common use today are typically limited to caching 771 responses to GET, most implementations simply decline other methods and use only the URI as the key. 772 </p> 773 <p id="rfc.section.2.p.4">If a request target is subject to content negotiation, its cache entry might consist of multiple stored responses, each differentiated 774 by a secondary key for the values of the original request's selecting header fields (<a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2.7</a>). 775 </p> 753 776 <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> <a id="response.cacheability" href="#response.cacheability">Response Cacheability</a></h2> 754 777 <p id="rfc.section.2.1.p.1">A cache <em class="bcp14">MUST NOT</em> store a response to any request, unless: … … 779 802 <p id="rfc.section.2.1.p.2">Note that any of the requirements listed above can be overridden by a cache-control extension; see <a href="#cache.control.extensions" title="Cache Control Extensions">Section 3.2.3</a>. 780 803 </p> 781 <p id="rfc.section.2.1.p.3">In this context, a cache has "understood" a request method or a response status code if it recognises it and implements any 782 cache-specific behavior. In particular, 206 Partial Content responses cannot be cached by an implementation that does not 783 handle partial content (see <a href="#errors.or.incomplete.response.cache.behavior" title="Storing Partial and Incomplete Responses">Section 2.1.1</a>). 784 </p> 785 <p id="rfc.section.2.1.p.4">Note that in normal operation, most caches will not store a response that has neither a cache validator nor an explicit expiration 804 <p id="rfc.section.2.1.p.3">In this context, a cache has "understood" a request method or a response status code if it recognizes it and implements any 805 cache-specific behavior. 806 </p> 807 <p id="rfc.section.2.1.p.4">Note that, in normal operation, most caches will not store a response that has neither a cache validator nor an explicit expiration 786 808 time, as such responses are not usually useful to store. However, caches are not prohibited from storing such responses. 787 809 </p> 788 <h3 id="rfc.section.2.1.1"><a href="#rfc.section.2.1.1">2.1.1</a> <a id="errors.or.incomplete.response.cache.behavior" href="#errors.or.incomplete.response.cache.behavior">Storing Partial and Incomplete Responses</a></h3> 789 <p id="rfc.section.2.1.1.p.1">A cache that receives an incomplete response (for example, with fewer bytes of data than specified in a Content-Length header 790 field) can store the response, but <em class="bcp14">MUST</em> treat it 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 can 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. 791 </p> 792 <p id="rfc.section.2.1.1.p.2">A cache that does not support the Range and Content-Range header fields <em class="bcp14">MUST NOT</em> store incomplete or partial responses. 810 <p id="rfc.section.2.1.p.5">A response message is considered complete when all of the octets indicated by the message framing (<a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) are received prior to the connection being closed. If the request is GET, the response status is 200 (OK), and the entire 811 response header block has been received, a cache <em class="bcp14">MAY</em> store an incomplete response message-body if the cache entry is recorded as incomplete. Likewise, a 206 (Partial Content) 812 response <em class="bcp14">MAY</em> be stored as if it were an incomplete 200 (OK) cache entry. However, a cache <em class="bcp14">MUST NOT</em> store incomplete or partial content responses if it does not support the Range and Content-Range header fields or if it does 813 not understand the range units used in those fields. 814 </p> 815 <p id="rfc.section.2.1.p.6">A cache <em class="bcp14">MAY</em> complete a stored incomplete response by making a subsequent range request (<a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) and combining the successful response with the stored entry, as defined in <a href="#combining.responses" title="Combining Partial Content">Section 2.8</a>. A cache <em class="bcp14">MUST NOT</em> use an incomplete response to answer requests unless the response has been made complete or the request is partial and specifies 816 a range that is wholly within the incomplete response. A cache <em class="bcp14">MUST NOT</em> send a partial response to a client without explicitly marking it as such using the 206 (Partial Content) status code. 793 817 </p> 794 818 <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> <a id="constructing.responses.from.caches" href="#constructing.responses.from.caches">Constructing Responses from Caches</a></h2> … … 796 820 </p> 797 821 <ul> 798 <li>The presented 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.1 1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and that of the stored response match, and822 <li>The presented 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.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and that of the stored response match, and 799 823 </li> 800 824 <li>the request method associated with the stored response allows it to be used for the presented request, and</li> … … 818 842 <p id="rfc.section.2.2.p.3">When a stored response is used to satisfy a request without validation, a cache <em class="bcp14">MUST</em> include a single Age header field (<a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section 3.1</a>) in the response with a value equal to the stored response's current_age; see <a href="#age.calculations" title="Calculating Age">Section 2.3.2</a>. 819 843 </p> 820 <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. 1"><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 and844 <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 821 845 having received a corresponding response. 822 846 </p> … … 869 893 <h4 id="rfc.section.2.3.1.1"><a href="#rfc.section.2.3.1.1">2.3.1.1</a> <a id="heuristic.freshness" href="#heuristic.freshness">Calculating Heuristic Freshness</a></h4> 870 894 <p id="rfc.section.2.3.1.1.p.1">If no explicit expiration time is present in a stored response that has a status code whose definition allows heuristic freshness 871 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. 2"><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.895 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. 872 896 </p> 873 897 <p id="rfc.section.2.3.1.1.p.2">When a heuristic is used to calculate freshness lifetime, a cache <em class="bcp14">SHOULD</em> attach a Warning header field with a 113 warn-code to the response if its current_age is more than 24 hours and such a warning 874 898 is not already present. 875 899 </p> 876 <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.1</a> of <a href="#Part4" id="rfc.xref.Part4. 1"><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 this900 <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.1</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 877 901 fraction might be 10%. 878 902 </p> … … 901 925 <li>HTTP/1.1 requires origin servers to send a Date header field, if possible, with every response, giving the time at which the 902 926 response was generated. The term "date_value" denotes the value of the Date header field, in a form appropriate for arithmetic 903 operations. See <a href="p1-messaging.html#header.date" title="Date">Section 9.3</a> of <a href="#Part1" id="rfc.xref.Part1.1 2"><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.927 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. 904 928 </li> 905 929 </ul> … … 958 982 <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> 959 983 <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 960 fresh, or one cannot be selected; see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2.7</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 to984 fresh, or one cannot be selected; see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2.7</a>), it can use the conditional request mechanism <a href="#Part4" id="rfc.xref.Part4.5"><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 961 985 update it. This process is known as "validating" or "revalidating" the stored response. 962 986 </p> … … 967 991 that stored response. 968 992 </p> 969 <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.responses" title="Combining Responses">Section 2.8</a>.993 <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 2.9</a>. 970 994 </p> 971 995 <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 972 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 .996 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). 973 997 </p> 974 998 <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>). 975 999 </p> 976 1000 <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> 977 <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. 3"><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 them1001 <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 978 1002 to keep their contents up-to-date. 979 1003 </p> 980 <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.1 3"><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 request1004 <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 981 1005 with an unsafe method is received. 982 1006 </p> 983 1007 <p id="rfc.section.2.5.p.3">However, a cache <em class="bcp14">MUST NOT</em> invalidate a URI from a Location or Content-Location header field if the host part of that URI differs from the host part 984 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.1 4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). This helps prevent denial of service attacks.985 </p> 986 <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.1 5"><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.1008 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. 1009 </p> 1010 <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. 987 1011 </p> 988 1012 <p id="rfc.section.2.5.p.5">Here, a "non-error response" is one with a 2xx or 3xx status code. "Invalidate" means that the cache will either remove all … … 1011 1035 <ul> 1012 1036 <li>adding or removing whitespace, where allowed in the header field's syntax</li> 1013 <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.1 6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>)1037 <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>) 1014 1038 </li> 1015 1039 <li>normalizing both header field values in a way that is known to have identical semantics, according to the header field's specification … … 1028 1052 <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 2.4</a>. 1029 1053 </p> 1030 <h2 id="rfc.section.2.8"><a href="#rfc.section.2.8">2.8</a> <a id="combining.responses" href="#combining.responses">Combining Responses</a></h2> 1031 <p id="rfc.section.2.8.p.1">When a cache receives a 304 (Not Modified) response or a 206 (Partial Content) response (in this section, the "new" response"), 1032 it needs to create an updated response by combining the stored response with the new one, so that the updated response can 1033 be used to satisfy the request, and potentially update the cached response. 1034 </p> 1035 <p id="rfc.section.2.8.p.2">If the new response contains an ETag, it identifies the stored response to use. <span class="comment" id="TODO-mention-CL">[<a href="#TODO-mention-CL" class="smpl">TODO-mention-CL</a>: might need language about Content-Location here]</span><span class="comment" id="TODO-select-for-combine">[<a href="#TODO-select-for-combine" class="smpl">TODO-select-for-combine</a>: Shouldn't this be the selected response?]</span> 1036 </p> 1037 <p id="rfc.section.2.8.p.3">When the new response's status code is 206 (partial content), a cache <em class="bcp14">MUST NOT</em> combine it with the old response if either response does not have a validator, and <em class="bcp14">MUST NOT</em> combine it with the old response when those validators do not match with the strong comparison function (see <a href="p4-conditional.html#weak.and.strong.validators" title="Weak versus Strong">Section 2.2.2</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). 1038 </p> 1039 <p id="rfc.section.2.8.p.4">The stored response header fields are used as those of the updated response, except that </p> 1040 <ul> 1041 <li>a cache <em class="bcp14">MUST</em> delete any stored Warning header fields with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section 3.6</a>). 1042 </li> 1043 <li>a cache <em class="bcp14">MUST</em> retain any stored Warning header fields with warn-code 2xx. 1044 </li> 1045 <li>a cache <em class="bcp14">MUST</em> use other header fields provided in the new response to replace all instances of the corresponding header fields from the 1046 stored response. 1047 </li> 1048 </ul> 1049 <p id="rfc.section.2.8.p.5">A cache <em class="bcp14">MUST</em> use the updated response header fields to replace those of the stored response (unless the stored response is removed). In 1050 the case of a 206 response, a cache <em class="bcp14">MAY</em> store the combined representation. 1051 </p> 1054 <h2 id="rfc.section.2.8"><a href="#rfc.section.2.8">2.8</a> <a id="combining.responses" href="#combining.responses">Combining Partial Content</a></h2> 1055 <p id="rfc.section.2.8.p.1">A response might transfer only a partial representation if the connection closed prematurely or if the request used one or 1056 more Range specifiers (<a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>). After several such transfers, a cache might have received several ranges of the same representation. A cache <em class="bcp14">MAY</em> combine these ranges into a single stored response, and reuse that response to satisfy later requests, if they all share the 1057 same strong validator and the cache complies with the client requirements in <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>. 1058 </p> 1059 <p id="rfc.section.2.8.p.2">When combining the new response with one or more stored responses, a cache <em class="bcp14">MUST</em>: 1060 </p> 1061 <ul> 1062 <li>delete any Warning header fields in the stored response with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section 3.6</a>); 1063 </li> 1064 <li>retain any Warning header fields in the stored response with warn-code 2xx; and,</li> 1065 <li>use other header fields provided in the new response, aside from Content-Range, to replace all instances of the corresponding 1066 header fields in the stored response. 1067 </li> 1068 </ul> 1069 <h2 id="rfc.section.2.9"><a href="#rfc.section.2.9">2.9</a> <a id="freshening.responses" href="#freshening.responses">Freshening Responses</a></h2> 1070 <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 1071 key, the cache needs to identify which of the stored responses are updated by this new response and then update the stored 1072 response(s) with the new information provided in the 304 response. 1073 </p> 1074 <ul> 1075 <li>If the new response contains a strong validator, then that strong validator identifies the selected representation. All of 1076 the stored responses with the same strong validator are selected. If none of the stored responses contain the same strong 1077 validator, then this new response corresponds to a new selected representation and <em class="bcp14">MUST NOT</em> update the existing stored responses. 1078 </li> 1079 <li>If the new response contains a weak validator and that validator corresponds to one of the cache's stored responses, then 1080 the most recent of those matching stored responses is selected. 1081 </li> 1082 <li>If the new response does not include any form of validator, there is only one stored response, and that stored response also 1083 lacks a validator, then that stored response is selected. 1084 </li> 1085 </ul> 1086 <p id="rfc.section.2.9.p.2">If a stored response is selected for update, the cache <em class="bcp14">MUST</em>: 1087 </p> 1088 <ul> 1089 <li>delete any Warning header fields in the stored response with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.3" title="Warning">Section 3.6</a>); 1090 </li> 1091 <li>retain any Warning header fields in the stored response with warn-code 2xx; and,</li> 1092 <li>use other header fields provided in the 304 response to replace all instances of the corresponding header fields in the stored 1093 response. 1094 </li> 1095 </ul> 1052 1096 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> 1053 1097 <p id="rfc.section.3.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to caching.</p> … … 1064 1108 true, since HTTP/1.0 caches might not implement the Age header field. 1065 1109 </p> 1066 <div id="rfc.iref.c. 4"></div>1110 <div id="rfc.iref.c.6"></div> 1067 1111 <div id="rfc.iref.h.3"></div> 1068 1112 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="header.cache-control" href="#header.cache-control">Cache-Control</a></h2> … … 1097 1141 / "only-if-cached" 1098 1142 / <a href="#header.cache-control" class="smpl">cache-extension</a> 1099 </pre><p id="rfc.section.3.2.1.p.2"> <dfn>no-cache</dfn> <span id="rfc.iref.c. 5"></span> <span id="rfc.iref.n.1"></span>1143 </pre><p id="rfc.section.3.2.1.p.2"> <dfn>no-cache</dfn> <span id="rfc.iref.c.7"></span> <span id="rfc.iref.n.1"></span> 1100 1144 </p> 1101 1145 <ul class="empty"> … … 1103 1147 </li> 1104 1148 </ul> 1105 <p id="rfc.section.3.2.1.p.3"> <dfn>no-store</dfn> <span id="rfc.iref.c. 6"></span> <span id="rfc.iref.n.2"></span>1149 <p id="rfc.section.3.2.1.p.3"> <dfn>no-store</dfn> <span id="rfc.iref.c.8"></span> <span id="rfc.iref.n.2"></span> 1106 1150 </p> 1107 1151 <ul class="empty"> … … 1115 1159 </li> 1116 1160 </ul> 1117 <p id="rfc.section.3.2.1.p.4"> <dfn>max-age</dfn> <span id="rfc.iref.c. 7"></span> <span id="rfc.iref.m.1"></span>1161 <p id="rfc.section.3.2.1.p.4"> <dfn>max-age</dfn> <span id="rfc.iref.c.9"></span> <span id="rfc.iref.m.1"></span> 1118 1162 </p> 1119 1163 <ul class="empty"> … … 1122 1166 </li> 1123 1167 </ul> 1124 <p id="rfc.section.3.2.1.p.5"> <dfn>max-stale</dfn> <span id="rfc.iref.c. 8"></span> <span id="rfc.iref.m.2"></span>1168 <p id="rfc.section.3.2.1.p.5"> <dfn>max-stale</dfn> <span id="rfc.iref.c.10"></span> <span id="rfc.iref.m.2"></span> 1125 1169 </p> 1126 1170 <ul class="empty"> … … 1131 1175 </li> 1132 1176 </ul> 1133 <p id="rfc.section.3.2.1.p.6"> <dfn>min-fresh</dfn> <span id="rfc.iref.c. 9"></span> <span id="rfc.iref.m.3"></span>1177 <p id="rfc.section.3.2.1.p.6"> <dfn>min-fresh</dfn> <span id="rfc.iref.c.11"></span> <span id="rfc.iref.m.3"></span> 1134 1178 </p> 1135 1179 <ul class="empty"> … … 1139 1183 </li> 1140 1184 </ul> 1141 <p id="rfc.section.3.2.1.p.7"> <dfn>no-transform</dfn> <span id="rfc.iref.c.1 0"></span> <span id="rfc.iref.n.3"></span>1185 <p id="rfc.section.3.2.1.p.7"> <dfn>no-transform</dfn> <span id="rfc.iref.c.12"></span> <span id="rfc.iref.n.3"></span> 1142 1186 </p> 1143 1187 <ul class="empty"> … … 1145 1189 </li> 1146 1190 </ul> 1147 <p id="rfc.section.3.2.1.p.8"> <dfn>only-if-cached</dfn> <span id="rfc.iref.c.1 1"></span> <span id="rfc.iref.o.1"></span>1191 <p id="rfc.section.3.2.1.p.8"> <dfn>only-if-cached</dfn> <span id="rfc.iref.c.13"></span> <span id="rfc.iref.o.1"></span> 1148 1192 </p> 1149 1193 <ul class="empty"> … … 1166 1210 / "s-maxage" "=" <a href="#delta-seconds" class="smpl">delta-seconds</a> 1167 1211 / <a href="#header.cache-control" class="smpl">cache-extension</a> 1168 </pre><p id="rfc.section.3.2.2.p.2"> <dfn>public</dfn> <span id="rfc.iref.c.1 2"></span> <span id="rfc.iref.p.2"></span>1212 </pre><p id="rfc.section.3.2.2.p.2"> <dfn>public</dfn> <span id="rfc.iref.c.14"></span> <span id="rfc.iref.p.2"></span> 1169 1213 </p> 1170 1214 <ul class="empty"> … … 1172 1216 </li> 1173 1217 </ul> 1174 <p id="rfc.section.3.2.2.p.3"> <dfn>private</dfn> <span id="rfc.iref.c.1 3"></span> <span id="rfc.iref.p.3"></span>1218 <p id="rfc.section.3.2.2.p.3"> <dfn>private</dfn> <span id="rfc.iref.c.15"></span> <span id="rfc.iref.p.3"></span> 1175 1219 </p> 1176 1220 <ul class="empty"> … … 1185 1229 </li> 1186 1230 </ul> 1187 <p id="rfc.section.3.2.2.p.4"> <dfn>no-cache</dfn> <span id="rfc.iref.c.1 4"></span> <span id="rfc.iref.n.4"></span>1231 <p id="rfc.section.3.2.2.p.4"> <dfn>no-cache</dfn> <span id="rfc.iref.c.16"></span> <span id="rfc.iref.n.4"></span> 1188 1232 </p> 1189 1233 <ul class="empty"> … … 1202 1246 </li> 1203 1247 </ul> 1204 <p id="rfc.section.3.2.2.p.5"> <dfn>no-store</dfn> <span id="rfc.iref.c.1 5"></span> <span id="rfc.iref.n.5"></span>1248 <p id="rfc.section.3.2.2.p.5"> <dfn>no-store</dfn> <span id="rfc.iref.c.17"></span> <span id="rfc.iref.n.5"></span> 1205 1249 </p> 1206 1250 <ul class="empty"> … … 1211 1255 </li> 1212 1256 </ul> 1213 <p id="rfc.section.3.2.2.p.6"> <dfn>must-revalidate</dfn> <span id="rfc.iref.c.1 6"></span> <span id="rfc.iref.m.4"></span>1257 <p id="rfc.section.3.2.2.p.6"> <dfn>must-revalidate</dfn> <span id="rfc.iref.c.18"></span> <span id="rfc.iref.m.4"></span> 1214 1258 </p> 1215 1259 <ul class="empty"> … … 1223 1267 </li> 1224 1268 </ul> 1225 <p id="rfc.section.3.2.2.p.7"> <dfn>proxy-revalidate</dfn> <span id="rfc.iref.c.1 7"></span> <span id="rfc.iref.p.4"></span>1269 <p id="rfc.section.3.2.2.p.7"> <dfn>proxy-revalidate</dfn> <span id="rfc.iref.c.19"></span> <span id="rfc.iref.p.4"></span> 1226 1270 </p> 1227 1271 <ul class="empty"> … … 1230 1274 </li> 1231 1275 </ul> 1232 <p id="rfc.section.3.2.2.p.8"> <dfn>max-age</dfn> <span id="rfc.iref.c. 18"></span> <span id="rfc.iref.m.5"></span>1276 <p id="rfc.section.3.2.2.p.8"> <dfn>max-age</dfn> <span id="rfc.iref.c.20"></span> <span id="rfc.iref.m.5"></span> 1233 1277 </p> 1234 1278 <ul class="empty"> … … 1237 1281 </li> 1238 1282 </ul> 1239 <p id="rfc.section.3.2.2.p.9"> <dfn>s-maxage</dfn> <span id="rfc.iref.c. 19"></span> <span id="rfc.iref.s.3"></span>1283 <p id="rfc.section.3.2.2.p.9"> <dfn>s-maxage</dfn> <span id="rfc.iref.c.21"></span> <span id="rfc.iref.s.4"></span> 1240 1284 </p> 1241 1285 <ul class="empty"> … … 1245 1289 </li> 1246 1290 </ul> 1247 <p id="rfc.section.3.2.2.p.10"> <dfn>no-transform</dfn> <span id="rfc.iref.c.2 0"></span> <span id="rfc.iref.n.6"></span>1291 <p id="rfc.section.3.2.2.p.10"> <dfn>no-transform</dfn> <span id="rfc.iref.c.22"></span> <span id="rfc.iref.n.6"></span> 1248 1292 </p> 1249 1293 <ul class="empty"> … … 1295 1339 that time. 1296 1340 </p> 1297 <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.1 7"><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.1341 <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. 1298 1342 </p> 1299 1343 <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.7"></span> <a href="#header.expires" class="smpl">Expires</a> = <a href="#abnf.dependencies" class="smpl">HTTP-date</a> … … 1339 1383 </p> 1340 1384 </div> 1341 <div id="rfc.iref.v. 2"></div>1385 <div id="rfc.iref.v.3"></div> 1342 1386 <div id="rfc.iref.h.6"></div> 1343 1387 <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a> <a id="header.vary" href="#header.vary">Vary</a></h2> … … 1605 1649 <td class="left">http</td> 1606 1650 <td class="left">standard</td> 1607 <td class="left"> <a href="#header.warning" id="rfc.xref.header.warning. 3" title="Warning">Section 3.6</a>1651 <td class="left"> <a href="#header.warning" id="rfc.xref.header.warning.4" title="Warning">Section 3.6</a> 1608 1652 </td> 1609 1653 </tr> … … 1619 1663 </p> 1620 1664 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="acks" href="#acks">Acknowledgments</a></h1> 1621 <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.1 8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.1665 <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>. 1622 1666 </p> 1623 1667 <h1 id="rfc.references"><a id="rfc.section.8" href="#rfc.section.8">8.</a> References … … 1723 1767 </p> 1724 1768 <p id="rfc.section.A.p.5">Do not mention RFC 2047 encoding and multiple languages in Warning header fields anymore, as these aspects never were implemented. 1725 (<a href="#header.warning" id="rfc.xref.header.warning. 4" title="Warning">Section 3.6</a>)1769 (<a href="#header.warning" id="rfc.xref.header.warning.5" title="Warning">Section 3.6</a>) 1726 1770 </p> 1727 1771 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> … … 1997 2041 <li>Cache Directives 1998 2042 <ul> 1999 <li>max-age <a href="#rfc.iref.c.7"><b>3.2.1</b></a>, <a href="#rfc.iref.c.18"><b>3.2.2</b></a></li> 2000 <li>max-stale <a href="#rfc.iref.c.8"><b>3.2.1</b></a></li> 2001 <li>min-fresh <a href="#rfc.iref.c.9"><b>3.2.1</b></a></li> 2002 <li>must-revalidate <a href="#rfc.iref.c.16"><b>3.2.2</b></a></li> 2003 <li>no-cache <a href="#rfc.iref.c.5"><b>3.2.1</b></a>, <a href="#rfc.iref.c.14"><b>3.2.2</b></a></li> 2004 <li>no-store <a href="#rfc.iref.c.6"><b>3.2.1</b></a>, <a href="#rfc.iref.c.15"><b>3.2.2</b></a></li> 2005 <li>no-transform <a href="#rfc.iref.c.10"><b>3.2.1</b></a>, <a href="#rfc.iref.c.20"><b>3.2.2</b></a></li> 2006 <li>only-if-cached <a href="#rfc.iref.c.11"><b>3.2.1</b></a></li> 2007 <li>private <a href="#rfc.iref.c.13"><b>3.2.2</b></a></li> 2008 <li>proxy-revalidate <a href="#rfc.iref.c.17"><b>3.2.2</b></a></li> 2009 <li>public <a href="#rfc.iref.c.12"><b>3.2.2</b></a></li> 2010 <li>s-maxage <a href="#rfc.iref.c.19"><b>3.2.2</b></a></li> 2011 </ul> 2012 </li> 2013 <li>Cache-Control header field <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.4"><b>3.2</b></a>, <a href="#rfc.xref.header.cache-control.3">5.2</a></li> 2043 <li>max-age <a href="#rfc.iref.c.9"><b>3.2.1</b></a>, <a href="#rfc.iref.c.20"><b>3.2.2</b></a></li> 2044 <li>max-stale <a href="#rfc.iref.c.10"><b>3.2.1</b></a></li> 2045 <li>min-fresh <a href="#rfc.iref.c.11"><b>3.2.1</b></a></li> 2046 <li>must-revalidate <a href="#rfc.iref.c.18"><b>3.2.2</b></a></li> 2047 <li>no-cache <a href="#rfc.iref.c.7"><b>3.2.1</b></a>, <a href="#rfc.iref.c.16"><b>3.2.2</b></a></li> 2048 <li>no-store <a href="#rfc.iref.c.8"><b>3.2.1</b></a>, <a href="#rfc.iref.c.17"><b>3.2.2</b></a></li> 2049 <li>no-transform <a href="#rfc.iref.c.12"><b>3.2.1</b></a>, <a href="#rfc.iref.c.22"><b>3.2.2</b></a></li> 2050 <li>only-if-cached <a href="#rfc.iref.c.13"><b>3.2.1</b></a></li> 2051 <li>private <a href="#rfc.iref.c.15"><b>3.2.2</b></a></li> 2052 <li>proxy-revalidate <a href="#rfc.iref.c.19"><b>3.2.2</b></a></li> 2053 <li>public <a href="#rfc.iref.c.14"><b>3.2.2</b></a></li> 2054 <li>s-maxage <a href="#rfc.iref.c.21"><b>3.2.2</b></a></li> 2055 </ul> 2056 </li> 2057 <li>cache entry <a href="#rfc.iref.c.4">2</a></li> 2058 <li>cache key <a href="#rfc.iref.c.5">2</a></li> 2059 <li>Cache-Control header field <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> 2014 2060 <li>cacheable <a href="#rfc.iref.c.3">1.2</a></li> 2015 2061 </ul> … … 2058 2104 <li>Pragma <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> 2059 2105 <li>Vary <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> 2060 <li>Warning <a href="#rfc.xref.header.warning.1">2.3.3</a>, <a href="#rfc.xref.header.warning.2">2.8</a>, <a href="#rfc. iref.h.7"><b>3.6</b></a>, <a href="#rfc.xref.header.warning.3">5.2</a>, <a href="#rfc.xref.header.warning.4">A</a></li>2106 <li>Warning <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> 2061 2107 </ul> 2062 2108 </li> … … 2114 2160 </li> 2115 2161 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 2116 <li><em>Part1</em> <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. 2</a>, <a href="#rfc.xref.Part1.12">2.3.2</a>, <a href="#rfc.xref.Part1.13">2.5</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.7</a>, <a href="#rfc.xref.Part1.17">3.3</a>, <a href="#rfc.xref.Part1.18">7</a>, <a href="#Part1"><b>8.1</b></a><ul>2162 <li><em>Part1</em> <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> 2117 2163 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.1">1.4</a></li> 2118 2164 <li><em>Section 1.2.2</em> <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></li> 2119 2165 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.8">1.4.2</a>, <a href="#rfc.xref.Part1.10">1.4.2</a></li> 2120 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.6">1.4.2</a>, <a href="#rfc.xref.Part1.1 6">2.7</a></li>2121 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.1 1">2.2</a>, <a href="#rfc.xref.Part1.13">2.5</a>, <a href="#rfc.xref.Part1.14">2.5</a>, <a href="#rfc.xref.Part1.15">2.5</a></li>2122 <li><em>Section 6.1</em> <a href="#rfc.xref.Part1.7">1.4.2</a>, <a href="#rfc.xref.Part1.1 7">3.3</a></li>2123 <li><em>Section 9.3</em> <a href="#rfc.xref.Part1.1 2">2.3.2</a></li>2166 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.6">1.4.2</a>, <a href="#rfc.xref.Part1.17">2.7</a></li> 2167 <li><em>Section 4.3</em> <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> 2168 <li><em>Section 6.1</em> <a href="#rfc.xref.Part1.7">1.4.2</a>, <a href="#rfc.xref.Part1.18">3.3</a></li> 2169 <li><em>Section 9.3</em> <a href="#rfc.xref.Part1.13">2.3.2</a></li> 2124 2170 <li><em>Section 9.9</em> <a href="#rfc.xref.Part1.9">1.4.2</a></li> 2125 <li><em>Section 12</em> <a href="#rfc.xref.Part1.18">7</a></li> 2126 </ul> 2127 </li> 2128 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">2.2</a>, <a href="#rfc.xref.Part2.2">2.3.1.1</a>, <a href="#rfc.xref.Part2.3">2.5</a>, <a href="#Part2"><b>8.1</b></a><ul> 2129 <li><em>Section 7.1.1</em> <a href="#rfc.xref.Part2.1">2.2</a>, <a href="#rfc.xref.Part2.3">2.5</a></li> 2130 <li><em>Section 8</em> <a href="#rfc.xref.Part2.2">2.3.1.1</a></li> 2131 </ul> 2132 </li> 2133 <li><em>Part4</em> <a href="#rfc.xref.Part4.1">2.3.1.1</a>, <a href="#rfc.xref.Part4.2">2.4</a>, <a href="#rfc.xref.Part4.3">2.8</a>, <a href="#Part4"><b>8.1</b></a><ul> 2134 <li><em>Section 2.1</em> <a href="#rfc.xref.Part4.1">2.3.1.1</a></li> 2135 <li><em>Section 2.2.2</em> <a href="#rfc.xref.Part4.3">2.8</a></li> 2136 </ul> 2137 </li> 2138 <li><em>Part5</em> <a href="#rfc.xref.Part5.1">2.1.1</a>, <a href="#rfc.xref.Part5.2">2.1.1</a>, <a href="#Part5"><b>8.1</b></a><ul> 2139 <li><em>Section 4</em> <a href="#rfc.xref.Part5.2">2.1.1</a></li> 2171 <li><em>Section 12</em> <a href="#rfc.xref.Part1.19">7</a></li> 2172 </ul> 2173 </li> 2174 <li><em>Part2</em> <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> 2175 <li><em>Section 7.1.1</em> <a href="#rfc.xref.Part2.2">2.2</a>, <a href="#rfc.xref.Part2.4">2.5</a></li> 2176 <li><em>Section 8</em> <a href="#rfc.xref.Part2.3">2.3.1.1</a></li> 2177 </ul> 2178 </li> 2179 <li><em>Part4</em> <a href="#rfc.xref.Part4.1">1.2</a>, <a href="#rfc.xref.Part4.2">1.2</a>, <a href="#rfc.xref.Part4.3">1.2</a>, <a href="#rfc.xref.Part4.4">2.3.1.1</a>, <a href="#rfc.xref.Part4.5">2.4</a>, <a href="#Part4"><b>8.1</b></a><ul> 2180 <li><em>Section 2.1</em> <a href="#rfc.xref.Part4.4">2.3.1.1</a></li> 2181 <li><em>Section 2.1.2</em> <a href="#rfc.xref.Part4.3">1.2</a></li> 2182 <li><em>Section 2.2</em> <a href="#rfc.xref.Part4.2">1.2</a></li> 2183 <li><em>Section 2.2.2</em> <a href="#rfc.xref.Part4.1">1.2</a></li> 2184 </ul> 2185 </li> 2186 <li><em>Part5</em> <a href="#rfc.xref.Part5.1">2.1</a>, <a href="#rfc.xref.Part5.2">2.8</a>, <a href="#rfc.xref.Part5.3">2.8</a>, <a href="#Part5"><b>8.1</b></a><ul> 2187 <li><em>Section 4</em> <a href="#rfc.xref.Part5.3">2.8</a></li> 2140 2188 </ul> 2141 2189 </li> … … 2189 2237 <li>s-maxage 2190 2238 <ul> 2191 <li>Cache Directive <a href="#rfc.iref.s. 3"><b>3.2.2</b></a></li>2239 <li>Cache Directive <a href="#rfc.iref.s.4"><b>3.2.2</b></a></li> 2192 2240 </ul> 2193 2241 </li> 2194 2242 <li>shared cache <a href="#rfc.iref.s.1">1.2</a></li> 2195 2243 <li>stale <a href="#rfc.iref.s.2">1.2</a></li> 2244 <li>strong validator <a href="#rfc.iref.s.3">1.2</a></li> 2196 2245 </ul> 2197 2246 </li> 2198 2247 <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul> 2199 2248 <li>validator <a href="#rfc.iref.v.1">1.2</a></li> 2200 <li>Vary header field <a href="#rfc.xref.header.vary.1">2.7</a>, <a href="#rfc.iref.v.2"><b>3.5</b></a>, <a href="#rfc.xref.header.vary.2">5.2</a></li> 2249 <li>validator, strong <a href="#rfc.iref.v.2">1.2</a></li> 2250 <li>Vary header field <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> 2201 2251 </ul> 2202 2252 </li> 2203 2253 <li><a id="rfc.index.W" href="#rfc.index.W"><b>W</b></a><ul> 2204 <li>Warning header field <a href="#rfc.xref.header.warning.1">2.3.3</a>, <a href="#rfc.xref.header.warning.2">2.8</a>, <a href="#rfc. iref.w.1"><b>3.6</b></a>, <a href="#rfc.xref.header.warning.3">5.2</a>, <a href="#rfc.xref.header.warning.4">A</a></li>2254 <li>Warning header field <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> 2205 2255 </ul> 2206 2256 </li>
Note: See TracChangeset
for help on using the changeset viewer.