Changeset 970 for draft-ietf-httpbis/latest/p4-conditional.html
- Timestamp:
- 31/07/10 08:54:31 (11 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p4-conditional.html
r968 r970 400 400 <meta name="dct.creator" content="Reschke, J. F."> 401 401 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest"> 402 <meta name="dct.issued" scheme="ISO8601" content="2010-07-3 0">402 <meta name="dct.issued" scheme="ISO8601" content="2010-07-31"> 403 403 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 404 404 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia 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."> … … 426 426 </tr> 427 427 <tr> 428 <td class="left">Expires: January 31, 2011</td>428 <td class="left">Expires: February 1, 2011</td> 429 429 <td class="right">J. Mogul</td> 430 430 </tr> … … 483 483 <tr> 484 484 <td class="left"></td> 485 <td class="right">July 3 0, 2010</td>485 <td class="right">July 31, 2010</td> 486 486 </tr> 487 487 </tbody> … … 509 509 in progress”. 510 510 </p> 511 <p>This Internet-Draft will expire in January 31, 2011.</p>511 <p>This Internet-Draft will expire in February 1, 2011.</p> 512 512 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 513 513 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 881 881 </p> 882 882 <ul class="empty"> 883 <li> <b>Note:</b> The general principle behind these rules is that HTTP/1.1 servers and clients shouldtransmit as much non-redundant information883 <li> <b>Note:</b> The general principle behind these rules is that HTTP/1.1 servers and clients ought to transmit as much non-redundant information 884 884 as is available in their responses and requests. HTTP/1.1 systems receiving this information will make the most conservative 885 885 assumptions about the validators they receive. … … 989 989 </li> 990 990 <li> <b>Note:</b> If a client uses an arbitrary date in the If-Modified-Since header instead of a date taken from the Last-Modified header for 991 the same request, the client should be aware of the fact that this date is interpreted in the server's understanding of time.992 The client should consider unsynchronized clocks and rounding problems due to the different encodings of time between the993 client and server. This includes the possibility of race conditions if the document has changed between the time it was first994 requested and the If-Modified-Since date of a subsequent request, and the possibility of clock-skew-related problems if the995 If-Modified-Since date is derived from the client's clock without correction to the server's clock. Corrections for different996 time bases between client andserver are at best approximate due to network latency.991 the same request, the client needs to be aware that this date is interpreted in the server's understanding of time. Unsynchronized 992 clocks and rounding problems, due to the different encodings of time between the client and server, are concerns. This includes 993 the possibility of race conditions if the document has changed between the time it was first requested and the If-Modified-Since 994 date of a subsequent request, and the possibility of clock-skew-related problems if the If-Modified-Since date is derived 995 from the client's clock without correction to the server's clock. Corrections for different time bases between client and 996 server are at best approximate due to network latency. 997 997 </li> 998 998 </ul> … … 1086 1086 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> 1087 1087 <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a> <a id="status.code.registration" href="#status.code.registration">Status Code Registration</a></h2> 1088 <p id="rfc.section.7.1.p.1">The HTTP Status Code Registry located at <<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>> sh ouldbe updated with the registrations below:1088 <p id="rfc.section.7.1.p.1">The HTTP Status Code Registry located at <<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>> shall be updated with the registrations below: 1089 1089 </p> 1090 1090 <div id="rfc.table.1"> … … 1115 1115 </div> 1116 1116 <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a> <a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2> 1117 <p id="rfc.section.7.2.p.1">The Message Header Field Registry located at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>> sh ouldbe updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):1117 <p id="rfc.section.7.2.p.1">The Message Header Field Registry located at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>> shall be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>): 1118 1118 </p> 1119 1119 <div id="rfc.table.2">
Note: See TracChangeset
for help on using the changeset viewer.