Changeset 500 for draft-ietf-httpbis


Ignore:
Timestamp:
Mar 3, 2009, 11:40:49 PM (11 years ago)
Author:
julian.reschke@…
Message:

sync P1-P5/P7 from latest, re-gen HTML

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

Legend:

Unmodified
Added
Removed

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

    r462 r500  
    471471         <tr>
    472472            <td class="header left"></td>
    473             <td class="header right">March 2, 2009</td>
     473            <td class="header right">March 4, 2009</td>
    474474         </tr>
    475475      </table>
    … …  
    13781378      </dl>
    13791379      <p id="rfc.section.5.1.2.p.18">HTTP does not place a pre-defined limit on the length of a request-target. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the 414 (URI Too Long) status if the received request-target
    1380          would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 Request-target Too Long">Section 8.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     1380         would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 8.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    13811381      </p>
    13821382      <p id="rfc.section.5.1.2.p.19">Various ad-hoc limitations on request-target length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support request-target lengths of 8000 or more OCTETs.
    … …  
    26492649      <div id="rfc.figure.u.65"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS
    26502650
    2651 <a href="#abnf.dependencies" class="smpl">Cache-Control</a> = &lt;Cache-Control, defined in [Part6], Section 3.4&gt;
     2651<a href="#abnf.dependencies" class="smpl">Cache-Control</a> = &lt;Cache-Control, defined in [Part6], Section 15.4&gt;
    26522652<a href="#chunked.transfer.encoding" class="smpl">Chunked-Body</a> = *chunk last-chunk trailer-part CRLF
    26532653<a href="#header.connection" class="smpl">Connection</a> = "Connection:" OWS Connection-v
    … …  
    26732673<a href="#rule.whitespace" class="smpl">OWS</a> = *( [ obs-fold ] WSP )
    26742674
    2675 <a href="#abnf.dependencies" class="smpl">Pragma</a> = &lt;Pragma, defined in [Part6], Section 3.4&gt;
     2675<a href="#abnf.dependencies" class="smpl">Pragma</a> = &lt;Pragma, defined in [Part6], Section 15.4&gt;
    26762676
    26772677<a href="#rule.whitespace" class="smpl">RWS</a> = 1*( [ obs-fold ] WSP )
    … …  
    27042704 ] )
    27052705
    2706 <a href="#abnf.dependencies" class="smpl">Warning</a> = &lt;Warning, defined in [Part6], Section 3.6&gt;
     2706<a href="#abnf.dependencies" class="smpl">Warning</a> = &lt;Warning, defined in [Part6], Section 15.6&gt;
    27072707
    27082708<a href="#uri" class="smpl">absolute-URI</a> = &lt;absolute-URI, defined in [RFC3986], Section 4.3&gt;

  • draft-ietf-httpbis/latest-roy/p1-messaging.xml

    r462 r500  
    44364436<x:ref>BWS</x:ref> = OWS
    44374437
    4438 <x:ref>Cache-Control</x:ref> = &lt;Cache-Control, defined in [Part6], Section 3.4&gt;
     4438<x:ref>Cache-Control</x:ref> = &lt;Cache-Control, defined in [Part6], Section 15.4&gt;
    44394439<x:ref>Chunked-Body</x:ref> = *chunk last-chunk trailer-part CRLF
    44404440<x:ref>Connection</x:ref> = "Connection:" OWS Connection-v
    … …  
    44604460<x:ref>OWS</x:ref> = *( [ obs-fold ] WSP )
    44614461
    4462 <x:ref>Pragma</x:ref> = &lt;Pragma, defined in [Part6], Section 3.4&gt;
     4462<x:ref>Pragma</x:ref> = &lt;Pragma, defined in [Part6], Section 15.4&gt;
    44634463
    44644464<x:ref>RWS</x:ref> = 1*( [ obs-fold ] WSP )
    … …  
    44914491 ] )
    44924492
    4493 <x:ref>Warning</x:ref> = &lt;Warning, defined in [Part6], Section 3.6&gt;
     4493<x:ref>Warning</x:ref> = &lt;Warning, defined in [Part6], Section 15.6&gt;
    44944494
    44954495<x:ref>absolute-URI</x:ref> = &lt;absolute-URI, defined in [RFC3986], Section 4.3&gt;

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

    r462 r500  
    468468         <tr>
    469469            <td class="header left"></td>
    470             <td class="header right">March 2, 2009</td>
     470            <td class="header right">March 4, 2009</td>
    471471         </tr>
    472472      </table>
    … …  
    592592                     <li class="tocline1">8.4.13&nbsp;&nbsp;&nbsp;<a href="#status.412">412 Precondition Failed</a></li>
    593593                     <li class="tocline1">8.4.14&nbsp;&nbsp;&nbsp;<a href="#status.413">413 Request Entity Too Large</a></li>
    594                      <li class="tocline1">8.4.15&nbsp;&nbsp;&nbsp;<a href="#status.414">414 Request-target Too Long</a></li>
     594                     <li class="tocline1">8.4.15&nbsp;&nbsp;&nbsp;<a href="#status.414">414 URI Too Long</a></li>
    595595                     <li class="tocline1">8.4.16&nbsp;&nbsp;&nbsp;<a href="#status.415">415 Unsupported Media Type</a></li>
    596596                     <li class="tocline1">8.4.17&nbsp;&nbsp;&nbsp;<a href="#status.416">416 Requested Range Not Satisfiable</a></li>
    … …  
    825825       / "412"  ; <a href="#status.412" id="rfc.xref.status.412.1" title="412 Precondition Failed">Section&nbsp;8.4.13</a>: Precondition Failed
    826826       / "413"  ; <a href="#status.413" id="rfc.xref.status.413.1" title="413 Request Entity Too Large">Section&nbsp;8.4.14</a>: Request Entity Too Large
    827        / "414"  ; <a href="#status.414" id="rfc.xref.status.414.1" title="414 Request-target Too Long">Section&nbsp;8.4.15</a>: Request-target Too Long
     827       / "414"  ; <a href="#status.414" id="rfc.xref.status.414.1" title="414 URI Too Long">Section&nbsp;8.4.15</a>: URI Too Long
    828828       / "415"  ; <a href="#status.415" id="rfc.xref.status.415.1" title="415 Unsupported Media Type">Section&nbsp;8.4.16</a>: Unsupported Media Type
    829829       / "416"  ; <a href="#status.416" id="rfc.xref.status.416.1" title="416 Requested Range Not Satisfiable">Section&nbsp;8.4.17</a>: Requested range not satisfiable
    … …  
    13861386      <div id="rfc.iref.56"></div>
    13871387      <div id="rfc.iref.s.33"></div>
    1388       <h3 id="rfc.section.8.4.15"><a href="#rfc.section.8.4.15">8.4.15</a>&nbsp;<a id="status.414" href="#status.414">414 Request-target Too Long</a></h3>
     1388      <h3 id="rfc.section.8.4.15"><a href="#rfc.section.8.4.15">8.4.15</a>&nbsp;<a id="status.414" href="#status.414">414 URI Too Long</a></h3>
    13891389      <p id="rfc.section.8.4.15.p.1">The server is refusing to service the request because the request-target is longer than the server is willing to interpret.
    13901390         This rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long
    … …  
    19041904               <tr>
    19051905                  <td>414</td>
    1906                   <td>Request-target Too Long</td>
    1907                   <td> <a href="#status.414" id="rfc.xref.status.414.2" title="414 Request-target Too Long">Section&nbsp;8.4.15</a>
     1906                  <td>URI Too Long</td>
     1907                  <td> <a href="#status.414" id="rfc.xref.status.414.2" title="414 URI Too Long">Section&nbsp;8.4.15</a>
    19081908                  </td>
    19091909               </tr>
    … …  
    22512251<a href="#abnf.dependencies" class="smpl">Accept-Language</a> = &lt;Accept-Language, defined in [Part3], Section 5.4&gt;
    22522252<a href="#abnf.dependencies" class="smpl">Accept-Ranges</a> = &lt;Accept-Ranges, defined in [Part5], Section 5.1&gt;
    2253 <a href="#abnf.dependencies" class="smpl">Age</a> = &lt;Age, defined in [Part6], Section 3.1&gt;
     2253<a href="#abnf.dependencies" class="smpl">Age</a> = &lt;Age, defined in [Part6], Section 15.1&gt;
    22542254<a href="#header.allow" class="smpl">Allow</a> = "Allow:" OWS Allow-v
    22552255<a href="#header.allow" class="smpl">Allow-v</a> = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ]
    … …  
    23122312<a href="#header.user-agent" class="smpl">User-Agent-v</a> = product *( RWS ( product / comment ) )
    23132313
    2314 <a href="#abnf.dependencies" class="smpl">Vary</a> = &lt;Vary, defined in [Part6], Section 3.5&gt;
     2314<a href="#abnf.dependencies" class="smpl">Vary</a> = &lt;Vary, defined in [Part6], Section 15.5&gt;
    23152315
    23162316WWW-Authenticate =
    … …  
    25192519                  <li class="indline1">412 Precondition Failed (status code)&nbsp;&nbsp;<a class="iref" href="#rfc.xref.status.412.1">4</a>, <a class="iref" href="#rfc.iref.54"><b>8.4.13</b></a>, <a class="iref" href="#rfc.xref.status.412.2">10.2</a></li>
    25202520                  <li class="indline1">413 Request Entity Too Large (status code)&nbsp;&nbsp;<a class="iref" href="#rfc.xref.status.413.1">4</a>, <a class="iref" href="#rfc.iref.55"><b>8.4.14</b></a>, <a class="iref" href="#rfc.xref.status.413.2">10.2</a></li>
    2521                   <li class="indline1">414 Request-target Too Long (status code)&nbsp;&nbsp;<a class="iref" href="#rfc.xref.status.414.1">4</a>, <a class="iref" href="#rfc.iref.56"><b>8.4.15</b></a>, <a class="iref" href="#rfc.xref.status.414.2">10.2</a></li>
     2521                  <li class="indline1">414 URI Too Long (status code)&nbsp;&nbsp;<a class="iref" href="#rfc.xref.status.414.1">4</a>, <a class="iref" href="#rfc.iref.56"><b>8.4.15</b></a>, <a class="iref" href="#rfc.xref.status.414.2">10.2</a></li>
    25222522                  <li class="indline1">415 Unsupported Media Type (status code)&nbsp;&nbsp;<a class="iref" href="#rfc.xref.status.415.1">4</a>, <a class="iref" href="#rfc.iref.57"><b>8.4.16</b></a>, <a class="iref" href="#rfc.xref.status.415.2">10.2</a></li>
    25232523                  <li class="indline1">416 Requested Range Not Satisfiable (status code)&nbsp;&nbsp;<a class="iref" href="#rfc.xref.status.416.1">4</a>, <a class="iref" href="#rfc.iref.58"><b>8.4.17</b></a>, <a class="iref" href="#rfc.xref.status.416.2">10.2</a></li>
    … …  
    27612761                        <li class="indline1">412 Precondition Failed&nbsp;&nbsp;<a class="iref" href="#rfc.xref.status.412.1">4</a>, <a class="iref" href="#rfc.iref.s.31"><b>8.4.13</b></a>, <a class="iref" href="#rfc.xref.status.412.2">10.2</a></li>
    27622762                        <li class="indline1">413 Request Entity Too Large&nbsp;&nbsp;<a class="iref" href="#rfc.xref.status.413.1">4</a>, <a class="iref" href="#rfc.iref.s.32"><b>8.4.14</b></a>, <a class="iref" href="#rfc.xref.status.413.2">10.2</a></li>
    2763                         <li class="indline1">414 Request-target Too Long&nbsp;&nbsp;<a class="iref" href="#rfc.xref.status.414.1">4</a>, <a class="iref" href="#rfc.iref.s.33"><b>8.4.15</b></a>, <a class="iref" href="#rfc.xref.status.414.2">10.2</a></li>
     2763                        <li class="indline1">414 URI Too Long&nbsp;&nbsp;<a class="iref" href="#rfc.xref.status.414.1">4</a>, <a class="iref" href="#rfc.iref.s.33"><b>8.4.15</b></a>, <a class="iref" href="#rfc.xref.status.414.2">10.2</a></li>
    27642764                        <li class="indline1">415 Unsupported Media Type&nbsp;&nbsp;<a class="iref" href="#rfc.xref.status.415.1">4</a>, <a class="iref" href="#rfc.iref.s.34"><b>8.4.16</b></a>, <a class="iref" href="#rfc.xref.status.415.2">10.2</a></li>
    27652765                        <li class="indline1">416 Requested Range Not Satisfiable&nbsp;&nbsp;<a class="iref" href="#rfc.xref.status.416.1">4</a>, <a class="iref" href="#rfc.iref.s.35"><b>8.4.17</b></a>, <a class="iref" href="#rfc.xref.status.416.2">10.2</a></li>

  • draft-ietf-httpbis/latest-roy/p2-semantics.xml

    r462 r500  
    556556       / "412"  ; <xref target="status.412"/>: Precondition Failed
    557557       / "413"  ; <xref target="status.413"/>: Request Entity Too Large
    558        / "414"  ; <xref target="status.414"/>: Request-target Too Long
     558       / "414"  ; <xref target="status.414"/>: URI Too Long
    559559       / "415"  ; <xref target="status.415"/>: Unsupported Media Type
    560560       / "416"  ; <xref target="status.416"/>: Requested range not satisfiable
    … …  
    16621662</section>
    16631663
    1664 <section title="414 Request-target Too Long" anchor="status.414">
    1665   <iref primary="true" item="414 Request-target Too Long (status code)" x:for-anchor=""/>
    1666   <iref primary="true" item="Status Codes" subitem="414 Request-target Too Long" x:for-anchor=""/>
     1664<section title="414 URI Too Long" anchor="status.414">
     1665  <iref primary="true" item="414 URI Too Long (status code)" x:for-anchor=""/>
     1666  <iref primary="true" item="Status Codes" subitem="414 URI Too Long" x:for-anchor=""/>
    16671667<t>
    16681668   The server is refusing to service the request because the request-target
    … …  
    24022402   </c>
    24032403   <c>414</c>
    2404    <c>Request-target Too Long</c>
     2404   <c>URI Too Long</c>
    24052405   <c>
    24062406      <xref target="status.414"/>
    … …  
    32133213<x:ref>Accept-Language</x:ref> = &lt;Accept-Language, defined in [Part3], Section 5.4&gt;
    32143214<x:ref>Accept-Ranges</x:ref> = &lt;Accept-Ranges, defined in [Part5], Section 5.1&gt;
    3215 <x:ref>Age</x:ref> = &lt;Age, defined in [Part6], Section 3.1&gt;
     3215<x:ref>Age</x:ref> = &lt;Age, defined in [Part6], Section 15.1&gt;
    32163216<x:ref>Allow</x:ref> = "Allow:" OWS Allow-v
    32173217<x:ref>Allow-v</x:ref> = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ]
    … …  
    32743274<x:ref>User-Agent-v</x:ref> = product *( RWS ( product / comment ) )
    32753275
    3276 <x:ref>Vary</x:ref> = &lt;Vary, defined in [Part6], Section 3.5&gt;
     3276<x:ref>Vary</x:ref> = &lt;Vary, defined in [Part6], Section 15.5&gt;
    32773277
    32783278WWW-Authenticate =
    … …  
    33223322</artwork></figure></section>
    33233323
    3324 
    33253324<section title="Change Log (to be removed by RFC Editor before publication)" anchor="change.log">
    33263325

  • draft-ietf-httpbis/latest-roy/p3-payload.html

    r462 r500  
    475475         <tr>
    476476            <td class="header left"></td>
    477             <td class="header right">March 2, 2009</td>
     477            <td class="header right">March 4, 2009</td>
    478478         </tr>
    479479      </table>
    … …  
    17491749<a href="#header.content-type" class="smpl">Content-Type-v</a> = media-type
    17501750
    1751 <a href="#abnf.dependencies" class="smpl">Expires</a> = &lt;Expires, defined in [Part6], Section 3.3&gt;
     1751<a href="#abnf.dependencies" class="smpl">Expires</a> = &lt;Expires, defined in [Part6], Section 15.3&gt;
    17521752
    17531753<a href="#abnf.dependencies" class="smpl">Last-Modified</a> = &lt;Last-Modified, defined in [Part4], Section 6.6&gt;

  • draft-ietf-httpbis/latest-roy/p3-payload.xml

    r462 r500  
    26672667<x:ref>Content-Type-v</x:ref> = media-type
    26682668
    2669 <x:ref>Expires</x:ref> = &lt;Expires, defined in [Part6], Section 3.3&gt;
     2669<x:ref>Expires</x:ref> = &lt;Expires, defined in [Part6], Section 15.3&gt;
    26702670
    26712671<x:ref>Last-Modified</x:ref> = &lt;Last-Modified, defined in [Part4], Section 6.6&gt;

  • draft-ietf-httpbis/latest-roy/p4-conditional.html

    r461 r500  
    464464         <tr>
    465465            <td class="header left"></td>
    466             <td class="header right">March 2, 2009</td>
     466            <td class="header right">March 4, 2009</td>
    467467         </tr>
    468468      </table>

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

    r461 r500  
    464464         <tr>
    465465            <td class="header left"></td>
    466             <td class="header right">March 2, 2009</td>
     466            <td class="header right">March 4, 2009</td>
    467467         </tr>
    468468      </table>

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

    r463 r500  
    465465         <tr>
    466466            <td class="header left"></td>
    467             <td class="header right">March 2, 2009</td>
     467            <td class="header right">March 4, 2009</td>
    468468         </tr>
    469469      </table>
    … …  
    523523         <li class="tocline0">2.&nbsp;&nbsp;&nbsp;<a href="#caching.overview">Cache Operation</a><ul class="toc">
    524524               <li class="tocline1">2.1&nbsp;&nbsp;&nbsp;<a href="#response.cacheability">Response Cacheability</a><ul class="toc">
    525                      <li class="tocline1">2.1.1&nbsp;&nbsp;&nbsp;<a href="#errors.or.incomplete.response.cache.behavior">Storing Incomplete Responses</a></li>
     525                     <li class="tocline1">2.1.1&nbsp;&nbsp;&nbsp;<a href="#errors.or.incomplete.response.cache.behavior">Storing Partial and Incomplete Responses</a></li>
    526526                  </ul>
    527527               </li>
    … …  
    529529               <li class="tocline1">2.3&nbsp;&nbsp;&nbsp;<a href="#expiration.model">Freshness Model</a><ul class="toc">
    530530                     <li class="tocline1">2.3.1&nbsp;&nbsp;&nbsp;<a href="#calculating.freshness.lifetime">Calculating Freshness Lifetime</a><ul class="toc">
    531                            <li class="tocline1">2.3.1.1&nbsp;&nbsp;&nbsp;<a href="#heuristic.freshness">Using Heuristic Freshness</a></li>
     531                           <li class="tocline1">2.3.1.1&nbsp;&nbsp;&nbsp;<a href="#heuristic.freshness">Calculating Heuristic Freshness</a></li>
    532532                        </ul>
    533533                     </li>
    … …  
    645645      </p>
    646646      <dl class="empty">
    647          <dd>A response is stale if its age has passed its freshness lifetime.</dd>
     647         <dd>A response is stale if its age has passed its freshness lifetime (either explicit or heuristic).</dd>
    648648      </dl>
    649649      <p id="rfc.section.1.2.p.10"> <span id="rfc.iref.v.1"></span>  <dfn>validator</dfn> 
    … …  
    688688      </p>
    689689      <ul>
    690          <li>the "no-store" cache directive (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.1" title="Cache-Control">Section&nbsp;3.2</a>) does not appear in request or response headers.
    691          </li>
    692          <li>the cache understands partial responses, if the response is partial or incomplete (see <a href="#errors.or.incomplete.response.cache.behavior" title="Storing Incomplete Responses">Section&nbsp;2.1.1</a>).
     690         <li>The request method is defined as being cacheable, and</li>
     691         <li>the "no-store" cache directive (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.1" title="Cache-Control">Section&nbsp;3.2</a>) does not appear in request or response headers, and
     692         </li>
     693         <li>the "private" cache response directive (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.2" title="Cache-Control">Section&nbsp;3.2</a> does not appear in the response, if the cache is a shared cache, and
     694         </li>
     695         <li>the cache understands partial responses, if the response is partial or incomplete (see <a href="#errors.or.incomplete.response.cache.behavior" title="Storing Partial and Incomplete Responses">Section&nbsp;2.1.1</a>).
    693696         </li>
    694697      </ul>
    … …  
    696699         time, as such responses are not usually useful to store. However, caches are not prohibited from storing such responses.
    697700      </p>
    698       <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 Incomplete Responses</a></h3>
    699       <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) <em class="bcp14">MAY</em> store the response <span class="comment">[rfc.comment.1: Indeed? Is this new? --JRE]</span>. However, the cache <em class="bcp14">MUST</em> treat this as a partial response <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. Partial responses <em class="bcp14">MAY</em> be combined as described in <a href="p5-range.html#combining.byte.ranges" title="Combining Ranges">Section 4</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>; the result might be a full response or might still be partial. A cache <em class="bcp14">MUST NOT</em> return a partial response to a client without explicitly marking it as such using the 206 (Partial Content) status code.
     701      <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>
     702      <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) <em class="bcp14">MAY</em> store the response. However, the cache <em class="bcp14">MUST</em> treat this as a partial response <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. Partial responses <em class="bcp14">MAY</em> be combined as described in <a href="p5-range.html#combining.byte.ranges" title="Combining Ranges">Section 4</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>; the result might be a full response or might still be partial. A cache <em class="bcp14">MUST NOT</em> return a partial response to a client without explicitly marking it as such using the 206 (Partial Content) status code.
    700703      </p>
    701704      <p id="rfc.section.2.1.1.p.2">A cache that does not support the Range and Content-Range headers <em class="bcp14">MUST NOT</em> store incomplete or partial responses.
    702705      </p>
    703706      <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>
    704       <p id="rfc.section.2.2.p.1">For a given request, a non-shared cache <em class="bcp14">MAY</em> return a stored response, provided that:
     707      <p id="rfc.section.2.2.p.1">For a presented request, a non-shared cache <em class="bcp14">MAY</em> return a stored response, provided that:
    705708      </p>
    706709      <ul>
    707          <li>the presented request-URI and that of the stored response match (see <span class="comment">[rfc.comment.2: TBD]</span>), and
    708          </li>
    709          <li>selecting headers nominated by the stored response (if any) match (see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.6</a>), and
    710          </li>
    711          <li>the stored response is either fresh (see <a href="#expiration.model" title="Freshness Model">Section&nbsp;2.3</a>) or allowed to be served stale (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;2.3.3</a>), and
    712          </li>
    713          <li>the presented request and stored response are free from directives that would prevent it (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.2" title="Cache-Control">Section&nbsp;3.2</a> and <a href="#header.pragma" id="rfc.xref.header.pragma.1" title="Pragma">Section&nbsp;3.4</a>).
     710         <li>The presented Request-URI and that of the stored response match (see <span class="comment">[rfc.comment.1: TBD]</span>), and
     711         </li>
     712         <li>the request method associated with the stored response allows it to be used for the presented request, and</li>
     713         <li>selecting request-headers nominated by the stored response (if any) match those presented (see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.6</a>), and
     714         </li>
     715         <li>the stored response is either:
     716            <ul>
     717               <li>fresh (see <a href="#expiration.model" title="Freshness Model">Section&nbsp;2.3</a>), or
     718               </li>
     719               <li>allowed to be served stale (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;2.3.3</a>), or
     720               </li>
     721               <li>successfully validated (see <a href="#validation.model" title="Validation Model">Section&nbsp;2.4</a>).
     722               </li>
     723            </ul>and
     724         </li>
     725         <li>the presented request and stored response are free from directives that would prevent its use (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.3" title="Cache-Control">Section&nbsp;3.2</a> and <a href="#header.pragma" id="rfc.xref.header.pragma.1" title="Pragma">Section&nbsp;3.4</a>).
    714726         </li>
    715727      </ul>
    716       <p id="rfc.section.2.2.p.2"> <span class="comment">[rfc.comment.3: ISSUE: This doesn't specify whether the request method is part of the cache key.]</span>
    717       </p>
    718       <p id="rfc.section.2.2.p.3">A shared cache <em class="bcp14">MAY</em> return a stored response, provided that:
     728      <p id="rfc.section.2.2.p.2">A shared cache <em class="bcp14">MAY</em> return a stored response, provided that:
    719729      </p>
    720730      <ul>
    721          <li>the criteria for non-shared caches above are met (including directives for shared caches; see <a href="#header.cache-control" id="rfc.xref.header.cache-control.3" title="Cache-Control">Section&nbsp;3.2</a>), and
    722          </li>
    723          <li>the stored response was not associated with an authenticated request (see <a href="p7-auth.html#header.authorization" title="Authorization">Section 3.1</a> of <a href="#Part7" id="rfc.xref.Part7.1"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>), unless explicitly allowed (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.4" title="Cache-Control">Section&nbsp;3.2</a>).
     731         <li>The criteria for non-shared caches above are met (taking into account directives specific to shared caches; see <a href="#header.cache-control" id="rfc.xref.header.cache-control.4" title="Cache-Control">Section&nbsp;3.2</a>), and
     732         </li>
     733         <li>the stored response was not associated with an authenticated request (see <a href="p7-auth.html#header.authorization" title="Authorization">Section 3.1</a> of <a href="#Part7" id="rfc.xref.Part7.1"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>), unless explicitly allowed (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.5" title="Cache-Control">Section&nbsp;3.2</a>).
    724734         </li>
    725735      </ul>
    726       <p id="rfc.section.2.2.p.4">All responses satisfied from cache <em class="bcp14">MUST</em> include an appropriate Age header field (<a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section&nbsp;3.1</a>).
    727       </p>
    728       <p id="rfc.section.2.2.p.5">All request methods other than GET and HEAD <em class="bcp14">MUST</em> be written through the cache to the origin server. Note that such requests might invalidate already stored responses; see <a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section&nbsp;2.5</a>.
    729       </p>
    730       <p id="rfc.section.2.2.p.6">Caches <em class="bcp14">SHOULD</em> use the most recent response (as determined by the Date header) when more than one applicable response is stored. They <em class="bcp14">MAY</em> also send a request with "Cache-Control: max-age=0" or "Cache-Control: no-cache" to disambiguate which response to use.
    731       </p>
    732       <p id="rfc.section.2.2.p.7">In the process of determining whether a stored response is fresh or not, a cache <em class="bcp14">MAY</em> validate that response (see <a href="#validation.model" title="Validation Model">Section&nbsp;2.4</a>).
     736      <p id="rfc.section.2.2.p.3"><span class="comment">[rfc.comment.2: TODO: define method cacheability for GET, HEAD and POST in p2-semantics.]</span></p>
     737      <p id="rfc.section.2.2.p.4">All responses satisfied from cache include an appropriate Age header field; see <a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section&nbsp;3.1</a>. <span class="comment">[rfc.comment.3: DISCUSS: this currently includes successfully validated responses.]</span></p>
     738      <p id="rfc.section.2.2.p.5">Request 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>) <em class="bcp14">MUST</em> be written through the cache to the origin server; i.e., A cache must not reply to such a request before having forwarded
     739         the request and having received a corresponding response.
     740      </p>
     741      <p id="rfc.section.2.2.p.6">Also, note that unsafe requests might invalidate already stored responses; see <a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section&nbsp;2.5</a>.
     742      </p>
     743      <p id="rfc.section.2.2.p.7">Caches <em class="bcp14">SHOULD</em> use the most recent response (as determined by the Date header) when more than one suitable response is stored. They <em class="bcp14">MAY</em> also forward a request with "Cache-Control: max-age=0" or "Cache-Control: no-cache" to disambiguate which response to use.
    733744      </p>
    734745      <p id="rfc.section.2.2.p.8"> <span class="comment">[rfc.comment.4: TODO: end-to-end and hop-by-hop headers, non-modifiable headers removed; re-spec in p1]</span>
    735746      </p>
    736747      <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;<a id="expiration.model" href="#expiration.model">Freshness Model</a></h2>
    737       <p id="rfc.section.2.3.p.1">HTTP caching works best when caches can entirely avoid making requests to the origin server. When a response is "fresh" in
    738          the cache, it can be used to satisfy subsequent requests without contacting the origin server. This is also referred to as
    739          "expiration."<span class="comment">[rfc.comment.5: What exactly is called 'expiration'? --JRE]</span>.
    740       </p>
    741       <p id="rfc.section.2.3.p.2">Expiration applies only to responses taken from a cache and not to first-hand responses. It cannot be used to force a user
    742          agent to refresh its display or reload a resource; its semantics apply only to caches. See <a href="#history.lists" title="History Lists">Section&nbsp;4</a> for an explanation of the difference between caches and history mechanisms.
    743       </p>
    744       <p id="rfc.section.2.3.p.3">The primary mechanism for avoiding requests is for an origin server to provide an explicit expiration time in the future,
     748      <p id="rfc.section.2.3.p.1">When a response is "fresh" in the cache, it can be used to satisfy subsequent requests without contacting the origin server,
     749         thereby improving efficiency.
     750      </p>
     751      <p id="rfc.section.2.3.p.2">The primary mechanism for determining freshness is for an origin server to provide an explicit expiration time in the future,
    745752         using either the Expires header (<a href="#header.expires" id="rfc.xref.header.expires.1" title="Expires">Section&nbsp;3.3</a>) or the max-age response cache directive (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>). Generally, origin servers will assign future explicit expiration times to responses in the belief that the entity is not
    746          likely to change in a semantically significant way before the expiration time is reached. This normally preserves cache correctness,
    747          as long as the server's expiration times are carefully chosen.
    748       </p>
    749       <p id="rfc.section.2.3.p.4">If an origin server wishes to force a cache to validate every request, it <em class="bcp14">MAY</em> assign an explicit expiration time in the past. This means that the response is always stale, so that caches should validate
    750          it before using it for subsequent requests.
    751       </p>
    752       <p id="rfc.section.2.3.p.5">Since origin servers do not always provide explicit expiration times, HTTP caches may assign heuristic expiration times when
    753          they are not specified, employing algorithms that use other header values (such as the Last-Modified time) to estimate a plausible
    754          expiration time. The HTTP/1.1 specification does not provide specific algorithms, but does impose worst-case constraints on
    755          their results.
    756       </p>
    757       <p id="rfc.section.2.3.p.6">The calculation to determine if a response has expired is:</p>
     753         likely to change in a semantically significant way before the expiration time is reached.
     754      </p>
     755      <p id="rfc.section.2.3.p.3">If an origin server wishes to force a cache to validate every request, it <em class="bcp14">MAY</em> assign an explicit expiration time in the past. This means that the response is always stale, so that caches should validate
     756         it before using it for subsequent requests. <span class="comment">[rfc.comment.5: This wording may cause confusion, because the response may still be served stale.]</span></p>
     757      <p id="rfc.section.2.3.p.4">Since origin servers do not always provide explicit expiration times, HTTP caches may also assign heuristic expiration times
     758         when they are not specified, employing algorithms that use other header values (such as the Last-Modified time) to estimate
     759         a plausible expiration time. The HTTP/1.1 specification does not provide specific algorithms, but does impose worst-case constraints
     760         on their results.
     761      </p>
     762      <p id="rfc.section.2.3.p.5">The calculation to determine if a response is fresh is:</p>
    758763      <div id="rfc.figure.u.3"></div> <pre class="text">   response_is_fresh = (freshness_lifetime &gt; current_age)
    759 </pre> <p id="rfc.section.2.3.p.8">The freshness_lifetime is defined in <a href="#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section&nbsp;2.3.1</a>; the current_age is defined in <a href="#age.calculations" title="Calculating Age">Section&nbsp;2.3.2</a>.
    760       </p>
    761       <p id="rfc.section.2.3.p.9">Additionally, clients may need to influence freshness calculation. They can do this using several request cache directives,
     764</pre> <p id="rfc.section.2.3.p.7">The freshness_lifetime is defined in <a href="#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section&nbsp;2.3.1</a>; the current_age is defined in <a href="#age.calculations" title="Calculating Age">Section&nbsp;2.3.2</a>.
     765      </p>
     766      <p id="rfc.section.2.3.p.8">Additionally, clients may need to influence freshness calculation. They can do this using several request cache directives,
    762767         with the effect of either increasing or loosening constraints on freshness. See <a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;3.2.1</a>.
     768      </p>
     769      <p id="rfc.section.2.3.p.9">Note that reshness applies only to cache operation; it cannot be used to force a user agent to refresh its display or reload
     770         a resource. See <a href="#history.lists" title="History Lists">Section&nbsp;4</a> for an explanation of the difference between caches and history mechanisms.
    763771      </p>
    764772      <p id="rfc.section.2.3.p.10"> <span class="comment">[rfc.comment.6: ISSUE: there are not requirements directly applying to cache-request-directives and freshness.]</span>
    … …  
    773781         <li>If the Expires response header (<a href="#header.expires" id="rfc.xref.header.expires.2" title="Expires">Section&nbsp;3.3</a>) is present, use its value minus the value of the Date response header, or
    774782         </li>
    775          <li>Otherwise, no explicit expiration time is present in the response, but a heuristic may be used; see <a href="#heuristic.freshness" title="Using Heuristic Freshness">Section&nbsp;2.3.1.1</a>.
     783         <li>Otherwise, no explicit expiration time is present in the response, but a heuristic may be used; see <a href="#heuristic.freshness" title="Calculating Heuristic Freshness">Section&nbsp;2.3.1.1</a>.
    776784         </li>
    777785      </ul>
    778786      <p id="rfc.section.2.3.1.p.2">Note that this calculation is not vulnerable to clock skew, since all of the information comes from the origin server.</p>
    779       <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">Using Heuristic Freshness</a></h4>
     787      <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>
    780788      <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 of 200, 203, 206, 300, 301 or 410, a
    781789         heuristic expiration time <em class="bcp14">MAY</em> be calculated. Heuristics <em class="bcp14">MUST NOT</em> be used for other response status codes.
    … …  
    794802         path from the origin server, plus the amount of time it has been in transit along network paths.
    795803      </p>
    796       <p id="rfc.section.2.3.2.p.2">When a response is generated from a stored response, the cache <em class="bcp14">MUST</em> include a single Age header field in the response with a value equal to the stored response's current_age, calculated using
     804      <p id="rfc.section.2.3.2.p.2">When a stored response is used to satisfy a request, the cache <em class="bcp14">MUST</em> include a single Age header field in the response with a value equal to the stored response's current_age, calculated using
    797805         the algorithm described in this section.
    798806      </p>
    … …  
    848856         but is not fresh according to the calculations in <a href="#expiration.model" title="Freshness Model">Section&nbsp;2.3</a>.
    849857      </p>
    850       <p id="rfc.section.2.3.3.p.2">Caches <em class="bcp14">MUST NOT</em> return a stale response if it is prohibited by an explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache
     858      <p id="rfc.section.2.3.3.p.2">Caches <em class="bcp14">MAY</em> return a stale response if disconnected or explicitly allowed (e.g., the max-stale request directive; see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;3.2.1</a>).
     859      </p>
     860      <p id="rfc.section.2.3.3.p.3">Otherwise, caches <em class="bcp14">SHOULD NOT</em> return stale responses.
     861      </p>
     862      <p id="rfc.section.2.3.3.p.4">Caches <em class="bcp14">MUST NOT</em> return a stale response if it is prohibited by an explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache
    851863         directive, a "must-revalidate" cache-response-directive, or an applicable "s-maxage" or "proxy-revalidate" cache-response-directive;
    852864         see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>).
    853865      </p>
    854       <p id="rfc.section.2.3.3.p.3">Caches <em class="bcp14">MAY</em> return a stale response if disconnected or explicitly allowed (e.g., the max-stale request directive; see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;3.2.1</a>).
    855       </p>
    856       <p id="rfc.section.2.3.3.p.4">Otherwise, caches <em class="bcp14">SHOULD NOT</em> return stale responses.
    857       </p>
    858866      <p id="rfc.section.2.3.3.p.5">Stale responses <em class="bcp14">SHOULD</em> have a Warning header with the 110 warn-code (see <a href="#header.warning" id="rfc.xref.header.warning.1" title="Warning">Section&nbsp;3.6</a>).
    859867      </p>
    … …  
    862870      </p>
    863871      <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>
    864       <p id="rfc.section.2.4.p.1">When a cache has a stale response that it would like to use, it <em class="bcp14">SHOULD</em> first check with the origin server (or possibly an intermediate cache with a fresh response) to see if it is still usable.
    865          This is called "validating" or "revalidating" the stored response.
    866       </p>
    867       <p id="rfc.section.2.4.p.2">HTTP's conditional request mechanism, defined in <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, is used to avoid retransmitting the response payload when the stored response is valid. When a stored response includes
    868          one or more "cache validators", such as the field values of an ETag or Last-Modified header field, then a validating GET request <em class="bcp14">SHOULD</em> be made conditional to those field values. The server checks the conditional request's validator against the current state
    869          of the requested resource and, if they match, the server responds with a 304 (Not Modified) status code to indicate that the
    870          stored response can be refreshed and reused without retransmitting the response payload. If the validator does not match the
    871          current state of the requested resource, then the server returns a full response, including payload, so that the request can
    872          be satisfied and the stored response supplanted without the need for an additional network round-trip.
    873       </p>
    874       <p id="rfc.section.2.4.p.3">See <a href="#combining.headers" title="Combining Responses">Section&nbsp;2.7</a> regarding combining cached headers with those in a 304 response.
    875       </p>
    876       <p id="rfc.section.2.4.p.4">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 received response unless the stored response includes the "must-revalidate" cache directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>).
     872      <p id="rfc.section.2.4.p.1">Checking with the origin server to see if a stale or otherwise unusable cached response can be reused is called "validating"
     873         or "revalidating." Doing so potentially avoids the overhead of retransmitting the response body when the stored response is
     874         valid.
     875      </p>
     876      <p id="rfc.section.2.4.p.2">HTTP's conditional request mechanism <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a> is used for this purpose. When a stored response includes one or more validators, such as the field values of an ETag or Last-Modified
     877         header field, then a validating request <em class="bcp14">SHOULD</em> be made conditional to those field values.
     878      </p>
     879      <p id="rfc.section.2.4.p.3">A 304 (Not Modified) response status code indicates that the stored response can be updated and reused; see <a href="#combining.headers" title="Combining Responses">Section&nbsp;2.7</a>.
     880      </p>
     881      <p id="rfc.section.2.4.p.4">If instead the cache receives a full response (i.e., one with a response body), it is used to satisfy the request and replace
     882         the stored response. <span class="comment">[rfc.comment.8: Should there be a requirement here?]</span></p>
     883      <p id="rfc.section.2.4.p.5">If a cache receives a 5xx response while attempting to validate a response, it <em class="bcp14">MAY</em> either forward this response to the requesting client, or act as if the server failed to respond. In the latter case, it <em class="bcp14">MAY</em> return a previously stored response unless the stored response includes the "must-revalidate" cache directive (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;2.3.3</a>).
    877884      </p>
    878885      <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>
    879       <p id="rfc.section.2.5.p.1">Because unsafe methods <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> have the potential for changing state on the origin server, intervening caches have the opportunity to use them to keep their
    880          contents up-to-date.
     886      <p id="rfc.section.2.5.p.1">Because unsafe methods (<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>) have the potential for changing state on the origin server, intervening caches can use them to keep their contents up-to-date.
    881887      </p>
    882888      <p id="rfc.section.2.5.p.2">The following HTTP methods <em class="bcp14">MUST</em> cause a cache to invalidate the Request-URI as well as the Location and Content-Location headers (if present):
    … …  
    890896         attacks.
    891897      </p>
    892       <p id="rfc.section.2.5.p.4"> <span class="comment">[rfc.comment.8: TODO: "host part" needs to be specified better.]</span>
     898      <p id="rfc.section.2.5.p.4"> <span class="comment">[rfc.comment.9: TODO: "host part" needs to be specified better.]</span>
    893899      </p>
    894900      <p id="rfc.section.2.5.p.5">A cache that passes through requests for methods it does not understand <em class="bcp14">SHOULD</em> invalidate the Request-URI.
    … …  
    900906         change at the origin server might not have gone through the cache where a response is stored.
    901907      </p>
    902       <p id="rfc.section.2.5.p.8"> <span class="comment">[rfc.comment.9: TODO: specify that only successful (2xx, 3xx?) responses invalidate.]</span>
     908      <p id="rfc.section.2.5.p.8"> <span class="comment">[rfc.comment.10: TODO: specify that only successful (2xx, 3xx?) responses invalidate.]</span>
    903909      </p>
    904910      <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a>&nbsp;<a id="caching.negotiated.responses" href="#caching.negotiated.responses">Caching Negotiated Responses</a></h2>
    905       <p id="rfc.section.2.6.p.1">Use of server-driven content negotiation (<a href="p3-payload.html#server-driven.negotiation" title="Server-driven Negotiation">Section 4.1</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), as indicated by the presence of a Vary header field (<a href="#header.vary" id="rfc.xref.header.vary.1" title="Vary">Section&nbsp;3.5</a>) in a response, alters the conditions and procedure by which a cache can use the response for subsequent requests.
    906       </p>
    907       <p id="rfc.section.2.6.p.2">When the cache receives a subsequent request which may be satisfied by a stored responses that include a Vary header field,
    908          it <em class="bcp14">MUST NOT</em> use it to satisfy the request unless all of the selecting request-headers present in the new request match the corresponding
    909          stored request-headers from the original request.
     911      <p id="rfc.section.2.6.p.1">Use of server-driven content negotiation (<a href="p3-payload.html#server-driven.negotiation" title="Server-driven Negotiation">Section 4.1</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) alters the conditions and procedure by which a cache can use the response for subsequent requests.
     912      </p>
     913      <p id="rfc.section.2.6.p.2">When the cache receives a request which may be satisfied by a stored response that includes a Vary header field <a href="#header.vary" id="rfc.xref.header.vary.1" title="Vary">Section&nbsp;3.5</a>, it <em class="bcp14">MUST NOT</em> use the stored response to satisfy the request unless all of the selecting request-headers present in the new request match
     914         the corresponding stored request-headers from the original request.
    910915      </p>
    911916      <p id="rfc.section.2.6.p.3">The selecting request-headers from two requests are defined to match if and only if the selecting request-headers in the first
    912          request can be transformed to the selecting request-headers in the second request by adding or removing linear white space <span class="comment">[rfc.comment.10: [ref]]</span> at places where this is allowed by the corresponding ABNF, and/or combining multiple message-header fields with the same field
    913          name following the rules about message headers in <a href="p1-messaging.html#message.headers" title="Message Headers">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
    914       </p>
    915       <p id="rfc.section.2.6.p.4">A Vary header field-value of "*" always fails to match, and subsequent requests on that resource can only be properly interpreted
     917         request can be transformed to the selecting request-headers in the second request by adding or removing linear white space <span class="comment">[rfc.comment.11: [ref]]</span> at places where this is allowed by the corresponding ABNF, and/or combining multiple message-header fields with the same field
     918         name following the rules about message headers in <a href="p1-messaging.html#message.headers" title="Message Headers">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. <span class="comment">[rfc.comment.12: DISCUSS: header-specific canonicalisation]</span></p>
     919      <p id="rfc.section.2.6.p.4">A Vary header field-value of "*" always fails to match, and subsequent requests to that resource can only be properly interpreted
    916920         by the origin server.
    917921      </p>
    918       <p id="rfc.section.2.6.p.5">If the selecting request header fields for the stored response do not match the selecting request header fields of the new
    919          request, then the cache <em class="bcp14">MUST NOT</em> use the stored response to satisfy the request unless it first relays the new request to the origin server in a conditional
    920          request and the server responds with 304 (Not Modified), including an entity tag or Content-Location that indicates the entity
    921          to be used.
    922       </p>
    923       <p id="rfc.section.2.6.p.6">If one or more applicable stored response has an entity tag, the forwarded request <em class="bcp14">SHOULD</em> be conditional and include all of these entity tags in an If-None-Match header field. This conveys to the server the set of
    924          entities currently stored by the cache, so that if any one of these entities matches the requested entity, the server can
    925          use the ETag header field in its 304 (Not Modified) response to tell the cache which stored response is appropriate. If the
    926          entity-tag of the new response matches that of an existing stored resopnse, the new response <em class="bcp14">SHOULD</em> be used to update its header fields, and the result <em class="bcp14">MUST</em> be returned to the client.
    927       </p>
    928       <p id="rfc.section.2.6.p.7">If any of the existing stored responses contains only partial content for the associated entity, its entity-tag <em class="bcp14">SHOULD NOT</em> be included in the If-None-Match header field unless the request is for a range that would be fully satisfied by that stored
     922      <p id="rfc.section.2.6.p.5">If no stored response matches, the cache <em class="bcp14">MAY</em> forward the presented request to the origin server in a conditional request, which <em class="bcp14">SHOULD</em> include all ETags stored with potentially suitable responses in an If-None-Match request header. If the server responds with
     923         304 (Not Modified) and includes an entity tag or Content-Location that indicates the entity to be used, that cached response <em class="bcp14">MUST</em> be used to satisfy the presented request, and <em class="bcp14">SHOULD</em> be used to update the corresponding stored response; see <a href="#combining.headers" title="Combining Responses">Section&nbsp;2.7</a>.
     924      </p>
     925      <p id="rfc.section.2.6.p.6">If any of the stored responses contains only partial content, its entity-tag <em class="bcp14">SHOULD NOT</em> be included in the If-None-Match header field unless the request is for a range that would be fully satisfied by that stored
    929926         response.
    930927      </p>
    931       <p id="rfc.section.2.6.p.8">If a cache receives a successful response whose Content-Location field matches that of an existing stored response for the
     928      <p id="rfc.section.2.6.p.7">If a cache receives a successful response whose Content-Location field matches that of an existing stored response for the
    932929         same Request-URI, whose entity-tag differs from that of the existing stored response, and whose Date is more recent than that
    933          of the existing response, the existing response <em class="bcp14">SHOULD NOT</em> be returned in response to future requests and <em class="bcp14">SHOULD</em> be deleted from the cache.
    934       </p>
    935       <p id="rfc.section.2.6.p.9"> <span class="comment">[rfc.comment.11: TODO: this still needs work.]</span>
    936       </p>
     930         of the existing response, the existing response <em class="bcp14">SHOULD NOT</em> be returned in response to future requests and <em class="bcp14">SHOULD</em> be deleted from the cache.<span class="comment">[rfc.comment.13: DISCUSS: Not sure if this is necessary.]</span></p>
    937931      <h2 id="rfc.section.2.7"><a href="#rfc.section.2.7">2.7</a>&nbsp;<a id="combining.headers" href="#combining.headers">Combining Responses</a></h2>
    938932      <p id="rfc.section.2.7.p.1">When a cache receives a 304 (Not Modified) response or a 206 (Partial Content) response, it needs to update the stored response
    … …  
    956950         such old headers <em class="bcp14">MUST</em> be replaced. it <em class="bcp14">MAY</em> store the combined entity-body.
    957951      </p>
    958       <p id="rfc.section.2.7.p.5"><span class="comment">[rfc.comment.12: ISSUE: discuss how to handle HEAD updates]</span></p>
     952      <p id="rfc.section.2.7.p.5"><span class="comment">[rfc.comment.14: ISSUE: discuss how to handle HEAD updates]</span></p>
    959953      <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>
    960954      <p id="rfc.section.3.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to caching.</p>
    … …  
    14051399                  <td>http</td>
    14061400                  <td>standard</td>
    1407                   <td> <a href="#header.cache-control" id="rfc.xref.header.cache-control.5" title="Cache-Control">Section&nbsp;3.2</a>
     1401                  <td> <a href="#header.cache-control" id="rfc.xref.header.cache-control.6" title="Cache-Control">Section&nbsp;3.2</a>
    14081402                  </td>
    14091403               </tr>
    … …  
    15421536      <h1 id="rfc.section.A"><a href="#rfc.section.A">A.</a>&nbsp;<a id="compatibility" href="#compatibility">Compatibility with Previous Versions</a></h1>
    15431537      <h2 id="rfc.section.A.1"><a href="#rfc.section.A.1">A.1</a>&nbsp;<a id="changes.from.rfc.2068" href="#changes.from.rfc.2068">Changes from RFC 2068</a></h2>
    1544       <p id="rfc.section.A.1.p.1">A case was missed in the Cache-Control model of HTTP/1.1; s-maxage was introduced to add this missing case. (Sections <a href="#response.cacheability" title="Response Cacheability">2.1</a>, <a href="#header.cache-control" id="rfc.xref.header.cache-control.6" title="Cache-Control">3.2</a>).
     1538      <p id="rfc.section.A.1.p.1">A case was missed in the Cache-Control model of HTTP/1.1; s-maxage was introduced to add this missing case. (Sections <a href="#response.cacheability" title="Response Cacheability">2.1</a>, <a href="#header.cache-control" id="rfc.xref.header.cache-control.7" title="Cache-Control">3.2</a>).
    15451539      </p>
    15461540      <p id="rfc.section.A.1.p.2">Transfer-coding and message lengths all interact in ways that required fixing exactly when chunked encoding is used (to allow
    … …  
    15531547      </p>
    15541548      <p id="rfc.section.A.1.p.5">The Cache-Control: max-age directive was not properly defined for responses.</p>
    1555       <p id="rfc.section.A.1.p.6">Warnings could be cached incorrectly, or not updated appropriately. <a href="#expiration.model" title="Freshness Model">2.3</a>, <a href="#combining.headers" title="Combining Responses">2.7</a>, <a href="#header.cache-control" id="rfc.xref.header.cache-control.7" title="Cache-Control">3.2</a>, and <a href="#header.warning" id="rfc.xref.header.warning.4" title="Warning">3.6</a>) Warning also needed to be a general header, as PUT or other methods may have need for it in requests.
     1549      <p id="rfc.section.A.1.p.6">Warnings could be cached incorrectly, or not updated appropriately. <a href="#expiration.model" title="Freshness Model">2.3</a>, <a href="#combining.headers" title="Combining Responses">2.7</a>, <a href="#header.cache-control" id="rfc.xref.header.cache-control.8" title="Cache-Control">3.2</a>, and <a href="#header.warning" id="rfc.xref.header.warning.4" title="Warning">3.6</a>) Warning also needed to be a general header, as PUT or other methods may have need for it in requests.
    15561550      </p>
    15571551      <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a>&nbsp;<a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2>
    … …  
    17181712                     </ul>
    17191713                  </li>
    1720                   <li class="indline1">Cache-Control header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.cache-control.1">2.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.2">2.2</a>, <a class="iref" href="#rfc.xref.header.cache-control.3">2.2</a>, <a class="iref" href="#rfc.xref.header.cache-control.4">2.2</a>, <a class="iref" href="#rfc.iref.c.3"><b>3.2</b></a>, <a class="iref" href="#rfc.xref.header.cache-control.5">5.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.6">A.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.7">A.1</a></li>
     1714                  <li class="indline1">Cache-Control header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.cache-control.1">2.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.2">2.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.3">2.2</a>, <a class="iref" href="#rfc.xref.header.cache-control.4">2.2</a>, <a class="iref" href="#rfc.xref.header.cache-control.5">2.2</a>, <a class="iref" href="#rfc.iref.c.3"><b>3.2</b></a>, <a class="iref" href="#rfc.xref.header.cache-control.6">5.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.7">A.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.8">A.1</a></li>
    17211715                  <li class="indline1">cacheable&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.2">1.2</a></li>
    17221716               </ul>
    … …  
    17671761                     <ul class="ind">
    17681762                        <li class="indline1">Age&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.age.1">2.2</a>, <a class="iref" href="#rfc.iref.h.2"><b>3.1</b></a>, <a class="iref" href="#rfc.xref.header.age.2">5.1</a></li>
    1769                         <li class="indline1">Cache-Control&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.cache-control.1">2.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.2">2.2</a>, <a class="iref" href="#rfc.xref.header.cache-control.3">2.2</a>, <a class="iref" href="#rfc.xref.header.cache-control.4">2.2</a>, <a class="iref" href="#rfc.iref.h.3"><b>3.2</b></a>, <a class="iref" href="#rfc.xref.header.cache-control.5">5.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.6">A.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.7">A.1</a></li>
     1763                        <li class="indline1">Cache-Control&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.cache-control.1">2.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.2">2.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.3">2.2</a>, <a class="iref" href="#rfc.xref.header.cache-control.4">2.2</a>, <a class="iref" href="#rfc.xref.header.cache-control.5">2.2</a>, <a class="iref" href="#rfc.iref.h.3"><b>3.2</b></a>, <a class="iref" href="#rfc.xref.header.cache-control.6">5.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.7">A.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.8">A.1</a></li>
    17701764                        <li class="indline1">Expires&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.expires.1">2.3</a>, <a class="iref" href="#rfc.xref.header.expires.2">2.3.1</a>, <a class="iref" href="#rfc.iref.h.4"><b>3.3</b></a>, <a class="iref" href="#rfc.xref.header.expires.3">5.1</a></li>
    17711765                        <li class="indline1">Pragma&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.pragma.1">2.2</a>, <a class="iref" href="#rfc.xref.header.pragma.2">3.2</a>, <a class="iref" href="#rfc.iref.h.5"><b>3.4</b></a>, <a class="iref" href="#rfc.xref.header.pragma.3">5.1</a></li>
    … …  
    18411835                     </ul>
    18421836                  </li>
    1843                   <li class="indline1"><em>Part2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">2.5</a>, <a class="iref" href="#Part2"><b>8.1</b></a><ul class="ind">
    1844                         <li class="indline1"><em>Section 7.1.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">2.5</a></li>
     1837                  <li class="indline1"><em>Part2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">2.2</a>, <a class="iref" href="#rfc.xref.Part2.2">2.5</a>, <a class="iref" href="#Part2"><b>8.1</b></a><ul class="ind">
     1838                        <li class="indline1"><em>Section 7.1.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">2.2</a>, <a class="iref" href="#rfc.xref.Part2.2">2.5</a></li>
    18451839                     </ul>
    18461840                  </li>

  • draft-ietf-httpbis/latest-roy/p7-auth.html

    r461 r500  
    462462         <tr>
    463463            <td class="header left"></td>
    464             <td class="header right">March 2, 2009</td>
     464            <td class="header right">March 4, 2009</td>
    465465         </tr>
    466466      </table>
Note: See TracChangeset for help on using the changeset viewer.