Changeset 1375


Ignore:
Timestamp:
Aug 3, 2011, 10:44:42 PM (8 years ago)
Author:
fielding@…
Message:

update generated html

Location:
draft-ietf-httpbis/latest
Files:
4 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p1-messaging.html

    r1373 r1375  
    572572               <li>3.2&nbsp;&nbsp;&nbsp;<a href="#header.fields">Header Fields</a></li>
    573573               <li>3.3&nbsp;&nbsp;&nbsp;<a href="#message.body">Message Body</a></li>
    574                <li>3.4&nbsp;&nbsp;&nbsp;<a href="#general.header.fields">General Header Fields</a></li>
     574               <li>3.4&nbsp;&nbsp;&nbsp;<a href="#incomplete.messages">Incomplete Messages</a></li>
     575               <li>3.5&nbsp;&nbsp;&nbsp;<a href="#general.header.fields">General Header Fields</a></li>
    575576            </ul>
    576577         </li>
    … …  
    13721373         knowledge can be in the form of specific user configuration or by remembering the version of a prior received response.
    13731374      </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>&nbsp;<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
    13791392         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
    13801393         requests on a connection is described in <a href="#pipelining" title="Pipelining">Section&nbsp;7.1.2.2</a>.
    13811394      </p>
    1382       <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;<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 apply
     1395      <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a>&nbsp;<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
    13841397         to the payload being transferred. These header fields apply only to the message being transmitted.
    13851398      </p>
    … …  
    36643677                  <li>compress (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.8">6.2.2.1</a></li>
    36653678                  <li>connection&nbsp;&nbsp;<a href="#rfc.iref.c.2"><b>2.1</b></a></li>
    3666                   <li>Connection header field&nbsp;&nbsp;<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&nbsp;&nbsp;<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>
    36673680                  <li>Content-Length header field&nbsp;&nbsp;<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>
    36683681               </ul>
    36693682            </li>
    36703683            <li><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul>
    3671                   <li>Date header field&nbsp;&nbsp;<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&nbsp;&nbsp;<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>
    36723685                  <li>deflate (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.d.2">6.2.2.2</a></li>
    36733686                  <li>downstream&nbsp;&nbsp;<a href="#rfc.iref.d.1"><b>2.4</b></a></li>
    … …  
    37973810                  <li>Header Fields&nbsp;&nbsp;
    37983811                     <ul>
    3799                         <li>Connection&nbsp;&nbsp;<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&nbsp;&nbsp;<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>
    38003813                        <li>Content-Length&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<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>
    38023815                        <li>Host&nbsp;&nbsp;<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>
    38033816                        <li>TE&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<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>
    38083821                     </ul>
    38093822                  </li>
    … …  
    38693882                     </ul>
    38703883                  </li>
    3871                   <li><em>Part6</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>
    38723885                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.2">2.5</a></li>
    3873                         <li><em>Section 2.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.4">3.3</a></li>
     3886                        <li><em>Section 2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.4">3.4</a></li>
    38743887                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.3">2.7.2</a>, <a href="#rfc.xref.Part6.6">9.1</a></li>
    38753888                        <li><em>Section 3.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">2.4</a>, <a href="#rfc.xref.Part6.5">7.1.3.2</a></li>
    … …  
    39643977                  <li>TE header field&nbsp;&nbsp;<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>
    39653978                  <li><em>Tou1998</em>&nbsp;&nbsp;<a href="#rfc.xref.Tou1998.1">7.1.1</a>, <a href="#Tou1998"><b>13.2</b></a></li>
    3966                   <li>Trailer header field&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<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>
    39683981                  <li>transforming proxy&nbsp;&nbsp;<a href="#rfc.iref.t.1"><b>2.4</b></a></li>
    39693982                  <li>transparent proxy&nbsp;&nbsp;<a href="#rfc.iref.t.3"><b>2.4</b></a></li>
    … …  
    39723985            </li>
    39733986            <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul>
    3974                   <li>Upgrade header field&nbsp;&nbsp;<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&nbsp;&nbsp;<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>
    39753988                  <li>upstream&nbsp;&nbsp;<a href="#rfc.iref.u.2"><b>2.4</b></a></li>
    39763989                  <li>URI scheme&nbsp;&nbsp;
    … …  
    39853998            </li>
    39863999            <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul>
    3987                   <li>Via header field&nbsp;&nbsp;<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&nbsp;&nbsp;<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>
    39884001               </ul>
    39894002            </li>

  • draft-ietf-httpbis/latest/p2-semantics.html

    r1373 r1375  
    12651265         </li>
    12661266         <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.
    12681268         </li>
    12691269         <li>If the response has a Content-Location header field, and that URI is the same as the effective request URI, the response payload
    … …  
    13491349         to reject the request.
    13501350      </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>).
    13521352      </p>
    13531353      <p id="rfc.section.7.3.p.7">See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section&nbsp;11.2</a> for security considerations when used for forms.
    … …  
    13601360         hypertext links for validity, accessibility, and recent modification.
    13611361      </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 cached
     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.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
    13631363         representation differs from the current representation (as would be indicated by a change in Content-Length, ETag or Last-Modified),
    13641364         then the cache <em class="bcp14">MUST</em> treat the cache entry as stale.
    … …  
    13891389         a Location header field (see <a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section&nbsp;9.4</a>).
    13901390      </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.
    13921392      </p>
    13931393      <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
    … …  
    14541454      </p>
    14551455      <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>).
    14571457      </p>
    14581458      <div id="rfc.iref.d.1"></div>
    … …  
    14711471      </p>
    14721472      <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>).
    14741474      </p>
    14751475      <h2 id="rfc.section.7.8"><a href="#rfc.section.7.8">7.8</a>&nbsp;<a id="TRACE" href="#TRACE">TRACE</a></h2>
    … …  
    15741574         <dd>a representation containing the request message as received by the end server.</dd>
    15751575      </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.11"><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.
    15771577      </p>
    15781578      <div id="rfc.iref.25"></div>
    … …  
    16031603      <div id="rfc.iref.s.7"></div>
    16041604      <h3 id="rfc.section.8.2.4"><a href="#rfc.section.8.2.4">8.2.4</a>&nbsp;<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.12"><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>).
    16061606      </p>
    16071607      <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.13"><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.14"><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.
    16111611      </p>
    16121612      <div id="rfc.iref.28"></div>
    … …  
    16461646         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>.
    16471647      </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.15"><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.
    16491649      </p>
    16501650      <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a>&nbsp;<a id="status.3xx" href="#status.3xx">Redirection 3xx</a></h2>
    … …  
    16701670      <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.
    16711671      </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.16"><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.
    16731673      </p>
    16741674      <div id="rfc.iref.32"></div>
    … …  
    16781678         request URI to one or more of the new references returned by the server, where possible.
    16791679      </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.17"><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.
    16811681      </p>
    16821682      <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).
    … …  
    18511851         — that is left to the discretion of the server owner.
    18521852      </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.18"><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.
    18541854      </p>
    18551855      <div id="rfc.iref.50"></div>
    … …  
    32753275                     </ul>
    32763276                  </li>
    3277                   <li><em>Part6</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part6.8">7.5</a></li>
    3279                         <li><em>Section 2.3.1.1</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part6.5">6.1</a></li>
     3277                  <li><em>Part6</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part6.7">7.5</a></li>
     3279                        <li><em>Section 2.3.1.1</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part6.8">7.6</a>, <a href="#rfc.xref.Part6.9">7.7</a></li>
    32823281                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.3">5</a></li>
    3283                         <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.12">8.2.4</a></li>
     3282                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.11">8.2.4</a></li>
    32843283                        <li><em>Section 3.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.4">5</a></li>
    3285                         <li><em>Section 3.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.13">8.2.4</a></li>
     3284                        <li><em>Section 3.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.12">8.2.4</a></li>
    32863285                     </ul>
    32873286                  </li>

  • draft-ietf-httpbis/latest/p5-range.html

    r1373 r1375  
    611611      </ul>
    612612      <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<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 cache
     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 client
    614614         has stored a partial representation, it is desirable to request the remainder of that representation in a subsequent request
    615615         rather than transfer the entire representation. There are also a number of Web applications that benefit from being able to
    … …  
    694694      <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.
    695695      </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&nbsp;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, then
    700          it <em class="bcp14">MUST NOT</em> be cached either.
    701       </p>
    702696      <div id="rfc.iref.4"></div>
    703697      <div id="rfc.iref.s.2"></div>
    … …  
    710704      </p>
    711705      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<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.
    726728      </p>
    727729      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
    … …  
    825827      <div id="rfc.iref.h.3"></div>
    826828      <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a>&nbsp;<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 representation
    828          in its cache, it could use the Range header field with a conditional GET (using either or both of If-Unmodified-Since and
    829          If-Match.) However, if the condition fails because the representation has been modified, the client would then have to make
    830          a second request to obtain 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.
    831833      </p>
    832834      <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
    … …  
    834836      </p>
    835837      <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-tag
    839          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 the
    845          server <em class="bcp14">SHOULD</em> provide the specified sub-range of the representation using a 206 (Partial Content) response. If the cache validator does
    846          not match, then the server <em class="bcp14">SHOULD</em> return the 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.
    847849      </p>
    848850      <div id="rfc.iref.r.1"></div>
    … …  
    913915  <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>
    914916  <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 when
    916          possible, since Range supports efficient recovery from partially failed transfers, and supports efficient partial retrieval
    917          of large representations.
     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.
    918920      </p>
    919921      <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>
    … …  
    12171219      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="compatibility" href="#compatibility">Compatibility with Previous Versions</a></h1>
    12181220      <h2 id="rfc.section.B.1"><a href="#rfc.section.B.1">B.1</a>&nbsp;<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 cache validator in a 206 response. (<a href="#status.206" id="rfc.xref.status.206.2" title="206 Partial Content">Section&nbsp;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&nbsp;3.1</a>)
    12201222      </p>
    12211223      <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&nbsp;5</a>)
    … …  
    14861488                     </ul>
    14871489                  </li>
    1488                   <li><em>Part4</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part4.4">5.3</a></li>
    1490                         <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">1.2.2</a></li>
    1491                         <li><em>Section 2.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.2">4</a>, <a href="#rfc.xref.Part4.3">5.3</a></li>
     1490                  <li><em>Part4</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">1.2.2</a>, <a href="#rfc.xref.Part4.2">4</a></li>
    14921493                     </ul>
    14931494                  </li>

  • draft-ietf-httpbis/latest/p6-cache.html

    r1373 r1375  
    556556         </li>
    557557         <li>2.&nbsp;&nbsp;&nbsp;<a href="#caching.overview">Cache Operation</a><ul>
    558                <li>2.1&nbsp;&nbsp;&nbsp;<a href="#response.cacheability">Response Cacheability</a><ul>
    559                      <li>2.1.1&nbsp;&nbsp;&nbsp;<a href="#errors.or.incomplete.response.cache.behavior">Storing Partial and Incomplete Responses</a></li>
    560                   </ul>
    561                </li>
     558               <li>2.1&nbsp;&nbsp;&nbsp;<a href="#response.cacheability">Response Cacheability</a></li>
    562559               <li>2.2&nbsp;&nbsp;&nbsp;<a href="#constructing.responses.from.caches">Constructing Responses from Caches</a></li>
    563560               <li>2.3&nbsp;&nbsp;&nbsp;<a href="#expiration.model">Freshness Model</a><ul>
    … …  
    574571               <li>2.6&nbsp;&nbsp;&nbsp;<a href="#caching.authenticated.responses">Shared Caching of Authenticated Responses</a></li>
    575572               <li>2.7&nbsp;&nbsp;&nbsp;<a href="#caching.negotiated.responses">Caching Negotiated Responses</a></li>
    576                <li>2.8&nbsp;&nbsp;&nbsp;<a href="#combining.responses">Combining Responses</a></li>
     573               <li>2.8&nbsp;&nbsp;&nbsp;<a href="#combining.responses">Combining Partial Content</a></li>
     574               <li>2.9&nbsp;&nbsp;&nbsp;<a href="#freshening.responses">Freshening Responses</a></li>
    577575            </ul>
    578576         </li>
    … …  
    639637         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.
    640638      </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 prior
    642          response message to satisfy a current request. In some cases, a stored response can be reused without the need for a network
    643          request, reducing latency and network round-trips; a "freshness" mechanism is used for this purpose (see <a href="#expiration.model" title="Freshness Model">Section&nbsp;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 satisfy
    644          the request, thereby reducing network bandwidth usage; a "validation" mechanism is used for this purpose (see <a href="#validation.model" title="Validation Model">Section&nbsp;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&nbsp;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&nbsp;2.4</a>) or if the origin is unavailable.
    645643      </p>
    646644      <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a id="intro.terminology" href="#intro.terminology">Terminology</a></h2>
    … …  
    657655         </p>
    658656         <ul class="empty">
    659             <li>A cache that is accessible to more 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>
    660658         </ul>
    661659      </div>
    … …  
    712710      <ul class="empty">
    713711         <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>.
    715720         </li>
    716721      </ul>
    … …  
    750755         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.
    751756      </p>
     757      <div id="rfc.iref.c.4"></div>
     758      <div id="rfc.iref.c.5"></div>
    752759      <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<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&nbsp;2.7</a>).
     775      </p>
    753776      <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="response.cacheability" href="#response.cacheability">Response Cacheability</a></h2>
    754777      <p id="rfc.section.2.1.p.1">A cache <em class="bcp14">MUST NOT</em> store a response to any request, unless:
    … …  
    779802      <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&nbsp;3.2.3</a>.
    780803      </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&nbsp;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
    786808         time, as such responses are not usually useful to store. However, caches are not prohibited from storing such responses.
    787809      </p>
    788       <h3 id="rfc.section.2.1.1"><a href="#rfc.section.2.1.1">2.1.1</a>&nbsp;<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&nbsp;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.
    793817      </p>
    794818      <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="constructing.responses.from.caches" href="#constructing.responses.from.caches">Constructing Responses from Caches</a></h2>
    … …  
    796820      </p>
    797821      <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.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and that of the stored response match, and
     822         <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
    799823         </li>
    800824         <li>the request method associated with the stored response allows it to be used for the presented request, and</li>
    … …  
    818842      <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&nbsp;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&nbsp;2.3.2</a>.
    819843      </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 and
     844      <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
    821845         having received a corresponding response.
    822846      </p>
    … …  
    869893      <h4 id="rfc.section.2.3.1.1"><a href="#rfc.section.2.3.1.1">2.3.1.1</a>&nbsp;<a id="heuristic.freshness" href="#heuristic.freshness">Calculating Heuristic Freshness</a></h4>
    870894      <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.
    872896      </p>
    873897      <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
    874898         is not already present.
    875899      </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 this
     900      <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
    877901         fraction might be 10%.
    878902      </p>
    … …  
    901925         <li>HTTP/1.1 requires origin servers to send a Date header field, if possible, with every response, giving the time at which the
    902926            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.12"><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.
    904928         </li>
    905929      </ul>
    … …  
    958982      <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;<a id="validation.model" href="#validation.model">Validation Model</a></h2>
    959983      <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&nbsp;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 to
     984         fresh, or one cannot be selected; see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;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
    961985         update it. This process is known as "validating" or "revalidating" the stored response.
    962986      </p>
    … …  
    967991         that stored response.
    968992      </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&nbsp;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&nbsp;2.9</a>.
    970994      </p>
    971995      <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).
    973997      </p>
    974998      <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&nbsp;2.3.3</a>).
    975999      </p>
    9761000      <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a>&nbsp;<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 them
     1001      <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
    9781002         to keep their contents up-to-date.
    9791003      </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.13"><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
     1004      <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
    9811005         with an unsafe method is received.
    9821006      </p>
    9831007      <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.14"><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.15"><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.
    9871011      </p>
    9881012      <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
    … …  
    10111035      <ul>
    10121036         <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.16"><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>)
    10141038         </li>
    10151039         <li>normalizing both header field values in a way that is known to have identical semantics, according to the header field's specification
    … …  
    10281052      <p id="rfc.section.2.7.p.7">If no selected response is available, the cache <em class="bcp14">MAY</em> forward the presented request to the origin server in a conditional request; see <a href="#validation.model" title="Validation Model">Section&nbsp;2.4</a>.
    10291053      </p>
    1030       <h2 id="rfc.section.2.8"><a href="#rfc.section.2.8">2.8</a>&nbsp;<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&nbsp;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>&nbsp;<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&nbsp;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>&nbsp;<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&nbsp;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>
    10521096      <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
    10531097      <p id="rfc.section.3.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to caching.</p>
    … …  
    10641108         true, since HTTP/1.0 caches might not implement the Age header field.
    10651109      </p>
    1066       <div id="rfc.iref.c.4"></div>
     1110      <div id="rfc.iref.c.6"></div>
    10671111      <div id="rfc.iref.h.3"></div>
    10681112      <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="header.cache-control" href="#header.cache-control">Cache-Control</a></h2>
    … …  
    10971141     / "only-if-cached"
    10981142     / <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> 
    11001144      </p>
    11011145      <ul class="empty">
    … …  
    11031147         </li>
    11041148      </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> 
    11061150      </p>
    11071151      <ul class="empty">
    … …  
    11151159         </li>
    11161160      </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> 
    11181162      </p>
    11191163      <ul class="empty">
    … …  
    11221166         </li>
    11231167      </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> 
    11251169      </p>
    11261170      <ul class="empty">
    … …  
    11311175         </li>
    11321176      </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> 
    11341178      </p>
    11351179      <ul class="empty">
    … …  
    11391183         </li>
    11401184      </ul>
    1141       <p id="rfc.section.3.2.1.p.7"> <dfn>no-transform</dfn>  <span id="rfc.iref.c.10"></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> 
    11421186      </p>
    11431187      <ul class="empty">
    … …  
    11451189         </li>
    11461190      </ul>
    1147       <p id="rfc.section.3.2.1.p.8"> <dfn>only-if-cached</dfn>  <span id="rfc.iref.c.11"></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> 
    11481192      </p>
    11491193      <ul class="empty">
    … …  
    11661210     / "s-maxage" "=" <a href="#delta-seconds" class="smpl">delta-seconds</a>
    11671211     / <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.12"></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> 
    11691213      </p>
    11701214      <ul class="empty">
    … …  
    11721216         </li>
    11731217      </ul>
    1174       <p id="rfc.section.3.2.2.p.3"> <dfn>private</dfn>  <span id="rfc.iref.c.13"></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> 
    11751219      </p>
    11761220      <ul class="empty">
    … …  
    11851229         </li>
    11861230      </ul>
    1187       <p id="rfc.section.3.2.2.p.4"> <dfn>no-cache</dfn>  <span id="rfc.iref.c.14"></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> 
    11881232      </p>
    11891233      <ul class="empty">
    … …  
    12021246         </li>
    12031247      </ul>
    1204       <p id="rfc.section.3.2.2.p.5"> <dfn>no-store</dfn>  <span id="rfc.iref.c.15"></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> 
    12051249      </p>
    12061250      <ul class="empty">
    … …  
    12111255         </li>
    12121256      </ul>
    1213       <p id="rfc.section.3.2.2.p.6"> <dfn>must-revalidate</dfn>  <span id="rfc.iref.c.16"></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> 
    12141258      </p>
    12151259      <ul class="empty">
    … …  
    12231267         </li>
    12241268      </ul>
    1225       <p id="rfc.section.3.2.2.p.7"> <dfn>proxy-revalidate</dfn>  <span id="rfc.iref.c.17"></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> 
    12261270      </p>
    12271271      <ul class="empty">
    … …  
    12301274         </li>
    12311275      </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> 
    12331277      </p>
    12341278      <ul class="empty">
    … …  
    12371281         </li>
    12381282      </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> 
    12401284      </p>
    12411285      <ul class="empty">
    … …  
    12451289         </li>
    12461290      </ul>
    1247       <p id="rfc.section.3.2.2.p.10"> <dfn>no-transform</dfn>  <span id="rfc.iref.c.20"></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> 
    12481292      </p>
    12491293      <ul class="empty">
    … …  
    12951339         that time.
    12961340      </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.17"><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.
    12981342      </p>
    12991343      <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>
    … …  
    13391383         </p>
    13401384      </div>
    1341       <div id="rfc.iref.v.2"></div>
     1385      <div id="rfc.iref.v.3"></div>
    13421386      <div id="rfc.iref.h.6"></div>
    13431387      <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a>&nbsp;<a id="header.vary" href="#header.vary">Vary</a></h2>
    … …  
    16051649                  <td class="left">http</td>
    16061650                  <td class="left">standard</td>
    1607                   <td class="left"> <a href="#header.warning" id="rfc.xref.header.warning.3" title="Warning">Section&nbsp;3.6</a>
     1651                  <td class="left"> <a href="#header.warning" id="rfc.xref.header.warning.4" title="Warning">Section&nbsp;3.6</a>
    16081652                  </td>
    16091653               </tr>
    … …  
    16191663      </p>
    16201664      <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<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.18"><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>.
    16221666      </p>
    16231667      <h1 id="rfc.references"><a id="rfc.section.8" href="#rfc.section.8">8.</a> References
    … …  
    17231767      </p>
    17241768      <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&nbsp;3.6</a>)
     1769         (<a href="#header.warning" id="rfc.xref.header.warning.5" title="Warning">Section&nbsp;3.6</a>)
    17261770      </p>
    17271771      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    … …  
    19972041                  <li>Cache Directives&nbsp;&nbsp;
    19982042                     <ul>
    1999                         <li>max-age&nbsp;&nbsp;<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&nbsp;&nbsp;<a href="#rfc.iref.c.8"><b>3.2.1</b></a></li>
    2001                         <li>min-fresh&nbsp;&nbsp;<a href="#rfc.iref.c.9"><b>3.2.1</b></a></li>
    2002                         <li>must-revalidate&nbsp;&nbsp;<a href="#rfc.iref.c.16"><b>3.2.2</b></a></li>
    2003                         <li>no-cache&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<a href="#rfc.iref.c.11"><b>3.2.1</b></a></li>
    2007                         <li>private&nbsp;&nbsp;<a href="#rfc.iref.c.13"><b>3.2.2</b></a></li>
    2008                         <li>proxy-revalidate&nbsp;&nbsp;<a href="#rfc.iref.c.17"><b>3.2.2</b></a></li>
    2009                         <li>public&nbsp;&nbsp;<a href="#rfc.iref.c.12"><b>3.2.2</b></a></li>
    2010                         <li>s-maxage&nbsp;&nbsp;<a href="#rfc.iref.c.19"><b>3.2.2</b></a></li>
    2011                      </ul>
    2012                   </li>
    2013                   <li>Cache-Control header field&nbsp;&nbsp;<a href="#rfc.xref.header.cache-control.1">2.1</a>, <a href="#rfc.xref.header.cache-control.2">2.2</a>, <a href="#rfc.iref.c.4"><b>3.2</b></a>, <a href="#rfc.xref.header.cache-control.3">5.2</a></li>
     2043                        <li>max-age&nbsp;&nbsp;<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&nbsp;&nbsp;<a href="#rfc.iref.c.10"><b>3.2.1</b></a></li>
     2045                        <li>min-fresh&nbsp;&nbsp;<a href="#rfc.iref.c.11"><b>3.2.1</b></a></li>
     2046                        <li>must-revalidate&nbsp;&nbsp;<a href="#rfc.iref.c.18"><b>3.2.2</b></a></li>
     2047                        <li>no-cache&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<a href="#rfc.iref.c.13"><b>3.2.1</b></a></li>
     2051                        <li>private&nbsp;&nbsp;<a href="#rfc.iref.c.15"><b>3.2.2</b></a></li>
     2052                        <li>proxy-revalidate&nbsp;&nbsp;<a href="#rfc.iref.c.19"><b>3.2.2</b></a></li>
     2053                        <li>public&nbsp;&nbsp;<a href="#rfc.iref.c.14"><b>3.2.2</b></a></li>
     2054                        <li>s-maxage&nbsp;&nbsp;<a href="#rfc.iref.c.21"><b>3.2.2</b></a></li>
     2055                     </ul>
     2056                  </li>
     2057                  <li>cache entry&nbsp;&nbsp;<a href="#rfc.iref.c.4">2</a></li>
     2058                  <li>cache key&nbsp;&nbsp;<a href="#rfc.iref.c.5">2</a></li>
     2059                  <li>Cache-Control header field&nbsp;&nbsp;<a href="#rfc.xref.header.cache-control.1">2.1</a>, <a href="#rfc.xref.header.cache-control.2">2.2</a>, <a href="#rfc.iref.c.6"><b>3.2</b></a>, <a href="#rfc.xref.header.cache-control.3">5.2</a></li>
    20142060                  <li>cacheable&nbsp;&nbsp;<a href="#rfc.iref.c.3">1.2</a></li>
    20152061               </ul>
    … …  
    20582104                        <li>Pragma&nbsp;&nbsp;<a href="#rfc.xref.header.pragma.1">2.2</a>, <a href="#rfc.xref.header.pragma.2">3.2</a>, <a href="#rfc.iref.h.5"><b>3.4</b></a>, <a href="#rfc.xref.header.pragma.3">5.2</a></li>
    20592105                        <li>Vary&nbsp;&nbsp;<a href="#rfc.xref.header.vary.1">2.7</a>, <a href="#rfc.iref.h.6"><b>3.5</b></a>, <a href="#rfc.xref.header.vary.2">5.2</a></li>
    2060                         <li>Warning&nbsp;&nbsp;<a href="#rfc.xref.header.warning.1">2.3.3</a>, <a href="#rfc.xref.header.warning.2">2.8</a>, <a href="#rfc.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&nbsp;&nbsp;<a href="#rfc.xref.header.warning.1">2.3.3</a>, <a href="#rfc.xref.header.warning.2">2.8</a>, <a href="#rfc.xref.header.warning.3">2.9</a>, <a href="#rfc.iref.h.7"><b>3.6</b></a>, <a href="#rfc.xref.header.warning.4">5.2</a>, <a href="#rfc.xref.header.warning.5">A</a></li>
    20612107                     </ul>
    20622108                  </li>
    … …  
    21142160            </li>
    21152161            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    2116                   <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.4</a>, <a href="#rfc.xref.Part1.2">1.4.1</a>, <a href="#rfc.xref.Part1.3">1.4.1</a>, <a href="#rfc.xref.Part1.4">1.4.1</a>, <a href="#rfc.xref.Part1.5">1.4.1</a>, <a href="#rfc.xref.Part1.6">1.4.2</a>, <a href="#rfc.xref.Part1.7">1.4.2</a>, <a href="#rfc.xref.Part1.8">1.4.2</a>, <a href="#rfc.xref.Part1.9">1.4.2</a>, <a href="#rfc.xref.Part1.10">1.4.2</a>, <a href="#rfc.xref.Part1.11">2.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>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.4</a>, <a href="#rfc.xref.Part1.2">1.4.1</a>, <a href="#rfc.xref.Part1.3">1.4.1</a>, <a href="#rfc.xref.Part1.4">1.4.1</a>, <a href="#rfc.xref.Part1.5">1.4.1</a>, <a href="#rfc.xref.Part1.6">1.4.2</a>, <a href="#rfc.xref.Part1.7">1.4.2</a>, <a href="#rfc.xref.Part1.8">1.4.2</a>, <a href="#rfc.xref.Part1.9">1.4.2</a>, <a href="#rfc.xref.Part1.10">1.4.2</a>, <a href="#rfc.xref.Part1.11">2.1</a>, <a href="#rfc.xref.Part1.12">2.2</a>, <a href="#rfc.xref.Part1.13">2.3.2</a>, <a href="#rfc.xref.Part1.14">2.5</a>, <a href="#rfc.xref.Part1.15">2.5</a>, <a href="#rfc.xref.Part1.16">2.5</a>, <a href="#rfc.xref.Part1.17">2.7</a>, <a href="#rfc.xref.Part1.18">3.3</a>, <a href="#rfc.xref.Part1.19">7</a>, <a href="#Part1"><b>8.1</b></a><ul>
    21172163                        <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.4</a></li>
    21182164                        <li><em>Section 1.2.2</em>&nbsp;&nbsp;<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>
    21192165                        <li><em>Section 2.7</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part1.6">1.4.2</a>, <a href="#rfc.xref.Part1.16">2.7</a></li>
    2121                         <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.11">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>&nbsp;&nbsp;<a href="#rfc.xref.Part1.7">1.4.2</a>, <a href="#rfc.xref.Part1.17">3.3</a></li>
    2123                         <li><em>Section 9.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.12">2.3.2</a></li>
     2166                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.6">1.4.2</a>, <a href="#rfc.xref.Part1.17">2.7</a></li>
     2167                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.12">2.2</a>, <a href="#rfc.xref.Part1.14">2.5</a>, <a href="#rfc.xref.Part1.15">2.5</a>, <a href="#rfc.xref.Part1.16">2.5</a></li>
     2168                        <li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.7">1.4.2</a>, <a href="#rfc.xref.Part1.18">3.3</a></li>
     2169                        <li><em>Section 9.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.13">2.3.2</a></li>
    21242170                        <li><em>Section 9.9</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.9">1.4.2</a></li>
    2125                         <li><em>Section 12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.18">7</a></li>
    2126                      </ul>
    2127                   </li>
    2128                   <li><em>Part2</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">2.3.1.1</a></li>
    2131                      </ul>
    2132                   </li>
    2133                   <li><em>Part4</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">2.3.1.1</a></li>
    2135                         <li><em>Section 2.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.3">2.8</a></li>
    2136                      </ul>
    2137                   </li>
    2138                   <li><em>Part5</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part5.2">2.1.1</a></li>
     2171                        <li><em>Section 12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.19">7</a></li>
     2172                     </ul>
     2173                  </li>
     2174                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2</a>, <a href="#rfc.xref.Part2.2">2.2</a>, <a href="#rfc.xref.Part2.3">2.3.1.1</a>, <a href="#rfc.xref.Part2.4">2.5</a>, <a href="#Part2"><b>8.1</b></a><ul>
     2175                        <li><em>Section 7.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">2.2</a>, <a href="#rfc.xref.Part2.4">2.5</a></li>
     2176                        <li><em>Section 8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.3.1.1</a></li>
     2177                     </ul>
     2178                  </li>
     2179                  <li><em>Part4</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part4.4">2.3.1.1</a></li>
     2181                        <li><em>Section 2.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.3">1.2</a></li>
     2182                        <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.2">1.2</a></li>
     2183                        <li><em>Section 2.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">1.2</a></li>
     2184                     </ul>
     2185                  </li>
     2186                  <li><em>Part5</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.Part5.3">2.8</a></li>
    21402188                     </ul>
    21412189                  </li>
    … …  
    21892237                  <li>s-maxage&nbsp;&nbsp;
    21902238                     <ul>
    2191                         <li>Cache Directive&nbsp;&nbsp;<a href="#rfc.iref.s.3"><b>3.2.2</b></a></li>
     2239                        <li>Cache Directive&nbsp;&nbsp;<a href="#rfc.iref.s.4"><b>3.2.2</b></a></li>
    21922240                     </ul>
    21932241                  </li>
    21942242                  <li>shared cache&nbsp;&nbsp;<a href="#rfc.iref.s.1">1.2</a></li>
    21952243                  <li>stale&nbsp;&nbsp;<a href="#rfc.iref.s.2">1.2</a></li>
     2244                  <li>strong validator&nbsp;&nbsp;<a href="#rfc.iref.s.3">1.2</a></li>
    21962245               </ul>
    21972246            </li>
    21982247            <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul>
    21992248                  <li>validator&nbsp;&nbsp;<a href="#rfc.iref.v.1">1.2</a></li>
    2200                   <li>Vary header field&nbsp;&nbsp;<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&nbsp;&nbsp;<a href="#rfc.iref.v.2">1.2</a></li>
     2250                  <li>Vary header field&nbsp;&nbsp;<a href="#rfc.xref.header.vary.1">2.7</a>, <a href="#rfc.iref.v.3"><b>3.5</b></a>, <a href="#rfc.xref.header.vary.2">5.2</a></li>
    22012251               </ul>
    22022252            </li>
    22032253            <li><a id="rfc.index.W" href="#rfc.index.W"><b>W</b></a><ul>
    2204                   <li>Warning header field&nbsp;&nbsp;<a href="#rfc.xref.header.warning.1">2.3.3</a>, <a href="#rfc.xref.header.warning.2">2.8</a>, <a href="#rfc.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&nbsp;&nbsp;<a href="#rfc.xref.header.warning.1">2.3.3</a>, <a href="#rfc.xref.header.warning.2">2.8</a>, <a href="#rfc.xref.header.warning.3">2.9</a>, <a href="#rfc.iref.w.1"><b>3.6</b></a>, <a href="#rfc.xref.header.warning.4">5.2</a>, <a href="#rfc.xref.header.warning.5">A</a></li>
    22052255               </ul>
    22062256            </li>
Note: See TracChangeset for help on using the changeset viewer.