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

Timestamp:

Dec 8, 2012, 12:20:18 AM (7 years ago)

Author:

fielding@…

Message:

update generated abnf and html; done for the night

File:

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

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

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires June 10, 2013"; 
+       content: "Expires June 11, 2013"; 
   } 
   @bottom-right {
@@ -491 +491 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2012-12-07">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-12-08">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false.">
@@ -517 +517 @@
             </tr>
             <tr>
-               <td class="left">Expires: June 10, 2013</td>
-               <td class="right">December 7, 2012</td>
+               <td class="left">Expires: June 11, 2013</td>
+               <td class="right">December 8, 2012</td>
             </tr>
          </tbody>
@@ -545 +545 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on June 10, 2013.</p>
+      <p>This Internet-Draft will expire on June 11, 2013.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -1057 +1057 @@
       <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="status.304" href="#status.304">304 Not Modified</a></h2>
       <p id="rfc.section.4.1.p.1">The 304 status code indicates that a conditional GET request has been received and would have resulted in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response if it were not for the fact that the condition has evaluated to false. In other words, there is no need for the server
-         to transfer a representation of the target resource because the client's request indicates that it already has a valid representation,
-         as indicated by the 304 response header fields, and is therefore redirecting the client to make use of that stored representation
-         as if it were the payload of a 200 response. The 304 response <em class="bcp14">MUST NOT</em> contain a message-body, and thus is always terminated by the first empty line after the header fields.
-      </p>
-      <p id="rfc.section.4.1.p.2">A 304 response <em class="bcp14">MUST</em> include a <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field (<a href="p2-semantics.html#header.date" title="Date">Section 8.1.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) unless the origin server does not have a clock that can provide a reasonable approximation of the current time. If a <a href="p2-semantics.html#status.200" class="smpl">200
+         to transfer a representation of the target resource because the request indicates that the client which made the request conditional
+         already has a valid representation; the server is therefore redirecting that client to make use of that stored representation
+         as if it were the payload of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response.
+      </p>
+      <p id="rfc.section.4.1.p.2">The 304 response <em class="bcp14">MUST NOT</em> contain a message-body, and thus is always terminated by the first empty line after the header fields.
+      </p>
+      <p id="rfc.section.4.1.p.3">A 304 response <em class="bcp14">MUST</em> include a <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field (<a href="p2-semantics.html#header.date" title="Date">Section 8.1.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) unless the origin server does not have a clock that can provide a reasonable approximation of the current time. If a <a href="p2-semantics.html#status.200" class="smpl">200
             (OK)</a> response to the same request would have included any of the header fields <a href="p6-cache.html#header.cache-control" class="smpl">Cache-Control</a>, <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a>, <a href="#header.etag" class="smpl">ETag</a>, <a href="p6-cache.html#header.expires" class="smpl">Expires</a>, or <a href="p2-semantics.html#header.vary" class="smpl">Vary</a>, then those same header fields <em class="bcp14">MUST</em> be sent in a 304 response.
       </p>
-      <p id="rfc.section.4.1.p.3">Since the goal of a 304 response is to minimize information transfer when the recipient already has one or more cached representations,
+      <p id="rfc.section.4.1.p.4">Since the goal of a 304 response is to minimize information transfer when the recipient already has one or more cached representations,
          the response <em class="bcp14">SHOULD NOT</em> include representation metadata other than the above listed fields unless said metadata exists for the purpose of guiding
          cache updates (e.g., future HTTP extensions).
       </p>
-      <p id="rfc.section.4.1.p.4">If the recipient of a 304 response does not have a cached representation corresponding to the entity-tag indicated by the
+      <p id="rfc.section.4.1.p.5">If the recipient of a 304 response does not have a cached representation corresponding to the entity-tag indicated by the
          304 response, then the recipient <em class="bcp14">MUST NOT</em> use the 304 to update its own cache. If this conditional request originated with an outbound client, such as a user agent
          with its own cache sending a conditional GET to a shared proxy, then the 304 response <em class="bcp14">MAY</em> be forwarded to that client. Otherwise, the recipient <em class="bcp14">MUST</em> disregard the 304 response and repeat the request without any preconditions.
       </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 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.
       </p>
       <div id="rfc.iref.21"></div>
@@ -1330 +1332 @@
 <a href="#header.last-modified" class="smpl">Last-Modified</a> = HTTP-date
 
-<a href="#imported.abnf" class="smpl">OWS</a> = &lt;OWS, defined in [Part1], Section 3.2.1&gt;
+<a href="#imported.abnf" class="smpl">OWS</a> = &lt;OWS, defined in [Part1], Section 3.2.3&gt;
 
 <a href="#header.etag" class="smpl">entity-tag</a> = [ weak ] opaque-tag
@@ -1336 +1338 @@
  / obs-text
 
-<a href="#imported.abnf" class="smpl">obs-text</a> = &lt;obs-text, defined in [Part1], Section 3.2.4&gt;
+<a href="#imported.abnf" class="smpl">obs-text</a> = &lt;obs-text, defined in [Part1], Section 3.2.6&gt;
 <a href="#header.etag" class="smpl">opaque-tag</a> = DQUOTE *etagc DQUOTE