Changeset 305 for draft-ietf-httpbis/latest/p4-conditional.html

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:

• draft-ietf-httpbis/latest/p4-conditional.html (modified) (2 diffs)

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

@@ -473 +473 @@
          <tr>
             <td class="header left"></td>
-            <td class="header right">August 1, 2008</td>
+            <td class="header right">August 5, 2008</td>
          </tr>
       </table>
@@ -611 +611 @@
       </p>
       <ul>
-         <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>
-      </ul>
-      <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
-         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. 
-      </p>
-      <ul>
-         <li>ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request</li>
-         <li>Expires, Cache-Control, and/or Vary, if the field-value might differ from that sent in any previous response for the same
-            variant
-         </li>
-      </ul>
-      <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.
-      </p>
-      <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.
-      </p>
-      <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.
+         <li>
+            <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>
+            <p>If a clockless origin server obeys these rules, and proxies and clients add their own Date to any response received without
+               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.
+            </p>
+         </li>
+         <li>
+            <p>ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request</p>
+         </li>
+         <li>
+            <p>Expires, Cache-Control, and/or Vary, if the field-value might differ from that sent in any previous response for the same
+               variant
+            </p>
+         </li>
+      </ul>
+      <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.
+      </p>
+      <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.
+      </p>
+      <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.
       </p>
       <div id="rfc.iref.4"></div>