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

Timestamp:

04/07/12 19:54:55 (9 years ago)

Author:

julian.reschke@…

Message:

Work-in-progress: hyperlink status codes definitions (2xx range)

File:

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

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

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires January 4, 2013"; 
+       content: "Expires January 5, 2013"; 
   } 
   @bottom-right {
@@ -490 +490 @@
       <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-07-03">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-07-04">
       <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. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 4 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests.">
@@ -516 +516 @@
             </tr>
             <tr>
-               <td class="left">Expires: January 4, 2013</td>
+               <td class="left">Expires: January 5, 2013</td>
                <td class="right">J. Reschke, Editor</td>
             </tr>
@@ -525 +525 @@
             <tr>
                <td class="left"></td>
-               <td class="right">July 3, 2012</td>
+               <td class="right">July 4, 2012</td>
             </tr>
          </tbody>
@@ -555 +555 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on January 4, 2013.</p>
+      <p>This Internet-Draft will expire on January 5, 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>
@@ -692 +692 @@
       </p>
       <p id="rfc.section.2.1.p.2">A "strong validator" is a representation metadata value that <em class="bcp14">MUST</em> be changed to a new, previously unused or guaranteed unique, value whenever a change occurs to the representation data such
-         that a change would be observable in the payload body of a 200 response to GET. A strong validator <em class="bcp14">MAY</em> be changed for other reasons, such as when a semantically significant part of the representation metadata is changed (e.g.,
+         that a change would be observable in the payload body of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to GET. A strong validator <em class="bcp14">MAY</em> be changed for other reasons, such as when a semantically significant part of the representation metadata is changed (e.g.,
          Content-Type), but it is in the best interests of the origin server to only change the value when it is necessary to invalidate
          the stored responses held by remote caches and authoring tools. A strong validator <em class="bcp14">MUST</em> be unique across all representations of a given resource, such that no two representations of that resource share the same
@@ -1050 +1050 @@
       </p>
       <ol>
-         <li>If the request would normally result in anything other than a 200 (OK) status code, or if the passed If-Modified-Since date
-            is invalid, the response is exactly the same as for a normal GET. A date which is later than the server's current time is
-            invalid.
+         <li>If the request would normally result in anything other than a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> status code, or if the passed If-Modified-Since date is invalid, the response is exactly the same as for a normal GET. A date
+            which is later than the server's current time is invalid.
          </li>
          <li>If the selected representation has been modified since the If-Modified-Since date, the response is exactly the same as for
@@ -1107 +1106 @@
       <div id="rfc.iref.s.2"></div>
       <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 200 (OK) 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,
+      <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.