Changeset 1452 for draft-ietf-httpbis/latest/p4-conditional.html
- Timestamp:
- 23/10/11 20:20:31 (11 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p4-conditional.html
r1443 r1452 359 359 } 360 360 @bottom-center { 361 content: "Expires April 4, 2012";361 content: "Expires April 25, 2012"; 362 362 } 363 363 @bottom-right { … … 404 404 <meta name="dct.creator" content="Reschke, J. F."> 405 405 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest"> 406 <meta name="dct.issued" scheme="ISO8601" content="2011-10- 02">406 <meta name="dct.issued" scheme="ISO8601" content="2011-10-23"> 407 407 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 408 408 <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."> … … 430 430 </tr> 431 431 <tr> 432 <td class="left">Expires: April 4, 2012</td>432 <td class="left">Expires: April 25, 2012</td> 433 433 <td class="right">J. Mogul</td> 434 434 </tr> … … 487 487 <tr> 488 488 <td class="left"></td> 489 <td class="right">October 2 , 2011</td>489 <td class="right">October 23, 2011</td> 490 490 </tr> 491 491 </tbody> … … 517 517 in progress”. 518 518 </p> 519 <p>This Internet-Draft will expire on April 4, 2012.</p>519 <p>This Internet-Draft will expire on April 25, 2012.</p> 520 520 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 521 521 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 536 536 <ul class="toc"> 537 537 <li>1. <a href="#introduction">Introduction</a><ul> 538 <li>1.1 <a href="#intro. requirements">Requirements</a></li>538 <li>1.1 <a href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></li> 539 539 <li>1.2 <a href="#notation">Syntax Notation</a></li> 540 540 </ul> … … 625 625 selected representation. 626 626 </p> 627 <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="intro. requirements" href="#intro.requirements">Requirements</a></h2>627 <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="intro.conformance.and.error.handling" href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></h2> 628 628 <p id="rfc.section.1.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 629 629 in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>. 630 630 </p> 631 <p id="rfc.section.1.1.p.2">An implementation is not compliant if it fails to satisfy one or more of the "MUST" or "REQUIRED" level requirements for the 632 protocols it implements. An implementation that satisfies all the "MUST" or "REQUIRED" level and all the "SHOULD" level requirements 633 for its protocols is said to be "unconditionally compliant"; one that satisfies all the "MUST" level requirements but not 634 all the "SHOULD" level requirements for its protocols is said to be "conditionally compliant". 631 <p id="rfc.section.1.1.p.2">This document defines conformance criteria for several roles in HTTP communication, including Senders, Recipients, Clients, 632 Servers, User-Agents, Origin Servers, Intermediaries, Proxies and Gateways. See <a href="p1-messaging.html#architecture" title="Architecture">Section 2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for definitions of these terms. 633 </p> 634 <p id="rfc.section.1.1.p.3">An implementation is considered conformant if it complies with all of the requirements associated with its role(s). Note that 635 SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable. 636 </p> 637 <p id="rfc.section.1.1.p.4">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section 1.2</a>). In addition to the prose requirements placed upon them, Senders <em class="bcp14">MUST NOT</em> generate protocol elements that are invalid. 638 </p> 639 <p id="rfc.section.1.1.p.5">Unless noted otherwise, Recipients <em class="bcp14">MAY</em> take steps to recover a usable protocol element from an invalid construct. However, HTTP does not define specific error handling 640 mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require 641 different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the 642 Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of 643 error recovery could lead to dangerous consequences. 635 644 </p> 636 645 <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="notation" href="#notation">Syntax Notation</a></h2> 637 <p id="rfc.section.1.2.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1. 1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> (which extends the syntax defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list rule). <a href="#collected.abnf" title="Collected ABNF">Appendix B</a> shows the collected ABNF, with the list rule expanded.646 <p id="rfc.section.1.2.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> (which extends the syntax defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list rule). <a href="#collected.abnf" title="Collected ABNF">Appendix B</a> shows the collected ABNF, with the list rule expanded. 638 647 </p> 639 648 <p id="rfc.section.1.2.p.2">The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG … … 641 650 character). 642 651 </p> 643 <p id="rfc.section.1.2.p.3">The ABNF rules below are defined in <a href="#Part1" id="rfc.xref.Part1. 2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> and <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>:644 </p> 645 <div id="rfc.figure.u.1"></div><pre class="inline"> <a href="#notation" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1. 3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>>646 <a href="#notation" class="smpl">quoted-string</a> = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1. 4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>>652 <p id="rfc.section.1.2.p.3">The ABNF rules below are defined in <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> and <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>: 653 </p> 654 <div id="rfc.figure.u.1"></div><pre class="inline"> <a href="#notation" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>> 655 <a href="#notation" class="smpl">quoted-string</a> = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>> 647 656 <a href="#notation" class="smpl">HTTP-date</a> = <HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 8</a>> 648 657 </pre><div id="rfc.iref.m.1"></div> … … 882 891 <p> <b>Note:</b> Content codings are a property of the representation, so therefore an entity-tag of an encoded representation must be distinct 883 892 from an unencoded representation to prevent conflicts during cache updates and range requests. In contrast, transfer codings 884 (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 5.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>) apply only during message transfer and do not require distinct entity-tags.893 (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 5.1</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) apply only during message transfer and do not require distinct entity-tags. 885 894 </p> 886 895 </div> … … 1188 1197 <p id="rfc.section.5.2.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p> 1189 1198 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1> 1190 <p id="rfc.section.6.p.1">No additional security considerations have been identified beyond those applicable to HTTP in general <a href="#Part1" id="rfc.xref.Part1. 6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.1199 <p id="rfc.section.6.p.1">No additional security considerations have been identified beyond those applicable to HTTP in general <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 1191 1200 </p> 1192 1201 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="acks" href="#acks">Acknowledgments</a></h1> 1193 <p id="rfc.section.7.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 11</a> of <a href="#Part1" id="rfc.xref.Part1. 7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.1202 <p id="rfc.section.7.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 11</a> of <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 1194 1203 </p> 1195 1204 <h1 id="rfc.references"><a id="rfc.section.8" href="#rfc.section.8">8.</a> References … … 1421 1430 </ul> 1422 1431 <h2 id="rfc.section.C.18"><a href="#rfc.section.C.18">C.18</a> <a id="changes.since.16" href="#changes.since.16">Since draft-ietf-httpbis-p4-conditional-16</a></h2> 1423 <p id="rfc.section.C.18.p.1">None yet.</p> 1432 <p id="rfc.section.C.18.p.1">Closed issues: </p> 1433 <ul> 1434 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/186">http://tools.ietf.org/wg/httpbis/trac/ticket/186</a>>: "Document HTTP's error-handling philosophy" 1435 </li> 1436 </ul> 1424 1437 <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> 1425 1438 <p class="noprint"><a href="#rfc.index.3">3</a> <a href="#rfc.index.4">4</a> <a href="#rfc.index.E">E</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.L">L</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.V">V</a> … … 1484 1497 </li> 1485 1498 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 1486 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1.2</a>, <a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">1.2</a>, <a href="#rfc.xref.Part1.5">2.3.3</a>, <a href="#rfc.xref.Part1.6">6</a>, <a href="#rfc.xref.Part1.7">7</a>, <a href="#Part1"><b>8.1</b></a><ul> 1487 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.1">1.2</a></li> 1488 <li><em>Section 1.2.2</em> <a href="#rfc.xref.Part1.3">1.2</a></li> 1489 <li><em>Section 3.2.3</em> <a href="#rfc.xref.Part1.4">1.2</a></li> 1490 <li><em>Section 5.1</em> <a href="#rfc.xref.Part1.5">2.3.3</a></li> 1491 <li><em>Section 11</em> <a href="#rfc.xref.Part1.7">7</a></li> 1499 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1.1</a>, <a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">1.2</a>, <a href="#rfc.xref.Part1.5">1.2</a>, <a href="#rfc.xref.Part1.6">2.3.3</a>, <a href="#rfc.xref.Part1.7">6</a>, <a href="#rfc.xref.Part1.8">7</a>, <a href="#Part1"><b>8.1</b></a><ul> 1500 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.2">1.2</a></li> 1501 <li><em>Section 1.2.2</em> <a href="#rfc.xref.Part1.4">1.2</a></li> 1502 <li><em>Section 2</em> <a href="#rfc.xref.Part1.1">1.1</a></li> 1503 <li><em>Section 3.2.3</em> <a href="#rfc.xref.Part1.5">1.2</a></li> 1504 <li><em>Section 5.1</em> <a href="#rfc.xref.Part1.6">2.3.3</a></li> 1505 <li><em>Section 11</em> <a href="#rfc.xref.Part1.8">7</a></li> 1492 1506 </ul> 1493 1507 </li>
Note: See TracChangeset
for help on using the changeset viewer.