Changeset 1783 for draft-ietf-httpbis
- Timestamp:
- 15/07/12 06:40:35 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p4-conditional.html
r1773 r1783 475 475 <link rel="Chapter" title="3 Precondition Header Fields" href="#rfc.section.3"> 476 476 <link rel="Chapter" title="4 Status Code Definitions" href="#rfc.section.4"> 477 <link rel="Chapter" title="5 IANA Considerations" href="#rfc.section.5"> 478 <link rel="Chapter" title="6 Security Considerations" href="#rfc.section.6"> 479 <link rel="Chapter" title="7 Acknowledgments" href="#rfc.section.7"> 480 <link rel="Chapter" href="#rfc.section.8" title="8 References"> 477 <link rel="Chapter" title="5 ABNF Rules Defined Elsewhere" href="#rfc.section.5"> 478 <link rel="Chapter" title="6 IANA Considerations" href="#rfc.section.6"> 479 <link rel="Chapter" title="7 Security Considerations" href="#rfc.section.7"> 480 <link rel="Chapter" title="8 Acknowledgments" href="#rfc.section.8"> 481 <link rel="Chapter" href="#rfc.section.9" title="9 References"> 481 482 <link rel="Appendix" title="A Changes from RFC 2616" href="#rfc.section.A"> 482 483 <link rel="Appendix" title="B Collected ABNF" href="#rfc.section.B"> … … 492 493 <meta name="dct.issued" scheme="ISO8601" content="2012-07-14"> 493 494 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 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.">495 <meta name="description" 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.">495 <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."> 496 <meta name="description" 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."> 496 497 </head> 497 498 <body onload="init();"> … … 532 533 <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1> 533 534 <p>The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information 534 systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 4 of the 535 seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. 536 </p> 537 <p>Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those 538 requests. 535 systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, 536 request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request 537 when one or more preconditions evaluate to false. 539 538 </p> 540 539 <h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note (To be removed by RFC Editor)</a></h1> … … 572 571 <h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1> 573 572 <ul class="toc"> 574 <li>1. <a href="#introduction">Introduction</a><ul> 575 <li>1.1 <a href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></li> 576 <li>1.2 <a href="#notation">Syntax Notation</a></li> 577 </ul> 578 </li> 573 <li>1. <a href="#introduction">Introduction</a></li> 579 574 <li>2. <a href="#validators">Validators</a><ul> 580 575 <li>2.1 <a href="#weak.and.strong.validators">Weak versus Strong</a></li> … … 606 601 </ul> 607 602 </li> 608 <li>5. <a href="#IANA.considerations">IANA Considerations</a><ul> 609 <li>5.1 <a href="#status.code.registration">Status Code Registration</a></li> 610 <li>5.2 <a href="#header.field.registration">Header Field Registration</a></li> 603 <li>5. <a href="#abnf.dependencies">ABNF Rules Defined Elsewhere</a></li> 604 <li>6. <a href="#IANA.considerations">IANA Considerations</a><ul> 605 <li>6.1 <a href="#status.code.registration">Status Code Registration</a></li> 606 <li>6.2 <a href="#header.field.registration">Header Field Registration</a></li> 611 607 </ul> 612 608 </li> 613 <li> 6. <a href="#security.considerations">Security Considerations</a></li>614 <li> 7. <a href="#acks">Acknowledgments</a></li>615 <li> 8. <a href="#rfc.references">References</a><ul>616 <li> 8.1 <a href="#rfc.references.1">Normative References</a></li>617 <li> 8.2 <a href="#rfc.references.2">Informative References</a></li>609 <li>7. <a href="#security.considerations">Security Considerations</a></li> 610 <li>8. <a href="#acks">Acknowledgments</a></li> 611 <li>9. <a href="#rfc.references">References</a><ul> 612 <li>9.1 <a href="#rfc.references.1">Normative References</a></li> 613 <li>9.2 <a href="#rfc.references.2">Informative References</a></li> 618 614 </ul> 619 615 </li> … … 628 624 </ul> 629 625 <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a id="introduction" href="#introduction">Introduction</a></h1> 630 <p id="rfc.section.1.p.1">This document defines the HTTP/1.1 conditional request mechanisms, including both metadata for indicating/observing changes 631 in resource representations and request header fields that specify preconditions on that metadata; to be checked before performing 632 the request method. Conditional GET requests are the most efficient mechanism for HTTP cache updates <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. Conditionals can also be applied to state-changing methods, such as PUT and DELETE, to prevent the "lost update" problem: 626 <p id="rfc.section.1.p.1">Conditional requests are HTTP requests <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> that include one or more header fields indicating a precondition to be tested before applying the method semantics to the 627 target resource. Each precondition is based on metadata that is expected to change if the selected representation of the target 628 resource is changed. This document defines the HTTP/1.1 conditional request mechanisms in terms of the architecture, syntax 629 notation, and conformance criteria defined in <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>. 630 </p> 631 <p id="rfc.section.1.p.2">Conditional GET requests are the most efficient mechanism for HTTP cache updates <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. Conditionals can also be applied to state-changing methods, such as PUT and DELETE, to prevent the "lost update" problem: 633 632 one client accidentally overwriting the work of another client that has been acting in parallel. 634 633 </p> 635 <p id="rfc.section.1.p. 2">Conditional request preconditions are based on the state of the target resource as a whole (its current value set) or the634 <p id="rfc.section.1.p.3">Conditional request preconditions are based on the state of the target resource as a whole (its current value set) or the 636 635 state as observed in a previously obtained representation (one value in that set). A resource might have multiple current 637 636 representations, each with its own observable state. The conditional request mechanisms assume that the mapping of requests … … 640 639 when the precondition evaluates to false. 641 640 </p> 642 <p id="rfc.section.1.p. 3"><span id="rfc.iref.s.1"></span> We use the term "<dfn>selected representation</dfn>" to refer to the current representation of the target resource that would have been selected in a successful response if641 <p id="rfc.section.1.p.4"><span id="rfc.iref.s.1"></span> We use the term "<dfn>selected representation</dfn>" to refer to the current representation of the target resource that would have been selected in a successful response if 643 642 the same request had used the method GET and had excluded all of the conditional request header fields. The conditional request 644 643 preconditions are evaluated by comparing the values provided in the request header fields to the current metadata for the 645 644 selected representation. 646 645 </p> 647 <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> 648 <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" 649 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>. 650 </p> 651 <p id="rfc.section.1.1.p.2">This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP 652 requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways, 653 or caches, depending on what behavior is being constrained by the requirement. 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. 654 </p> 655 <p id="rfc.section.1.1.p.3">The verb "generate" is used instead of "send" where a requirement differentiates between creating a protocol element and merely 656 forwarding a received element downstream. 657 </p> 658 <p id="rfc.section.1.1.p.4">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes 659 in HTTP. Note that SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable. 660 </p> 661 <p id="rfc.section.1.1.p.5">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 do not match the grammar defined by the ABNF rules for those protocol elements that are applicable 662 to the sender's role. If a received protocol element is processed, the recipient <em class="bcp14">MUST</em> be able to parse any value that would match the ABNF rules for that protocol element, excluding only those rules not applicable 663 to the recipient's role. 664 </p> 665 <p id="rfc.section.1.1.p.6">Unless noted otherwise, a recipient <em class="bcp14">MAY</em> attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms 666 except when they have a direct impact on security, since different applications of the protocol require different error handling 667 strategies. For example, a Web browser might wish to transparently recover from a response where the <a href="p2-semantics.html#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereas a systems control client might consider any form of error recovery 668 to be dangerous. 669 </p> 670 <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="notation" href="#notation">Syntax Notation</a></h2> 671 <p id="rfc.section.1.2.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with the list rule extension 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>. <a href="#collected.abnf" title="Collected ABNF">Appendix B</a> shows the collected ABNF with the list rule expanded. 672 </p> 673 <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 674 (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII 675 character). 676 </p> 677 <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, Payload and Content Negotiation">[Part2]</cite></a>: 678 </p> 679 <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#whitespace" title="Whitespace">Section 3.2.1</a>> 680 <a href="#notation" class="smpl">obs-text</a> = <obs-text, 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.components" title="Field value components">Section 3.2.4</a>> 681 <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, Payload and Content Negotiation">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 5.1</a>> 682 </pre><div id="rfc.iref.m.1"></div> 646 <div id="rfc.iref.m.1"></div> 683 647 <div id="rfc.iref.v.1"></div> 684 648 <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="validators" href="#validators">Validators</a></h1> … … 737 701 was last modified. 738 702 </p> 739 <div id="rfc.figure.u. 2"></div><pre class="inline"><span id="rfc.iref.g.1"></span> <a href="#header.last-modified" class="smpl">Last-Modified</a> = <a href="#notation" class="smpl">HTTP-date</a>703 <div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span> <a href="#header.last-modified" class="smpl">Last-Modified</a> = <a href="#abnf.dependencies" class="smpl">HTTP-date</a> 740 704 </pre><p id="rfc.section.2.2.p.3">An example of its use is</p> 741 <div id="rfc.figure.u. 3"></div><pre class="text"> Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT705 <div id="rfc.figure.u.2"></div><pre class="text"> Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT 742 706 </pre><h3 id="rfc.section.2.2.1"><a href="#rfc.section.2.2.1">2.2.1</a> <a id="lastmod.generation" href="#lastmod.generation">Generation</a></h3> 743 707 <p id="rfc.section.2.2.1.p.1">Origin servers <em class="bcp14">SHOULD</em> send Last-Modified for any selected representation for which a last modification date can be reasonably and consistently determined, … … 799 763 same time, or both. An entity-tag consists of an opaque quoted string, possibly prefixed by a weakness indicator. 800 764 </p> 801 <div id="rfc.figure.u. 4"></div><pre class="inline"><span id="rfc.iref.g.2"></span><span id="rfc.iref.g.3"></span><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span> <a href="#header.etag" class="smpl">ETag</a> = <a href="#header.etag" class="smpl">entity-tag</a>765 <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.2"></span><span id="rfc.iref.g.3"></span><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span> <a href="#header.etag" class="smpl">ETag</a> = <a href="#header.etag" class="smpl">entity-tag</a> 802 766 803 767 <a href="#header.etag" class="smpl">entity-tag</a> = [ <a href="#header.etag" class="smpl">weak</a> ] <a href="#header.etag" class="smpl">opaque-tag</a> 804 768 <a href="#header.etag" class="smpl">weak</a> = %x57.2F ; "W/", case-sensitive 805 <a href="#header.etag" class="smpl">opaque-tag</a> = <a href="# notation" class="smpl">DQUOTE</a> *<a href="#header.etag" class="smpl">etagc</a> <a href="#notation" class="smpl">DQUOTE</a>806 <a href="#header.etag" class="smpl">etagc</a> = %x21 / %x23-7E / <a href="# notation" class="smpl">obs-text</a>807 ; <a href="# notation" class="smpl">VCHAR</a> except double quotes, plus obs-text769 <a href="#header.etag" class="smpl">opaque-tag</a> = <a href="#abnf.dependencies" class="smpl">DQUOTE</a> *<a href="#header.etag" class="smpl">etagc</a> <a href="#abnf.dependencies" class="smpl">DQUOTE</a> 770 <a href="#header.etag" class="smpl">etagc</a> = %x21 / %x23-7E / <a href="#abnf.dependencies" class="smpl">obs-text</a> 771 ; <a href="#abnf.dependencies" class="smpl">VCHAR</a> except double quotes, plus obs-text 808 772 </pre><div class="note" id="rfc.section.2.3.p.3"> 809 773 <p> <b>Note:</b> Previously, opaque-tag was defined to be a quoted-string (<a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="http://tools.ietf.org/html/rfc2616#section-3.11">Section 3.11</a>), thus some recipients might perform backslash unescaping. Servers therefore ought to avoid backslash characters in entity … … 815 779 not consistently maintained. 816 780 </p> 817 <div id="rfc.figure.u. 5"></div>781 <div id="rfc.figure.u.4"></div> 818 782 <p>Examples:</p> <pre class="text"> ETag: "xyzzy" 819 783 ETag: W/"xyzzy" … … 887 851 </div> 888 852 <h3 id="rfc.section.2.3.3"><a href="#rfc.section.2.3.3">2.3.3</a> <a id="example.entity.tag.vs.conneg" href="#example.entity.tag.vs.conneg">Example: Entity-tags varying on Content-Negotiated Resources</a></h3> 889 <p id="rfc.section.2.3.3.p.1">Consider a resource that is subject to content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2. 3"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>), and where the representations returned upon a GET request vary based on the <a href="p2-semantics.html#header.accept-encoding" class="smpl">Accept-Encoding</a> request header field (<a href="p2-semantics.html#header.accept-encoding" title="Accept-Encoding">Section 9.3</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>):890 </p> 891 <div id="rfc.figure.u. 6"></div>853 <p id="rfc.section.2.3.3.p.1">Consider a resource that is subject to content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>), and where the representations returned upon a GET request vary based on the <a href="p2-semantics.html#header.accept-encoding" class="smpl">Accept-Encoding</a> request header field (<a href="p2-semantics.html#header.accept-encoding" title="Accept-Encoding">Section 9.3</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>): 854 </p> 855 <div id="rfc.figure.u.5"></div> 892 856 <p>>> Request:</p><pre class="text2">GET /index HTTP/1.1 893 857 Host: www.example.com … … 895 859 896 860 </pre><p id="rfc.section.2.3.3.p.3">In this case, the response might or might not use the gzip content coding. If it does not, the response might look like:</p> 897 <div id="rfc.figure.u. 7"></div>861 <div id="rfc.figure.u.6"></div> 898 862 <p>>> Response:</p><pre class="text">HTTP/1.1 200 OK 899 863 Date: Thu, 26 Mar 2010 00:05:00 GMT … … 909 873 Hello World! 910 874 </span></pre><p id="rfc.section.2.3.3.p.5">An alternative representation that does use gzip content coding would be:</p> 911 <div id="rfc.figure.u. 8"></div>875 <div id="rfc.figure.u.7"></div> 912 876 <p>>> Response:</p><pre class="text">HTTP/1.1 200 OK 913 877 Date: Thu, 26 Mar 2010 00:05:00 GMT … … 921 885 <p> <b>Note:</b> Content codings are a property of the representation, so therefore an entity-tag of an encoded representation has to be distinct 922 886 from an unencoded representation to prevent conflicts during cache updates and range requests. In contrast, transfer codings 923 (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 4</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.887 (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 4</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>) apply only during message transfer and do not require distinct entity-tags. 924 888 </p> 925 889 </div> … … 978 942 field-value of "*" places the precondition on the existence of any current representation for the target resource. 979 943 </p> 980 <div id="rfc.figure.u. 9"></div><pre class="inline"><span id="rfc.iref.g.7"></span> <a href="#header.if-match" class="smpl">If-Match</a> = "*" / 1#<a href="#header.etag" class="smpl">entity-tag</a>944 <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.7"></span> <a href="#header.if-match" class="smpl">If-Match</a> = "*" / 1#<a href="#header.etag" class="smpl">entity-tag</a> 981 945 </pre><p id="rfc.section.3.1.p.4">The If-Match condition is met if and only if any of the entity-tags listed in the If-Match field value match the entity-tag 982 946 of the selected representation for the target resource (as per <a href="#entity.tag.comparison" title="Comparison">Section 2.3.2</a>), or if "*" is given and any current representation exists for the target resource. … … 992 956 </p> 993 957 <p id="rfc.section.3.1.p.9">Examples:</p> 994 <div id="rfc.figure.u. 10"></div><pre class="text"> If-Match: "xyzzy"958 <div id="rfc.figure.u.9"></div><pre class="text"> If-Match: "xyzzy" 995 959 If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" 996 960 If-Match: * … … 1013 977 for the target resource. 1014 978 </p> 1015 <div id="rfc.figure.u.1 1"></div><pre class="inline"><span id="rfc.iref.g.8"></span> <a href="#header.if-none-match" class="smpl">If-None-Match</a> = "*" / 1#<a href="#header.etag" class="smpl">entity-tag</a>979 <div id="rfc.figure.u.10"></div><pre class="inline"><span id="rfc.iref.g.8"></span> <a href="#header.if-none-match" class="smpl">If-None-Match</a> = "*" / 1#<a href="#header.etag" class="smpl">entity-tag</a> 1016 980 </pre><p id="rfc.section.3.2.p.5">The If-None-Match condition is met if and only if none of the entity-tags listed in the If-None-Match field value match the 1017 981 entity-tag of the selected representation for the target resource (as per <a href="#entity.tag.comparison" title="Comparison">Section 2.3.2</a>), or if "*" is given and no current representation exists for that resource. … … 1026 990 </p> 1027 991 <p id="rfc.section.3.2.p.9">Examples:</p> 1028 <div id="rfc.figure.u.1 2"></div><pre class="text"> If-None-Match: "xyzzy"992 <div id="rfc.figure.u.11"></div><pre class="text"> If-None-Match: "xyzzy" 1029 993 If-None-Match: W/"xyzzy" 1030 994 If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" … … 1040 1004 respond as detailed below. 1041 1005 </p> 1042 <div id="rfc.figure.u.1 3"></div><pre class="inline"><span id="rfc.iref.g.9"></span> <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> = <a href="#notation" class="smpl">HTTP-date</a>1006 <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.9"></span> <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> = <a href="#abnf.dependencies" class="smpl">HTTP-date</a> 1043 1007 </pre><p id="rfc.section.3.3.p.3">An example of the field is:</p> 1044 <div id="rfc.figure.u.1 4"></div><pre class="text"> If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT1008 <div id="rfc.figure.u.13"></div><pre class="text"> If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT 1045 1009 </pre><p id="rfc.section.3.3.p.5">A GET method with an If-Modified-Since header field and no <a href="p5-range.html#range.retrieval.requests" class="smpl">Range</a> header field requests that the selected representation be transferred only if it has been modified since the date given by 1046 1010 the If-Modified-Since header field. The algorithm for determining this includes the following cases: … … 1082 1046 representation has been modified since the time specified in this field, then the server <em class="bcp14">MUST NOT</em> perform the requested operation and <em class="bcp14">MUST</em> instead respond with the <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code. If the selected representation has not been modified since the time specified in this field, the server <em class="bcp14">SHOULD</em> perform the request method as if the If-Unmodified-Since header field were not present. 1083 1047 </p> 1084 <div id="rfc.figure.u.1 5"></div><pre class="inline"><span id="rfc.iref.g.10"></span> <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> = <a href="#notation" class="smpl">HTTP-date</a>1048 <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.10"></span> <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> = <a href="#abnf.dependencies" class="smpl">HTTP-date</a> 1085 1049 </pre><p id="rfc.section.3.4.p.3">An example of the field is:</p> 1086 <div id="rfc.figure.u.1 6"></div><pre class="text"> If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT1050 <div id="rfc.figure.u.15"></div><pre class="text"> If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT 1087 1051 </pre><p id="rfc.section.3.4.p.5">If a request normally (i.e., in absence of the If-Unmodified-Since header field) would result in anything other than a <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> or <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code, the If-Unmodified-Since header field <em class="bcp14">SHOULD</em> be ignored. 1088 1052 </p> … … 1103 1067 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. 1104 1068 </p> 1105 <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 9.10</a> of <a href="#Part2" id="rfc.xref.Part2. 5"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[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">2001069 <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 9.10</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[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 1106 1070 (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="p6-cache.html#header.vary" class="smpl">Vary</a>, then those same header fields <em class="bcp14">MUST</em> be sent in a 304 response. 1107 1071 </p> … … 1123 1087 and metadata) and thus prevent the request method from being applied if the target resource is in an unexpected state. 1124 1088 </p> 1125 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> 1126 <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a> <a id="status.code.registration" href="#status.code.registration">Status Code Registration</a></h2> 1127 <p id="rfc.section.5.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 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="abnf.dependencies" href="#abnf.dependencies">ABNF Rules Defined Elsewhere</a></h1> 1090 <p id="rfc.section.5.p.1">This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with the list rule extension defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <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="#collected.abnf" title="Collected ABNF">Appendix B</a> shows the collected ABNF with the list rule expanded. 1091 </p> 1092 <p id="rfc.section.5.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 1093 (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII 1094 character). 1095 </p> 1096 <p id="rfc.section.5.p.3">The ABNF rules below are 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> and <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>: 1097 </p> 1098 <div id="rfc.figure.u.16"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">OWS</a> = <OWS, 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#whitespace" title="Whitespace">Section 3.2.1</a>> 1099 <a href="#abnf.dependencies" class="smpl">obs-text</a> = <obs-text, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.4</a>> 1100 <a href="#abnf.dependencies" class="smpl">HTTP-date</a> = <HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 5.1</a>> 1101 </pre><p id="rfc.section.5.p.5">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 1102 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>. 1103 </p> 1104 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> 1105 <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a id="status.code.registration" href="#status.code.registration">Status Code Registration</a></h2> 1106 <p id="rfc.section.6.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: 1128 1107 </p> 1129 1108 <div id="rfc.table.1"> … … 1153 1132 </table> 1154 1133 </div> 1155 <h2 id="rfc.section. 5.2"><a href="#rfc.section.5.2">5.2</a> <a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2>1156 <p id="rfc.section. 5.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>):1134 <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a> <a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2> 1135 <p id="rfc.section.6.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>): 1157 1136 </p> 1158 1137 <div id="rfc.table.2"> … … 1213 1192 </table> 1214 1193 </div> 1215 <p id="rfc.section. 5.2.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>1216 <h1 id="rfc.section. 6"><a href="#rfc.section.6">6.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>1217 <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>.1218 </p> 1219 <h1 id="rfc.section. 7"><a href="#rfc.section.7">7.</a> <a id="acks" href="#acks">Acknowledgments</a></h1>1220 <p id="rfc.section. 7.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 9</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>.1221 </p> 1222 <h1 id="rfc.references"><a id="rfc.section. 8" href="#rfc.section.8">8.</a> References1194 <p id="rfc.section.6.2.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p> 1195 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1> 1196 <p id="rfc.section.7.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>. 1197 </p> 1198 <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a id="acks" href="#acks">Acknowledgments</a></h1> 1199 <p id="rfc.section.8.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 9</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>. 1200 </p> 1201 <h1 id="rfc.references"><a id="rfc.section.9" href="#rfc.section.9">9.</a> References 1223 1202 </h1> 1224 <h2 id="rfc.references.1"><a href="#rfc.section. 8.1" id="rfc.section.8.1">8.1</a> Normative References1203 <h2 id="rfc.references.1"><a href="#rfc.section.9.1" id="rfc.section.9.1">9.1</a> Normative References 1225 1204 </h2> 1226 1205 <table> … … 1256 1235 </tr> 1257 1236 </table> 1258 <h2 id="rfc.references.2"><a href="#rfc.section. 8.2" id="rfc.section.8.2">8.2</a> Informative References1237 <h2 id="rfc.references.2"><a href="#rfc.section.9.2" id="rfc.section.9.2">9.2</a> Informative References 1259 1238 </h2> 1260 1239 <table> … … 1297 1276 <div id="rfc.figure.u.17"></div> <pre class="inline"><a href="#header.etag" class="smpl">ETag</a> = entity-tag 1298 1277 1299 <a href="# notation" class="smpl">HTTP-date</a> = <HTTP-date, defined in [Part2], Section 5.1>1278 <a href="#abnf.dependencies" class="smpl">HTTP-date</a> = <HTTP-date, defined in [Part2], Section 5.1> 1300 1279 1301 1280 <a href="#header.if-match" class="smpl">If-Match</a> = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS … … 1308 1287 <a href="#header.last-modified" class="smpl">Last-Modified</a> = HTTP-date 1309 1288 1310 <a href="# notation" class="smpl">OWS</a> = <OWS, defined in [Part1], Section 3.2.1>1289 <a href="#abnf.dependencies" class="smpl">OWS</a> = <OWS, defined in [Part1], Section 3.2.1> 1311 1290 1312 1291 <a href="#header.etag" class="smpl">entity-tag</a> = [ weak ] opaque-tag … … 1314 1293 / obs-text 1315 1294 1316 <a href="# notation" class="smpl">obs-text</a> = <obs-text, defined in [Part1], Section 3.2.4>1295 <a href="#abnf.dependencies" class="smpl">obs-text</a> = <obs-text, defined in [Part1], Section 3.2.4> 1317 1296 <a href="#header.etag" class="smpl">opaque-tag</a> = DQUOTE *etagc DQUOTE 1318 1297 … … 1339 1318 <ul class="ind"> 1340 1319 <li><a id="rfc.index.3" href="#rfc.index.3"><b>3</b></a><ul> 1341 <li>304 Not Modified (status code) <a href="#rfc.iref.27"><b>4.1</b></a>, <a href="#rfc.xref.status.304.1"> 5.1</a></li>1320 <li>304 Not Modified (status code) <a href="#rfc.iref.27"><b>4.1</b></a>, <a href="#rfc.xref.status.304.1">6.1</a></li> 1342 1321 </ul> 1343 1322 </li> 1344 1323 <li><a id="rfc.index.4" href="#rfc.index.4"><b>4</b></a><ul> 1345 <li>412 Precondition Failed (status code) <a href="#rfc.iref.28"><b>4.2</b></a>, <a href="#rfc.xref.status.412.1"> 5.1</a></li>1324 <li>412 Precondition Failed (status code) <a href="#rfc.iref.28"><b>4.2</b></a>, <a href="#rfc.xref.status.412.1">6.1</a></li> 1346 1325 </ul> 1347 1326 </li> 1348 1327 <li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul> 1349 <li>ETag header field <a href="#rfc.xref.header.etag.1">2</a>, <a href="#rfc.iref.e.1"><b>2.3</b></a>, <a href="#rfc.xref.header.etag.2"> 5.2</a>, <a href="#rfc.xref.header.etag.3">A</a></li>1328 <li>ETag header field <a href="#rfc.xref.header.etag.1">2</a>, <a href="#rfc.iref.e.1"><b>2.3</b></a>, <a href="#rfc.xref.header.etag.2">6.2</a>, <a href="#rfc.xref.header.etag.3">A</a></li> 1350 1329 </ul> 1351 1330 </li> … … 1370 1349 <li>Header Fields 1371 1350 <ul> 1372 <li>ETag <a href="#rfc.xref.header.etag.1">2</a>, <a href="#rfc.iref.h.2"><b>2.3</b></a>, <a href="#rfc.xref.header.etag.2"> 5.2</a>, <a href="#rfc.xref.header.etag.3">A</a></li>1373 <li>If-Match <a href="#rfc.iref.h.3"><b>3.1</b></a>, <a href="#rfc.xref.header.if-match.1"> 5.2</a></li>1374 <li>If-Modified-Since <a href="#rfc.iref.h.5"><b>3.3</b></a>, <a href="#rfc.xref.header.if-modified-since.1"> 5.2</a></li>1375 <li>If-None-Match <a href="#rfc.iref.h.4"><b>3.2</b></a>, <a href="#rfc.xref.header.if-none-match.1"> 5.2</a>, <a href="#rfc.xref.header.if-none-match.2">A</a></li>1376 <li>If-Unmodified-Since <a href="#rfc.iref.h.6"><b>3.4</b></a>, <a href="#rfc.xref.header.if-unmodified-since.1"> 5.2</a></li>1377 <li>Last-Modified <a href="#rfc.xref.header.last-modified.1">2</a>, <a href="#rfc.iref.h.1"><b>2.2</b></a>, <a href="#rfc.xref.header.last-modified.2"> 5.2</a></li>1351 <li>ETag <a href="#rfc.xref.header.etag.1">2</a>, <a href="#rfc.iref.h.2"><b>2.3</b></a>, <a href="#rfc.xref.header.etag.2">6.2</a>, <a href="#rfc.xref.header.etag.3">A</a></li> 1352 <li>If-Match <a href="#rfc.iref.h.3"><b>3.1</b></a>, <a href="#rfc.xref.header.if-match.1">6.2</a></li> 1353 <li>If-Modified-Since <a href="#rfc.iref.h.5"><b>3.3</b></a>, <a href="#rfc.xref.header.if-modified-since.1">6.2</a></li> 1354 <li>If-None-Match <a href="#rfc.iref.h.4"><b>3.2</b></a>, <a href="#rfc.xref.header.if-none-match.1">6.2</a>, <a href="#rfc.xref.header.if-none-match.2">A</a></li> 1355 <li>If-Unmodified-Since <a href="#rfc.iref.h.6"><b>3.4</b></a>, <a href="#rfc.xref.header.if-unmodified-since.1">6.2</a></li> 1356 <li>Last-Modified <a href="#rfc.xref.header.last-modified.1">2</a>, <a href="#rfc.iref.h.1"><b>2.2</b></a>, <a href="#rfc.xref.header.last-modified.2">6.2</a></li> 1378 1357 </ul> 1379 1358 </li> … … 1381 1360 </li> 1382 1361 <li><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul> 1383 <li>If-Match header field <a href="#rfc.iref.i.1"><b>3.1</b></a>, <a href="#rfc.xref.header.if-match.1"> 5.2</a></li>1384 <li>If-Modified-Since header field <a href="#rfc.iref.i.3"><b>3.3</b></a>, <a href="#rfc.xref.header.if-modified-since.1"> 5.2</a></li>1385 <li>If-None-Match header field <a href="#rfc.iref.i.2"><b>3.2</b></a>, <a href="#rfc.xref.header.if-none-match.1"> 5.2</a>, <a href="#rfc.xref.header.if-none-match.2">A</a></li>1386 <li>If-Unmodified-Since header field <a href="#rfc.iref.i.4"><b>3.4</b></a>, <a href="#rfc.xref.header.if-unmodified-since.1"> 5.2</a></li>1362 <li>If-Match header field <a href="#rfc.iref.i.1"><b>3.1</b></a>, <a href="#rfc.xref.header.if-match.1">6.2</a></li> 1363 <li>If-Modified-Since header field <a href="#rfc.iref.i.3"><b>3.3</b></a>, <a href="#rfc.xref.header.if-modified-since.1">6.2</a></li> 1364 <li>If-None-Match header field <a href="#rfc.iref.i.2"><b>3.2</b></a>, <a href="#rfc.xref.header.if-none-match.1">6.2</a>, <a href="#rfc.xref.header.if-none-match.2">A</a></li> 1365 <li>If-Unmodified-Since header field <a href="#rfc.iref.i.4"><b>3.4</b></a>, <a href="#rfc.xref.header.if-unmodified-since.1">6.2</a></li> 1387 1366 </ul> 1388 1367 </li> 1389 1368 <li><a id="rfc.index.L" href="#rfc.index.L"><b>L</b></a><ul> 1390 <li>Last-Modified header field <a href="#rfc.xref.header.last-modified.1">2</a>, <a href="#rfc.iref.l.1"><b>2.2</b></a>, <a href="#rfc.xref.header.last-modified.2"> 5.2</a></li>1369 <li>Last-Modified header field <a href="#rfc.xref.header.last-modified.1">2</a>, <a href="#rfc.iref.l.1"><b>2.2</b></a>, <a href="#rfc.xref.header.last-modified.2">6.2</a></li> 1391 1370 </ul> 1392 1371 </li> … … 1396 1375 </li> 1397 1376 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 1398 <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>1399 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1. 2">1.2</a></li>1400 <li><em>Section 2</em> <a href="#rfc.xref.Part1.1">1 .1</a></li>1401 <li><em>Section 3.2.1</em> <a href="#rfc.xref.Part1. 4">1.2</a></li>1402 <li><em>Section 3.2.4</em> <a href="#rfc.xref.Part1. 5">1.2</a></li>1403 <li><em>Section 4</em> <a href="#rfc.xref.Part1. 6">2.3.3</a></li>1404 <li><em>Section 9</em> <a href="#rfc.xref.Part1.8"> 7</a></li>1377 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">2.3.3</a>, <a href="#rfc.xref.Part1.3">5</a>, <a href="#rfc.xref.Part1.4">5</a>, <a href="#rfc.xref.Part1.5">5</a>, <a href="#rfc.xref.Part1.6">5</a>, <a href="#rfc.xref.Part1.7">7</a>, <a href="#rfc.xref.Part1.8">8</a>, <a href="#Part1"><b>9.1</b></a><ul> 1378 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.3">5</a></li> 1379 <li><em>Section 2</em> <a href="#rfc.xref.Part1.1">1</a></li> 1380 <li><em>Section 3.2.1</em> <a href="#rfc.xref.Part1.5">5</a></li> 1381 <li><em>Section 3.2.4</em> <a href="#rfc.xref.Part1.6">5</a></li> 1382 <li><em>Section 4</em> <a href="#rfc.xref.Part1.2">2.3.3</a></li> 1383 <li><em>Section 9</em> <a href="#rfc.xref.Part1.8">8</a></li> 1405 1384 </ul> 1406 1385 </li> 1407 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">1 .2</a>, <a href="#rfc.xref.Part2.2">1.2</a>, <a href="#rfc.xref.Part2.3">2.3.3</a>, <a href="#rfc.xref.Part2.4">2.3.3</a>, <a href="#rfc.xref.Part2.5">4.1</a>, <a href="#Part2"><b>8.1</b></a><ul>1408 <li><em>Section 5.1</em> <a href="#rfc.xref.Part2. 2">1.2</a></li>1409 <li><em>Section 8</em> <a href="#rfc.xref.Part2. 3">2.3.3</a></li>1410 <li><em>Section 9.3</em> <a href="#rfc.xref.Part2. 4">2.3.3</a></li>1411 <li><em>Section 9.10</em> <a href="#rfc.xref.Part2. 5">4.1</a></li>1386 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.3.3</a>, <a href="#rfc.xref.Part2.3">2.3.3</a>, <a href="#rfc.xref.Part2.4">4.1</a>, <a href="#rfc.xref.Part2.5">5</a>, <a href="#rfc.xref.Part2.6">5</a>, <a href="#Part2"><b>9.1</b></a><ul> 1387 <li><em>Section 5.1</em> <a href="#rfc.xref.Part2.6">5</a></li> 1388 <li><em>Section 8</em> <a href="#rfc.xref.Part2.2">2.3.3</a></li> 1389 <li><em>Section 9.3</em> <a href="#rfc.xref.Part2.3">2.3.3</a></li> 1390 <li><em>Section 9.10</em> <a href="#rfc.xref.Part2.4">4.1</a></li> 1412 1391 </ul> 1413 1392 </li> 1414 <li><em>Part5</em> <a href="#rfc.xref.Part5.1">3.3</a>, <a href="#rfc.xref.Part5.2">3.5</a>, <a href="#Part5"><b> 8.1</b></a><ul>1393 <li><em>Part5</em> <a href="#rfc.xref.Part5.1">3.3</a>, <a href="#rfc.xref.Part5.2">3.5</a>, <a href="#Part5"><b>9.1</b></a><ul> 1415 1394 <li><em>Section 5.3</em> <a href="#rfc.xref.Part5.2">3.5</a></li> 1416 1395 <li><em>Section 5.4</em> <a href="#rfc.xref.Part5.1">3.3</a></li> 1417 1396 </ul> 1418 1397 </li> 1419 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">1</a>, <a href="#rfc.xref.Part6.2">2.2.1</a>, <a href="#rfc.xref.Part6.3">2.3.1</a>, <a href="#Part6"><b> 8.1</b></a></li>1398 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">1</a>, <a href="#rfc.xref.Part6.2">2.2.1</a>, <a href="#rfc.xref.Part6.3">2.3.1</a>, <a href="#Part6"><b>9.1</b></a></li> 1420 1399 </ul> 1421 1400 </li> 1422 1401 <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul> 1423 <li><em>RFC2119</em> <a href="#rfc.xref.RFC2119.1"> 1.1</a>, <a href="#RFC2119"><b>8.1</b></a></li>1424 <li><em>RFC2616</em> <a href="#rfc.xref.RFC2616.1">2.3</a>, <a href="#RFC2616"><b> 8.2</b></a><ul>1402 <li><em>RFC2119</em> <a href="#rfc.xref.RFC2119.1">5</a>, <a href="#RFC2119"><b>9.1</b></a></li> 1403 <li><em>RFC2616</em> <a href="#rfc.xref.RFC2616.1">2.3</a>, <a href="#RFC2616"><b>9.2</b></a><ul> 1425 1404 <li><em>Section 3.11</em> <a href="#rfc.xref.RFC2616.1">2.3</a></li> 1426 1405 </ul> 1427 1406 </li> 1428 <li><em>RFC3864</em> <a href="#rfc.xref.RFC3864.1"> 5.2</a>, <a href="#RFC3864"><b>8.2</b></a></li>1429 <li><em>RFC4918</em> <a href="#rfc.xref.RFC4918.1">2</a>, <a href="#RFC4918"><b> 8.2</b></a></li>1430 <li><em>RFC5234</em> <a href="#rfc.xref.RFC5234.1"> 1.2</a>, <a href="#rfc.xref.RFC5234.2">1.2</a>, <a href="#RFC5234"><b>8.1</b></a><ul>1431 <li><em>Appendix B.1</em> <a href="#rfc.xref.RFC5234.2"> 1.2</a></li>1407 <li><em>RFC3864</em> <a href="#rfc.xref.RFC3864.1">6.2</a>, <a href="#RFC3864"><b>9.2</b></a></li> 1408 <li><em>RFC4918</em> <a href="#rfc.xref.RFC4918.1">2</a>, <a href="#RFC4918"><b>9.2</b></a></li> 1409 <li><em>RFC5234</em> <a href="#rfc.xref.RFC5234.1">5</a>, <a href="#rfc.xref.RFC5234.2">5</a>, <a href="#RFC5234"><b>9.1</b></a><ul> 1410 <li><em>Appendix B.1</em> <a href="#rfc.xref.RFC5234.2">5</a></li> 1432 1411 </ul> 1433 1412 </li> … … 1438 1417 <li>Status Codes 1439 1418 <ul> 1440 <li>304 Not Modified <a href="#rfc.iref.s.2"><b>4.1</b></a>, <a href="#rfc.xref.status.304.1"> 5.1</a></li>1441 <li>412 Precondition Failed <a href="#rfc.iref.s.3"><b>4.2</b></a>, <a href="#rfc.xref.status.412.1"> 5.1</a></li>1419 <li>304 Not Modified <a href="#rfc.iref.s.2"><b>4.1</b></a>, <a href="#rfc.xref.status.304.1">6.1</a></li> 1420 <li>412 Precondition Failed <a href="#rfc.iref.s.3"><b>4.2</b></a>, <a href="#rfc.xref.status.412.1">6.1</a></li> 1442 1421 </ul> 1443 1422 </li> -
draft-ietf-httpbis/latest/p4-conditional.xml
r1773 r1783 105 105 <t> 106 106 The Hypertext Transfer Protocol (HTTP) is an application-level protocol for 107 distributed, collaborative, hypertext information systems. HTTP has been in 108 use by the World Wide Web global information initiative since 1990. This 109 document is Part 4 of the seven-part specification that defines the protocol 110 referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. 111 </t> 112 <t> 113 Part 4 defines request header fields for indicating conditional requests and 114 the rules for constructing responses to those requests. 107 distributed, collaborative, hypertext information systems. This document 108 defines HTTP/1.1 conditional requests, including metadata header fields 109 for indicating state changes, request header fields for making 110 preconditions on such state, and rules for constructing the responses to a 111 conditional request when one or more preconditions evaluate to false. 115 112 </t> 116 113 </abstract> … … 133 130 </note> 134 131 </front> 132 135 133 <middle> 136 134 <section title="Introduction" anchor="introduction"> 137 135 <t> 138 This document defines the HTTP/1.1 conditional request mechanisms, 139 including both metadata for indicating/observing changes in resource 140 representations and request header fields that specify preconditions 141 on that metadata; to be checked before performing the request method. 136 Conditional requests are HTTP requests <xref target="Part2"/> that include 137 one or more header fields indicating a precondition to be tested before 138 applying the method semantics to the target resource. 139 Each precondition is based on metadata that is expected to change if the 140 selected representation of the target resource is changed. 141 This document defines the HTTP/1.1 conditional request mechanisms in terms 142 of the architecture, syntax notation, and conformance criteria defined in 143 &architecture;. 144 </t> 145 <t> 142 146 Conditional GET requests are the most efficient mechanism for HTTP 143 147 cache updates &caching;. Conditionals can also be … … 167 171 for the selected representation. 168 172 </t> 169 170 <section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling">171 <t>172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this174 document are to be interpreted as described in <xref target="RFC2119"/>.175 </t>176 <t>177 This specification targets conformance criteria according to the role of178 a participant in HTTP communication. Hence, HTTP requirements are placed179 on senders, recipients, clients, servers, user agents, intermediaries,180 origin servers, proxies, gateways, or caches, depending on what behavior181 is being constrained by the requirement. See &architecture; for definitions182 of these terms.183 </t>184 <t>185 The verb "generate" is used instead of "send" where a requirement186 differentiates between creating a protocol element and merely forwarding a187 received element downstream.188 </t>189 <t>190 An implementation is considered conformant if it complies with all of the191 requirements associated with the roles it partakes in HTTP. Note that192 SHOULD-level requirements are relevant here, unless one of the documented193 exceptions is applicable.194 </t>195 <t>196 This document also uses ABNF to define valid protocol elements197 (<xref target="notation"/>).198 In addition to the prose requirements placed upon them, senders &MUST-NOT;199 generate protocol elements that do not match the grammar defined by the200 ABNF rules for those protocol elements that are applicable to the sender's201 role. If a received protocol element is processed, the recipient &MUST; be202 able to parse any value that would match the ABNF rules for that protocol203 element, excluding only those rules not applicable to the recipient's role.204 </t>205 <t>206 Unless noted otherwise, a recipient &MAY; attempt to recover a usable207 protocol element from an invalid construct. HTTP does not define208 specific error handling mechanisms except when they have a direct impact209 on security, since different applications of the protocol require210 different error handling strategies. For example, a Web browser might211 wish to transparently recover from a response where the212 <x:ref>Location</x:ref> header field doesn't parse according to the ABNF,213 whereas a systems control client might consider any form of error recovery214 to be dangerous.215 </t>216 </section>217 218 <section title="Syntax Notation" anchor="notation">219 <x:anchor-alias value="ALPHA"/>220 <x:anchor-alias value="CR"/>221 <x:anchor-alias value="DIGIT"/>222 <x:anchor-alias value="DQUOTE"/>223 <x:anchor-alias value="LF"/>224 <x:anchor-alias value="OCTET"/>225 <x:anchor-alias value="VCHAR"/>226 <x:anchor-alias value="core.rules"/>227 <x:anchor-alias value="obs-text"/>228 <x:anchor-alias value="OWS"/>229 <x:anchor-alias value="HTTP-date"/>230 <t>231 This specification uses the Augmented Backus-Naur Form (ABNF) notation232 of <xref target="RFC5234"/> with the list rule extension defined in233 ¬ation;. <xref target="collected.abnf"/> shows the collected ABNF234 with the list rule expanded.235 </t>236 <t>237 The following core rules are included by238 reference, as defined in <xref target="RFC5234" x:fmt="," x:sec="B.1"/>:239 ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls),240 DIGIT (decimal 0-9), DQUOTE (double quote),241 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed),242 OCTET (any 8-bit sequence of data), SP (space), and243 VCHAR (any visible US-ASCII character).244 </t>245 <t>246 The ABNF rules below are defined in <xref target="Part1"/> and247 <xref target="Part2"/>:248 </t>249 <figure><artwork type="abnf2616">250 <x:ref>OWS</x:ref> = <OWS, defined in &whitespace;>251 <x:ref>obs-text</x:ref> = <obs-text, defined in &field-components;>252 <x:ref>HTTP-date</x:ref> = <HTTP-date, defined in &http-date;>253 </artwork></figure>254 </section>255 173 </section> 256 174 … … 1084 1002 </t> 1085 1003 </section> 1004 </section> 1005 1006 <section title="ABNF Rules Defined Elsewhere" anchor="abnf.dependencies"> 1007 <x:anchor-alias value="ALPHA"/> 1008 <x:anchor-alias value="CR"/> 1009 <x:anchor-alias value="DIGIT"/> 1010 <x:anchor-alias value="DQUOTE"/> 1011 <x:anchor-alias value="LF"/> 1012 <x:anchor-alias value="OCTET"/> 1013 <x:anchor-alias value="VCHAR"/> 1014 <x:anchor-alias value="core.rules"/> 1015 <x:anchor-alias value="obs-text"/> 1016 <x:anchor-alias value="OWS"/> 1017 <x:anchor-alias value="HTTP-date"/> 1018 <t> 1019 This specification uses the Augmented Backus-Naur Form (ABNF) notation 1020 of <xref target="RFC5234"/> with the list rule extension defined in 1021 ¬ation;. <xref target="collected.abnf"/> shows the collected ABNF 1022 with the list rule expanded. 1023 </t> 1024 <t> 1025 The following core rules are included by 1026 reference, as defined in <xref target="RFC5234" x:fmt="," x:sec="B.1"/>: 1027 ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), 1028 DIGIT (decimal 0-9), DQUOTE (double quote), 1029 HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), 1030 OCTET (any 8-bit sequence of data), SP (space), and 1031 VCHAR (any visible US-ASCII character). 1032 </t> 1033 <t> 1034 The ABNF rules below are defined in <xref target="Part1"/> and 1035 <xref target="Part2"/>: 1036 </t> 1037 <figure><artwork type="abnf2616"> 1038 <x:ref>OWS</x:ref> = <OWS, defined in &whitespace;> 1039 <x:ref>obs-text</x:ref> = <obs-text, defined in &field-components;> 1040 <x:ref>HTTP-date</x:ref> = <HTTP-date, defined in &http-date;> 1041 </artwork></figure> 1042 <t> 1043 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 1044 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 1045 document are to be interpreted as described in <xref target="RFC2119"/>. 1046 </t> 1086 1047 </section> 1087 1048
Note: See TracChangeset
for help on using the changeset viewer.