Changeset 1715 for draft-ietf-httpbis/latest/p4-conditional.html
- Timestamp:
- 04/07/12 19:54:55 (11 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p4-conditional.html
r1708 r1715 449 449 } 450 450 @bottom-center { 451 content: "Expires January 4, 2013";451 content: "Expires January 5, 2013"; 452 452 } 453 453 @bottom-right { … … 490 490 <meta name="dct.creator" content="Reschke, J. F."> 491 491 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest"> 492 <meta name="dct.issued" scheme="ISO8601" content="2012-07-0 3">492 <meta name="dct.issued" scheme="ISO8601" content="2012-07-04"> 493 493 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 494 494 <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 "HTTP/1.1" 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> 517 517 <tr> 518 <td class="left">Expires: January 4, 2013</td>518 <td class="left">Expires: January 5, 2013</td> 519 519 <td class="right">J. Reschke, Editor</td> 520 520 </tr> … … 525 525 <tr> 526 526 <td class="left"></td> 527 <td class="right">July 3, 2012</td>527 <td class="right">July 4, 2012</td> 528 528 </tr> 529 529 </tbody> … … 555 555 in progress”. 556 556 </p> 557 <p>This Internet-Draft will expire on January 4, 2013.</p>557 <p>This Internet-Draft will expire on January 5, 2013.</p> 558 558 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 559 559 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 692 692 </p> 693 693 <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 694 that a change would be observable in the payload body of a 200response 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.,694 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., 695 695 Content-Type), but it is in the best interests of the origin server to only change the value when it is necessary to invalidate 696 696 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> 1051 1051 <ol> 1052 <li>If the request would normally result in anything other than a 200 (OK) status code, or if the passed If-Modified-Since date 1053 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 1054 invalid. 1052 <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 1053 which is later than the server's current time is invalid. 1055 1054 </li> 1056 1055 <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> 1108 1107 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="status.304" href="#status.304">304 Not Modified</a></h2> 1109 <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 1110 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 1111 transfer a representation of the target resource because the client's request indicates that it already has a valid representation, 1108 <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 1109 to transfer a representation of the target resource because the client's request indicates that it already has a valid representation, 1112 1110 as indicated by the 304 response header fields, and is therefore redirecting the client to make use of that stored representation 1113 1111 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.
Note: See TracChangeset
for help on using the changeset viewer.