Ignore:
Timestamp:
14/09/13 21:35:28 (7 years ago)
Author:
fielding@…
Message:

clarify requirements on non-GMT dates and updating stored GET responses with a HEAD response; addresses #475

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

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p6-cache.html

    r2393 r2397  
    919919         <li>Cache recipients <em class="bcp14">MUST NOT</em> allow local time zones to influence the calculation or comparison of an age or expiration time.
    920920         </li>
    921          <li>Cache recipients <em class="bcp14">SHOULD</em> consider a date with a zone abbreviation other than "GMT" to be invalid for calculating expiration.
     921         <li>Cache recipients <em class="bcp14">SHOULD</em> consider a date with a zone abbreviation other than GMT or UTC to be invalid for calculating expiration.
    922922         </li>
    923923      </ul>
     
    11351135         representation body is not desired even if it has changed.
    11361136      </p>
    1137       <p id="rfc.section.4.3.5.p.2">If one or more stored GET responses can be selected (as per <a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section&nbsp;4.1</a>) for a HEAD request, and the <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a>, <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> or <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> value of a HEAD response differs from that in a selected GET response, the cache <em class="bcp14">MUST</em> consider that selected response to be stale.
    1138       </p>
    1139       <p id="rfc.section.4.3.5.p.3">If the <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a>, <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> and <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> values of a HEAD response (when present) are the same as that in a selected GET response (as per <a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section&nbsp;4.1</a>), the cache <em class="bcp14">SHOULD</em> update the remaining header fields in the stored response using the following rules:
     1137      <p id="rfc.section.4.3.5.p.2">When a cache makes an inbound HEAD request for a given request target and receives a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response, the cache <em class="bcp14">SHOULD</em> update or invalidate each of its stored GET responses that could have been selected for that request (see <a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section&nbsp;4.1</a>).
     1138      </p>
     1139      <p id="rfc.section.4.3.5.p.3">For each of the stored responses that could have been selected, if the stored response and HEAD response have matching values
     1140         for any received validator fields (<a href="p4-conditional.html#header.etag" class="smpl">ETag</a> and <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a>) and, if the HEAD response has a <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> header field, the value of <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> matches that of the stored response, the cache <em class="bcp14">SHOULD</em> update the stored response a described below; otherwise, the cache <em class="bcp14">SHOULD</em> consider the stored response to be stale.
     1141      </p>
     1142      <p id="rfc.section.4.3.5.p.4">If a cache updates a stored response with the metadata provided in a HEAD response, the cache <em class="bcp14">MUST</em>:
    11401143      </p>
    11411144      <ul>
     
    11451148         </li>
    11461149         <li>use other header fields provided in the HEAD response to replace all instances of the corresponding header fields in the stored
    1147             response.
     1150            response and append new header fields to the stored response's header section unless otherwise restricted by the <a href="#header.cache-control" class="smpl">Cache-Control</a> header field.
    11481151         </li>
    11491152      </ul>
  • draft-ietf-httpbis/latest/p6-cache.xml

    r2393 r2397  
    606606
    607607     <t>Cache recipients &SHOULD; consider a date with a zone abbreviation
    608         other than "GMT" to be invalid for calculating expiration.</t>
     608        other than GMT or UTC to be invalid for calculating expiration.</t>
    609609  </list>
    610610</t>
     
    10701070</t>
    10711071<t>
    1072    If one or more stored GET responses can be selected (as per <xref
    1073    target="caching.negotiated.responses"/>) for a HEAD request, and the
    1074    <x:ref>Content-Length</x:ref>, <x:ref>ETag</x:ref> or
    1075    <x:ref>Last-Modified</x:ref> value of a HEAD response differs from that in a
    1076    selected GET response, the cache &MUST; consider that selected response to
    1077    be stale.
    1078 </t>
    1079 <t>
    1080    If the <x:ref>Content-Length</x:ref>, <x:ref>ETag</x:ref> and
    1081    <x:ref>Last-Modified</x:ref> values of a HEAD response (when present) are
    1082    the same as that in a selected GET response (as per
    1083    <xref target="caching.negotiated.responses"/>), the cache &SHOULD; update
    1084    the remaining header fields in the stored response using the following
    1085    rules:
     1072   When a cache makes an inbound HEAD request for a given request target and
     1073   receives a <x:ref>200 (OK)</x:ref> response, the cache &SHOULD; update or
     1074   invalidate each of its stored GET responses that could have been selected
     1075   for that request (see <xref target="caching.negotiated.responses"/>).
     1076</t>
     1077<t>
     1078   For each of the stored responses that could have been selected, if the
     1079   stored response and HEAD response have matching values for any received
     1080   validator fields (<x:ref>ETag</x:ref> and <x:ref>Last-Modified</x:ref>)
     1081   and, if the HEAD response has a <x:ref>Content-Length</x:ref> header field,
     1082   the value of <x:ref>Content-Length</x:ref> matches that of the stored
     1083   response, the cache &SHOULD; update the stored response a described below;
     1084   otherwise, the cache &SHOULD; consider the stored response to be stale.
     1085</t>
     1086<t>
     1087   If a cache updates a stored response with the metadata provided in a HEAD
     1088   response, the cache &MUST;:
    10861089   <list style="symbols">
    10871090      <t>delete any <x:ref>Warning</x:ref> header fields in the stored response
     
    10891092      <t>retain any <x:ref>Warning</x:ref> header fields in the stored response
    10901093         with warn-code 2xx; and,</t>
    1091       <t>use other header fields provided in the HEAD response to replace
    1092          all instances of the corresponding header fields in the stored
    1093          response.</t>
     1094      <t>use other header fields provided in the HEAD response to replace all
     1095         instances of the corresponding header fields in the stored response
     1096         and append new header fields to the stored response's header section
     1097         unless otherwise restricted by the <x:ref>Cache-Control</x:ref>
     1098         header field.</t>
    10941099   </list>
    10951100</t>
Note: See TracChangeset for help on using the changeset viewer.