Ignore:
Timestamp:
Aug 5, 2008, 1:04:23 PM (11 years ago)
Author:
julian.reschke@…
Message:

Outdent comment about Date handling (this gets the list format closer to the intended format, see <http://www.w3.org/Protocols/HTTP/1.1/rfc2616.pdf>)

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p4-conditional.html

    r302 r305  
    473473         <tr>
    474474            <td class="header left"></td>
    475             <td class="header right">August 1, 2008</td>
     475            <td class="header right">August 5, 2008</td>
    476476         </tr>
    477477      </table>
     
    611611      </p>
    612612      <ul>
    613          <li>Date, unless its omission is required by <a href="p1-messaging.html#clockless.origin.server.operation" title="Clockless Origin Server Operation">Section 8.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></li>
    614       </ul>
    615       <p id="rfc.section.4.1.p.3">If a clockless origin server obeys these rules, and proxies and clients add their own Date to any response received without
    616          one (as already specified by <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, <a href="http://tools.ietf.org/html/rfc2068#section-14.19">Section 14.19</a>), caches will operate correctly.
    617       </p>
    618       <ul>
    619          <li>ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request</li>
    620          <li>Expires, Cache-Control, and/or Vary, if the field-value might differ from that sent in any previous response for the same
    621             variant
    622          </li>
    623       </ul>
    624       <p id="rfc.section.4.1.p.4">If the conditional GET used a strong cache validator (see <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section&nbsp;5</a>), the response <em class="bcp14">SHOULD NOT</em> include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response <em class="bcp14">MUST NOT</em> include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers.
    625       </p>
    626       <p id="rfc.section.4.1.p.5">If a 304 response indicates an entity not currently cached, then the cache <em class="bcp14">MUST</em> disregard the response and repeat the request without the conditional.
    627       </p>
    628       <p id="rfc.section.4.1.p.6">If a cache uses a received 304 response to update a cache entry, the cache <em class="bcp14">MUST</em> update the entry to reflect any new field values given in the response.
     613         <li>
     614            <p>Date, unless its omission is required by <a href="p1-messaging.html#clockless.origin.server.operation" title="Clockless Origin Server Operation">Section 8.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></p>
     615            <p>If a clockless origin server obeys these rules, and proxies and clients add their own Date to any response received without
     616               one (as already specified by <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, <a href="http://tools.ietf.org/html/rfc2068#section-14.19">Section 14.19</a>), caches will operate correctly.
     617            </p>
     618         </li>
     619         <li>
     620            <p>ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request</p>
     621         </li>
     622         <li>
     623            <p>Expires, Cache-Control, and/or Vary, if the field-value might differ from that sent in any previous response for the same
     624               variant
     625            </p>
     626         </li>
     627      </ul>
     628      <p id="rfc.section.4.1.p.3">If the conditional GET used a strong cache validator (see <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section&nbsp;5</a>), the response <em class="bcp14">SHOULD NOT</em> include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response <em class="bcp14">MUST NOT</em> include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers.
     629      </p>
     630      <p id="rfc.section.4.1.p.4">If a 304 response indicates an entity not currently cached, then the cache <em class="bcp14">MUST</em> disregard the response and repeat the request without the conditional.
     631      </p>
     632      <p id="rfc.section.4.1.p.5">If a cache uses a received 304 response to update a cache entry, the cache <em class="bcp14">MUST</em> update the entry to reflect any new field values given in the response.
    629633      </p>
    630634      <div id="rfc.iref.4"></div>
Note: See TracChangeset for help on using the changeset viewer.