Changeset 1251 for draft-ietf-httpbis
- Timestamp:
- 31/03/11 12:11:25 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p4-conditional.html
r1243 r1251 359 359 } 360 360 @bottom-center { 361 content: "Expires October 1, 2011";361 content: "Expires October 2, 2011"; 362 362 } 363 363 @bottom-right { … … 382 382 <link rel="Index" href="#rfc.index"> 383 383 <link rel="Chapter" title="1 Introduction" href="#rfc.section.1"> 384 <link rel="Chapter" title="2 Entity-Tags" href="#rfc.section.2">384 <link rel="Chapter" title="2 Resource State Metadata" href="#rfc.section.2"> 385 385 <link rel="Chapter" title="3 Status Code Definitions" href="#rfc.section.3"> 386 386 <link rel="Chapter" title="4 Weak and Strong Validators" href="#rfc.section.4"> … … 406 406 <meta name="dct.creator" content="Reschke, J. F."> 407 407 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest"> 408 <meta name="dct.issued" scheme="ISO8601" content="2011-03-3 0">408 <meta name="dct.issued" scheme="ISO8601" content="2011-03-31"> 409 409 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 410 410 <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."> … … 432 432 </tr> 433 433 <tr> 434 <td class="left">Expires: October 1, 2011</td>434 <td class="left">Expires: October 2, 2011</td> 435 435 <td class="right">J. Mogul</td> 436 436 </tr> … … 489 489 <tr> 490 490 <td class="left"></td> 491 <td class="right">March 3 0, 2011</td>491 <td class="right">March 31, 2011</td> 492 492 </tr> 493 493 </tbody> … … 515 515 in progress”. 516 516 </p> 517 <p>This Internet-Draft will expire on October 1, 2011.</p>517 <p>This Internet-Draft will expire on October 2, 2011.</p> 518 518 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 519 519 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 535 535 <li>1. <a href="#introduction">Introduction</a><ul> 536 536 <li>1.1 <a href="#intro.requirements">Requirements</a></li> 537 <li>1.2 <a href="#notation">Syntax Notation</a><ul> 538 <li>1.2.1 <a href="#core.rules">Core Rules</a></li> 539 <li>1.2.2 <a href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></li> 537 <li>1.2 <a href="#notation">Syntax Notation</a></li> 538 </ul> 539 </li> 540 <li>2. <a href="#resource.metadata">Resource State Metadata</a><ul> 541 <li>2.1 <a href="#entity.tags">Entity Tags</a><ul> 542 <li>2.1.1 <a href="#example.entity.tag.vs.conneg">Example: Entity-tags varying on Content-Negotiated Resources</a></li> 540 543 </ul> 541 544 </li> 542 </ul>543 </li>544 <li>2. <a href="#entity.tags">Entity-Tags</a><ul>545 <li>2.1 <a href="#example.entity.tag.vs.conneg">Example: Entity-tags varying on Content-Negotiated Resources</a></li>546 545 </ul> 547 546 </li> … … 598 597 </ul> 599 598 <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a id="introduction" href="#introduction">Introduction</a></h1> 600 <p id="rfc.section.1.p.1">This document defines HTTP/1.1 response metadata for indicating potential changes to payload content, including modification601 time stamps and opaque entity-tags, and the HTTP conditional request mechanisms that allow preconditions to be placed on a602 request method. Conditional GET requests allow for efficient cache updates. Other conditional request methods are used to603 protect against overwriting or misunderstanding the state of a resource that has been changed unbeknownst to the requesting604 client.605 </p> 606 <p id="rfc.section.1.p.2"> <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 and sent as payload in a 200607 (OK) response if the same request had used the method GET and had excluded all of the conditional request header fields. The608 conditions found within conditional requests are evaluated on the basis of either the state of the target resource as a whole609 or the state of the target resource's selected representation.610 </p>611 <p id="rfc.section.1.p.3">This document is currently disorganized in order to minimize the changes between drafts and enable reviewers to see the smaller612 errata changes. A future draft will reorganize the sections to better reflect the content. In particular, the sections on613 resource metadata will be discussed first and then followed by each conditional request header field, concluding with a definition614 of precedence and the expectation of ordering strong validator checks before weak validator checks. It is likely that more615 content from <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a> will migrate to this part, where appropriate. The current mess reflects how widely dispersed these topics and associated requirements616 had become in <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.599 <p id="rfc.section.1.p.1">This document defines the HTTP/1.1 conditional request mechanisms, including both response metadata that can be used to indicate 600 or observe changes to resource state and request header fields that specify preconditions to be checked before performing 601 the action given by the request method. Conditional GET requests are the most efficient mechanism for HTTP cache updates. 602 Conditionals can be applied to state-changing methods, such as PUT and DELETE, to prevent the "lost update" problem: one client 603 accidentally overwriting the work of another client that has been acting in parallel. 604 </p> 605 <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 the 606 state as observed in a previously obtained representation (one value in that set). A resource might have multiple current 607 representations, each with its own observable state. The conditional request mechanisms assume that the mapping of requests 608 to corresponding representations will be consistent over time if the server intends to take advantage of conditionals. Regardless, 609 if the mapping is inconsistent and the server is unable to select the appropriate representation, then no harm will result 610 when the precondition evaluates to false. 611 </p> 612 <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 if 613 the same request had used the method GET and had excluded all of the conditional request header fields. The conditional request 614 preconditions are evaluated by comparing the values provided in the request header fields to the current metadata for the 615 selected representation. 617 616 </p> 618 617 <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> … … 632 631 and WSP (whitespace). 633 632 </p> 634 <h3 id="rfc.section.1.2.1"><a href="#rfc.section.1.2.1">1.2.1</a> <a id="core.rules" href="#core.rules">Core Rules</a></h3> 635 <p id="rfc.section.1.2.1.p.1">The core rules below are defined in <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.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>: 636 </p> 637 <div id="rfc.figure.u.1"></div><pre class="inline"> <a href="#core.rules" class="smpl">quoted-string</a> = <quoted-string, 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>> 638 <a href="#core.rules" 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>> 639 </pre><h3 id="rfc.section.1.2.2"><a href="#rfc.section.1.2.2">1.2.2</a> <a id="abnf.dependencies" href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></h3> 640 <p id="rfc.section.1.2.2.p.1">The ABNF rules below are defined in other parts:</p> 641 <div id="rfc.figure.u.2"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">HTTP-date</a> = <HTTP-date, 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#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a>> 642 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="entity.tags" href="#entity.tags">Entity-Tags</a></h1> 643 <p id="rfc.section.2.p.1">Entity-tags are used for comparing two or more representations of the same resource. HTTP/1.1 uses entity-tags in the ETag 633 <p id="rfc.section.1.2.p.3">The ABNF rules below are defined in other parts:</p> 634 <div id="rfc.figure.u.1"></div><pre class="inline"> <a href="#notation" class="smpl">quoted-string</a> = <quoted-string, 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>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>> 635 <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>> 636 <a href="#notation" class="smpl">HTTP-date</a> = <HTTP-date, 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#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a>> 637 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="resource.metadata" href="#resource.metadata">Resource State Metadata</a></h1> 638 <p id="rfc.section.2.p.1">This specification defines two forms of metadata that are commonly used to observe resource state and test for preconditions: 639 modification dates and opaque entity tags. Additional metadata that reflects resource state has been defined by various extensions 640 of HTTP, such as WebDAV <a href="#RFC4918" id="rfc.xref.RFC4918.1"><cite title="HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)">[RFC4918]</cite></a>, that are beyond the scope of this specification. 641 </p> 642 <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> <a id="entity.tags" href="#entity.tags">Entity Tags</a></h2> 643 <p id="rfc.section.2.1.p.1">Entity-tags are used for comparing two or more representations of the same resource. HTTP/1.1 uses entity-tags in the ETag 644 644 (<a href="#header.etag" id="rfc.xref.header.etag.1" title="ETag">Section 6.1</a>), If-Match (<a href="#header.if-match" id="rfc.xref.header.if-match.1" title="If-Match">Section 6.2</a>), If-None-Match (<a href="#header.if-none-match" id="rfc.xref.header.if-none-match.1" title="If-None-Match">Section 6.4</a>), and If-Range (<a href="p5-range.html#header.if-range" title="If-Range">Section 5.3</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) header fields. The definition of how they are used and compared as cache validators is in <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a>. An entity-tag consists of an opaque quoted string, possibly prefixed by a weakness indicator. 645 645 </p> 646 <div id="rfc.figure.u. 3"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span><span id="rfc.iref.g.3"></span> <a href="#entity.tags" class="smpl">entity-tag</a> = [ <a href="#entity.tags" class="smpl">weak</a> ] <a href="#entity.tags" class="smpl">opaque-tag</a>646 <div id="rfc.figure.u.2"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span><span id="rfc.iref.g.3"></span> <a href="#entity.tags" class="smpl">entity-tag</a> = [ <a href="#entity.tags" class="smpl">weak</a> ] <a href="#entity.tags" class="smpl">opaque-tag</a> 647 647 <a href="#entity.tags" class="smpl">weak</a> = %x57.2F ; "W/", case-sensitive 648 <a href="#entity.tags" class="smpl">opaque-tag</a> = <a href="# core.rules" class="smpl">quoted-string</a>649 </pre><p id="rfc.section.2. p.3">A "strong entity-tag" <em class="bcp14">MAY</em> be shared by two representations of a resource only if they are equivalent by octet equality.650 </p> 651 <p id="rfc.section.2. p.4">A "weak entity-tag", indicated by the "W/" prefix, <em class="bcp14">MAY</em> be shared by two representations of a resource. A weak entity-tag can only be used for weak comparison.652 </p> 653 <p id="rfc.section.2. p.5">Cache entries might persist for arbitrarily long periods, regardless of expiration times, so it is inappropriate to expect648 <a href="#entity.tags" class="smpl">opaque-tag</a> = <a href="#notation" class="smpl">quoted-string</a> 649 </pre><p id="rfc.section.2.1.p.3">A "strong entity-tag" <em class="bcp14">MAY</em> be shared by two representations of a resource only if they are equivalent by octet equality. 650 </p> 651 <p id="rfc.section.2.1.p.4">A "weak entity-tag", indicated by the "W/" prefix, <em class="bcp14">MAY</em> be shared by two representations of a resource. A weak entity-tag can only be used for weak comparison. 652 </p> 653 <p id="rfc.section.2.1.p.5">Cache entries might persist for arbitrarily long periods, regardless of expiration times, so it is inappropriate to expect 654 654 that a cache will never again attempt to validate an entry using a validator that it obtained at some point in the past. A 655 655 strong entity-tag <em class="bcp14">MUST</em> be unique across all versions of all representations associated with a particular resource over time. However, there is no … … 657 657 of multiple resources at the same time and does not imply that those representations are equivalent). 658 658 </p> 659 <h 2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> <a id="example.entity.tag.vs.conneg" href="#example.entity.tag.vs.conneg">Example: Entity-tags varying on Content-Negotiated Resources</a></h2>660 <p id="rfc.section.2.1. p.1">Consider a resource that is subject to content negotiation (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), and where the representations returned upon a GET request vary based on the Accept-Encoding request header field (<a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 6.3</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>):661 </p> 662 <div id="rfc.figure.u. 4"></div>659 <h3 id="rfc.section.2.1.1"><a href="#rfc.section.2.1.1">2.1.1</a> <a id="example.entity.tag.vs.conneg" href="#example.entity.tag.vs.conneg">Example: Entity-tags varying on Content-Negotiated Resources</a></h3> 660 <p id="rfc.section.2.1.1.p.1">Consider a resource that is subject to content negotiation (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), and where the representations returned upon a GET request vary based on the Accept-Encoding request header field (<a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 6.3</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>): 661 </p> 662 <div id="rfc.figure.u.3"></div> 663 663 <p>>> Request:</p><pre class="text2">GET /index HTTP/1.1 664 664 Host: www.example.com 665 665 Accept-Encoding: gzip 666 666 667 </pre><p id="rfc.section.2.1. 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>668 <div id="rfc.figure.u. 5"></div>667 </pre><p id="rfc.section.2.1.1.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> 668 <div id="rfc.figure.u.4"></div> 669 669 <p>>> Response:</p><pre class="text">HTTP/1.1 200 OK 670 670 Date: Thu, 26 Mar 2010 00:05:00 GMT … … 679 679 Hello World! 680 680 Hello World! 681 </span></pre><p id="rfc.section.2.1. p.5">An alternative representation that does use gzip content coding would be:</p>682 <div id="rfc.figure.u. 6"></div>681 </span></pre><p id="rfc.section.2.1.1.p.5">An alternative representation that does use gzip content coding would be:</p> 682 <div id="rfc.figure.u.5"></div> 683 683 <p>>> Response:</p><pre class="text">HTTP/1.1 200 OK 684 684 Date: Thu, 26 Mar 2010 00:05:00 GMT … … 689 689 Content-Encoding: gzip 690 690 691 <em>...binary data...</em></pre><div class="note" id="rfc.section.2.1. p.7">691 <em>...binary data...</em></pre><div class="note" id="rfc.section.2.1.1.p.7"> 692 692 <p> <b>Note:</b> Content codings are a property of the representation, so therefore an entity-tag of an encoded representation must be distinct 693 693 from an unencoded representation to prevent conflicts during cache updates and range requests. In contrast, transfer codings 694 (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 6.2</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.694 (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 6.2</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. 695 695 </p> 696 696 </div> … … 705 705 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. 706 706 </p> 707 <p id="rfc.section.3.1.p.2">A 304 response <em class="bcp14">MUST</em> include a Date header field (<a href="p1-messaging.html#header.date" title="Date">Section 9.3</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>) unless its omission is required by <a href="p1-messaging.html#clockless.origin.server.operation" title="Clockless Origin Server Operation">Section 9.3.1</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>. If a 200 response to the same request would have included any of the header fields Cache-Control, Content-Location, ETag,707 <p id="rfc.section.3.1.p.2">A 304 response <em class="bcp14">MUST</em> include a Date header field (<a href="p1-messaging.html#header.date" title="Date">Section 9.3</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>) unless its omission is required by <a href="p1-messaging.html#clockless.origin.server.operation" title="Clockless Origin Server Operation">Section 9.3.1</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>. If a 200 response to the same request would have included any of the header fields Cache-Control, Content-Location, ETag, 708 708 Expires, Last-Modified, or Vary, then those same header fields <em class="bcp14">MUST</em> be sent in a 304 response. 709 709 </p> … … 810 810 </table> 811 811 </div> 812 <p id="rfc.section.4.p.9">An entity-tag is strong unless it is explicitly tagged as weak. <a href="#entity.tags" title="Entity -Tags">Section 2</a> gives the syntax for entity-tags.812 <p id="rfc.section.4.p.9">An entity-tag is strong unless it is explicitly tagged as weak. <a href="#entity.tags" title="Entity Tags">Section 2.1</a> gives the syntax for entity-tags. 813 813 </p> 814 814 <p id="rfc.section.4.p.10">A Last-Modified time, when used as a validator in a request, is implicitly weak unless it is possible to deduce that it is … … 907 907 <div id="rfc.iref.h.1"></div> 908 908 <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a id="header.etag" href="#header.etag">ETag</a></h2> 909 <p id="rfc.section.6.1.p.1">The "ETag" header field provides the current value of the entity-tag (see <a href="#entity.tags" title="Entity -Tags">Section 2</a>) for one representation of the target resource. An entity-tag is intended for use as a resource-local identifier for differentiating909 <p id="rfc.section.6.1.p.1">The "ETag" header field provides the current value of the entity-tag (see <a href="#entity.tags" title="Entity Tags">Section 2.1</a>) for one representation of the target resource. An entity-tag is intended for use as a resource-local identifier for differentiating 910 910 between representations of the same resource that vary over time or via content negotiation (see <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a>). 911 911 </p> 912 <div id="rfc.figure.u. 7"></div><pre class="inline"><span id="rfc.iref.g.4"></span> <a href="#header.etag" class="smpl">ETag</a> = <a href="#entity.tags" class="smpl">entity-tag</a>913 </pre><div id="rfc.figure.u. 8"></div>912 <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.4"></span> <a href="#header.etag" class="smpl">ETag</a> = <a href="#entity.tags" class="smpl">entity-tag</a> 913 </pre><div id="rfc.figure.u.7"></div> 914 914 <p>Examples:</p> <pre class="text"> ETag: "xyzzy" 915 915 ETag: W/"xyzzy" … … 932 932 An If-Match field-value of "*" places the precondition on the existence of any current representation for the target resource. 933 933 </p> 934 <div id="rfc.figure.u. 9"></div><pre class="inline"><span id="rfc.iref.g.5"></span> <a href="#header.if-match" class="smpl">If-Match</a> = "*" / 1#<a href="#entity.tags" class="smpl">entity-tag</a>934 <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.5"></span> <a href="#header.if-match" class="smpl">If-Match</a> = "*" / 1#<a href="#entity.tags" class="smpl">entity-tag</a> 935 935 </pre><p id="rfc.section.6.2.p.3">If any of the entity-tags listed in the If-Match field value match the entity-tag of the selected representation for the target 936 936 resource, or if "*" is given and any current representation exists for the target resource, then the server <em class="bcp14">MAY</em> perform the request method as if the If-Match header field was not present. … … 942 942 </p> 943 943 <p id="rfc.section.6.2.p.6">Examples:</p> 944 <div id="rfc.figure.u. 10"></div><pre class="text"> If-Match: "xyzzy"944 <div id="rfc.figure.u.9"></div><pre class="text"> If-Match: "xyzzy" 945 945 If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" 946 946 If-Match: * … … 954 954 the time specified in this field, then do not perform the request method; instead, respond as detailed below. 955 955 </p> 956 <div id="rfc.figure.u.1 1"></div><pre class="inline"><span id="rfc.iref.g.6"></span> <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> = <a href="#abnf.dependencies" class="smpl">HTTP-date</a>956 <div id="rfc.figure.u.10"></div><pre class="inline"><span id="rfc.iref.g.6"></span> <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> = <a href="#notation" class="smpl">HTTP-date</a> 957 957 </pre><p id="rfc.section.6.3.p.3">An example of the field is:</p> 958 <div id="rfc.figure.u.1 2"></div><pre class="text"> If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT958 <div id="rfc.figure.u.11"></div><pre class="text"> If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT 959 959 </pre><p id="rfc.section.6.3.p.5">A GET method with an If-Modified-Since header field and no Range header field requests that the selected representation be 960 960 transferred only if it has been modified since the date given by the If-Modified-Since header field. The algorithm for determining … … 1009 1009 for the target resource. 1010 1010 </p> 1011 <div id="rfc.figure.u.1 3"></div><pre class="inline"><span id="rfc.iref.g.7"></span> <a href="#header.if-none-match" class="smpl">If-None-Match</a> = "*" / 1#<a href="#entity.tags" class="smpl">entity-tag</a>1011 <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.7"></span> <a href="#header.if-none-match" class="smpl">If-None-Match</a> = "*" / 1#<a href="#entity.tags" class="smpl">entity-tag</a> 1012 1012 </pre><p id="rfc.section.6.4.p.4">If any of the entity-tags listed in the If-None-Match field-value match the entity-tag of the selected representation, or 1013 1013 if "*" is given and any current representation exists for that resource, then the server <em class="bcp14">MUST NOT</em> perform the requested method. Instead, if the request method was GET or HEAD, the server <em class="bcp14">SHOULD</em> respond with a 304 (Not Modified) status code, including the cache-related header fields (particularly ETag) of the selected … … 1020 1020 </p> 1021 1021 <p id="rfc.section.6.4.p.7">Examples:</p> 1022 <div id="rfc.figure.u.1 4"></div><pre class="text"> If-None-Match: "xyzzy"1022 <div id="rfc.figure.u.13"></div><pre class="text"> If-None-Match: "xyzzy" 1023 1023 If-None-Match: W/"xyzzy" 1024 1024 If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" … … 1035 1035 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. 1036 1036 </p> 1037 <div id="rfc.figure.u.1 5"></div><pre class="inline"><span id="rfc.iref.g.8"></span> <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> = <a href="#abnf.dependencies" class="smpl">HTTP-date</a>1037 <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.8"></span> <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> = <a href="#notation" class="smpl">HTTP-date</a> 1038 1038 </pre><p id="rfc.section.6.5.p.3">An example of the field is:</p> 1039 <div id="rfc.figure.u.1 6"></div><pre class="text"> If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT1039 <div id="rfc.figure.u.15"></div><pre class="text"> If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT 1040 1040 </pre><p id="rfc.section.6.5.p.5">If the request normally (i.e., without the If-Unmodified-Since header field) would result in anything other than a 2xx or 1041 1041 412 status code, the If-Unmodified-Since header field <em class="bcp14">SHOULD</em> be ignored. … … 1052 1052 modified. 1053 1053 </p> 1054 <div id="rfc.figure.u.1 7"></div><pre class="inline"><span id="rfc.iref.g.9"></span> <a href="#header.last-modified" class="smpl">Last-Modified</a> = <a href="#abnf.dependencies" class="smpl">HTTP-date</a>1054 <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.9"></span> <a href="#header.last-modified" class="smpl">Last-Modified</a> = <a href="#notation" class="smpl">HTTP-date</a> 1055 1055 </pre><p id="rfc.section.6.6.p.3">An example of its use is</p> 1056 <div id="rfc.figure.u.1 8"></div><pre class="text"> Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT1056 <div id="rfc.figure.u.17"></div><pre class="text"> Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT 1057 1057 </pre><p id="rfc.section.6.6.p.5">A representation is typically the sum of many parts behind the resource interface. The last-modified time would usually be 1058 1058 the most recent time that any of those parts were changed. How that value is determined for any given resource is an implementation … … 1164 1164 <p id="rfc.section.7.2.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p> 1165 1165 <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1> 1166 <p id="rfc.section.8.p.1">No additional security considerations have been identified beyond those applicable to HTTP in general <a href="#Part1" id="rfc.xref.Part1. 9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.1166 <p id="rfc.section.8.p.1">No additional security considerations have been identified beyond those applicable to HTTP in general <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 1167 1167 </p> 1168 1168 <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a id="ack" href="#ack">Acknowledgments</a></h1> … … 1205 1205 <h2 id="rfc.references.2"><a href="#rfc.section.10.2" id="rfc.section.10.2">10.2</a> Informative References 1206 1206 </h2> 1207 <table> 1207 <table> 1208 1208 <tr> 1209 1209 <td class="reference"><b id="RFC2616">[RFC2616]</b></td> … … 1214 1214 <td class="reference"><b id="RFC3864">[RFC3864]</b></td> 1215 1215 <td class="top"><a href="mailto:GK-IETF@ninebynine.org" title="Nine by Nine">Klyne, G.</a>, <a href="mailto:mnot@pobox.com" title="BEA Systems">Nottingham, M.</a>, and <a href="mailto:JeffMogul@acm.org" title="HP Labs">J. Mogul</a>, “<a href="http://tools.ietf.org/html/rfc3864">Registration Procedures for Message Header Fields</a>”, BCP 90, RFC 3864, September 2004. 1216 </td> 1217 </tr> 1218 <tr> 1219 <td class="reference"><b id="RFC4918">[RFC4918]</b></td> 1220 <td class="top"><a href="mailto:ldusseault@commerce.net" title="CommerceNet">Dusseault, L., Ed.</a>, “<a href="http://tools.ietf.org/html/rfc4918">HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)</a>”, RFC 4918, June 2007. 1216 1221 </td> 1217 1222 </tr> … … 1241 1246 </p> 1242 1247 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 1243 <div id="rfc.figure.u.1 9"></div> <pre class="inline"><a href="#header.etag" class="smpl">ETag</a> = entity-tag1244 1245 <a href="# abnf.dependencies" class="smpl">HTTP-date</a> = <HTTP-date, defined in [Part1], Section 6.1>1248 <div id="rfc.figure.u.18"></div> <pre class="inline"><a href="#header.etag" class="smpl">ETag</a> = entity-tag 1249 1250 <a href="#notation" class="smpl">HTTP-date</a> = <HTTP-date, defined in [Part1], Section 6.1> 1246 1251 1247 1252 <a href="#header.if-match" class="smpl">If-Match</a> = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS … … 1254 1259 <a href="#header.last-modified" class="smpl">Last-Modified</a> = HTTP-date 1255 1260 1256 <a href="# core.rules" class="smpl">OWS</a> = <OWS, defined in [Part1], Section 1.2.2>1261 <a href="#notation" class="smpl">OWS</a> = <OWS, defined in [Part1], Section 1.2.2> 1257 1262 1258 1263 <a href="#entity.tags" class="smpl">entity-tag</a> = [ weak ] opaque-tag … … 1260 1265 <a href="#entity.tags" class="smpl">opaque-tag</a> = quoted-string 1261 1266 1262 <a href="# core.rules" class="smpl">quoted-string</a> = <quoted-string, defined in [Part1], Section 1.2.2>1267 <a href="#notation" class="smpl">quoted-string</a> = <quoted-string, defined in [Part1], Section 1.2.2> 1263 1268 1264 1269 <a href="#entity.tags" class="smpl">weak</a> = %x57.2F ; W/ 1265 </pre> <div id="rfc.figure.u. 20"></div>1270 </pre> <div id="rfc.figure.u.19"></div> 1266 1271 <p>ABNF diagnostics:</p><pre class="inline">; ETag defined but not used 1267 1272 ; If-Match defined but not used … … 1273 1278 <h2 id="rfc.section.C.1"><a href="#rfc.section.C.1">C.1</a> Since RFC 2616 1274 1279 </h2> 1275 <p id="rfc.section.C.1.p.1">Extracted relevant partitions from <a href="#RFC2616" id="rfc.xref.RFC2616. 2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.1280 <p id="rfc.section.C.1.p.1">Extracted relevant partitions from <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. 1276 1281 </p> 1277 1282 <h2 id="rfc.section.C.2"><a href="#rfc.section.C.2">C.2</a> Since draft-ietf-httpbis-p4-conditional-00 … … 1388 1393 </li> 1389 1394 <li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul> 1390 <li>ETag header field <a href="#rfc.xref.header.etag.1">2 </a>, <a href="#rfc.iref.e.1"><b>6.1</b></a>, <a href="#rfc.xref.header.etag.2">7.2</a></li>1395 <li>ETag header field <a href="#rfc.xref.header.etag.1">2.1</a>, <a href="#rfc.iref.e.1"><b>6.1</b></a>, <a href="#rfc.xref.header.etag.2">7.2</a></li> 1391 1396 </ul> 1392 1397 </li> … … 1394 1399 <li><tt>Grammar</tt> 1395 1400 <ul> 1396 <li><tt>entity-tag</tt> <a href="#rfc.iref.g.1"><b>2 </b></a></li>1401 <li><tt>entity-tag</tt> <a href="#rfc.iref.g.1"><b>2.1</b></a></li> 1397 1402 <li><tt>ETag</tt> <a href="#rfc.iref.g.4"><b>6.1</b></a></li> 1398 1403 <li><tt>If-Match</tt> <a href="#rfc.iref.g.5"><b>6.2</b></a></li> … … 1401 1406 <li><tt>If-Unmodified-Since</tt> <a href="#rfc.iref.g.8"><b>6.5</b></a></li> 1402 1407 <li><tt>Last-Modified</tt> <a href="#rfc.iref.g.9"><b>6.6</b></a></li> 1403 <li><tt>opaque-tag</tt> <a href="#rfc.iref.g.3"><b>2 </b></a></li>1404 <li><tt>weak</tt> <a href="#rfc.iref.g.2"><b>2 </b></a></li>1408 <li><tt>opaque-tag</tt> <a href="#rfc.iref.g.3"><b>2.1</b></a></li> 1409 <li><tt>weak</tt> <a href="#rfc.iref.g.2"><b>2.1</b></a></li> 1405 1410 </ul> 1406 1411 </li> … … 1410 1415 <li>Header Fields 1411 1416 <ul> 1412 <li>ETag <a href="#rfc.xref.header.etag.1">2 </a>, <a href="#rfc.iref.h.1"><b>6.1</b></a>, <a href="#rfc.xref.header.etag.2">7.2</a></li>1413 <li>If-Match <a href="#rfc.xref.header.if-match.1">2 </a>, <a href="#rfc.iref.h.2"><b>6.2</b></a>, <a href="#rfc.xref.header.if-match.2">7.2</a></li>1417 <li>ETag <a href="#rfc.xref.header.etag.1">2.1</a>, <a href="#rfc.iref.h.1"><b>6.1</b></a>, <a href="#rfc.xref.header.etag.2">7.2</a></li> 1418 <li>If-Match <a href="#rfc.xref.header.if-match.1">2.1</a>, <a href="#rfc.iref.h.2"><b>6.2</b></a>, <a href="#rfc.xref.header.if-match.2">7.2</a></li> 1414 1419 <li>If-Modified-Since <a href="#rfc.iref.h.3"><b>6.3</b></a>, <a href="#rfc.xref.header.if-modified-since.1">7.2</a></li> 1415 <li>If-None-Match <a href="#rfc.xref.header.if-none-match.1">2 </a>, <a href="#rfc.iref.h.4"><b>6.4</b></a>, <a href="#rfc.xref.header.if-none-match.2">7.2</a>, <a href="#rfc.xref.header.if-none-match.3">A</a></li>1420 <li>If-None-Match <a href="#rfc.xref.header.if-none-match.1">2.1</a>, <a href="#rfc.iref.h.4"><b>6.4</b></a>, <a href="#rfc.xref.header.if-none-match.2">7.2</a>, <a href="#rfc.xref.header.if-none-match.3">A</a></li> 1416 1421 <li>If-Unmodified-Since <a href="#rfc.iref.h.5"><b>6.5</b></a>, <a href="#rfc.xref.header.if-unmodified-since.1">7.2</a></li> 1417 1422 <li>Last-Modified <a href="#rfc.iref.h.6"><b>6.6</b></a>, <a href="#rfc.xref.header.last-modified.1">7.2</a></li> … … 1421 1426 </li> 1422 1427 <li><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul> 1423 <li>If-Match header field <a href="#rfc.xref.header.if-match.1">2 </a>, <a href="#rfc.iref.i.1"><b>6.2</b></a>, <a href="#rfc.xref.header.if-match.2">7.2</a></li>1428 <li>If-Match header field <a href="#rfc.xref.header.if-match.1">2.1</a>, <a href="#rfc.iref.i.1"><b>6.2</b></a>, <a href="#rfc.xref.header.if-match.2">7.2</a></li> 1424 1429 <li>If-Modified-Since header field <a href="#rfc.iref.i.2"><b>6.3</b></a>, <a href="#rfc.xref.header.if-modified-since.1">7.2</a></li> 1425 <li>If-None-Match header field <a href="#rfc.xref.header.if-none-match.1">2 </a>, <a href="#rfc.iref.i.3"><b>6.4</b></a>, <a href="#rfc.xref.header.if-none-match.2">7.2</a>, <a href="#rfc.xref.header.if-none-match.3">A</a></li>1430 <li>If-None-Match header field <a href="#rfc.xref.header.if-none-match.1">2.1</a>, <a href="#rfc.iref.i.3"><b>6.4</b></a>, <a href="#rfc.xref.header.if-none-match.2">7.2</a>, <a href="#rfc.xref.header.if-none-match.3">A</a></li> 1426 1431 <li>If-Unmodified-Since header field <a href="#rfc.iref.i.4"><b>6.5</b></a>, <a href="#rfc.xref.header.if-unmodified-since.1">7.2</a></li> 1427 1432 </ul> … … 1432 1437 </li> 1433 1438 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 1434 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1.2</a>, <a href="#rfc.xref.Part1.2">1.2 .1</a>, <a href="#rfc.xref.Part1.3">1.2.1</a>, <a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.2</a>, <a href="#rfc.xref.Part1.6">2.1</a>, <a href="#rfc.xref.Part1.7">3.1</a>, <a href="#rfc.xref.Part1.8">3.1</a>, <a href="#rfc.xref.Part1.9">8</a>, <a href="#Part1"><b>10.1</b></a><ul>1439 <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.1.1</a>, <a href="#rfc.xref.Part1.6">3.1</a>, <a href="#rfc.xref.Part1.7">3.1</a>, <a href="#rfc.xref.Part1.8">8</a>, <a href="#Part1"><b>10.1</b></a><ul> 1435 1440 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.1">1.2</a></li> 1436 <li><em>Section 1.2.2</em> <a href="#rfc.xref.Part1.2">1.2 .1</a>, <a href="#rfc.xref.Part1.3">1.2.1</a>, <a href="#rfc.xref.Part1.4">1.2.1</a></li>1437 <li><em>Section 6.1</em> <a href="#rfc.xref.Part1. 5">1.2.2</a></li>1438 <li><em>Section 6.2</em> <a href="#rfc.xref.Part1. 6">2.1</a></li>1439 <li><em>Section 9.3</em> <a href="#rfc.xref.Part1. 7">3.1</a></li>1440 <li><em>Section 9.3.1</em> <a href="#rfc.xref.Part1. 8">3.1</a></li>1441 <li><em>Section 1.2.2</em> <a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.3">1.2</a></li> 1442 <li><em>Section 6.1</em> <a href="#rfc.xref.Part1.4">1.2</a></li> 1443 <li><em>Section 6.2</em> <a href="#rfc.xref.Part1.5">2.1.1</a></li> 1444 <li><em>Section 9.3</em> <a href="#rfc.xref.Part1.6">3.1</a></li> 1445 <li><em>Section 9.3.1</em> <a href="#rfc.xref.Part1.7">3.1</a></li> 1441 1446 </ul> 1442 1447 </li> 1443 <li><em>Part3</em> <a href="#rfc.xref.Part3.1">2.1 </a>, <a href="#rfc.xref.Part3.2">2.1</a>, <a href="#Part3"><b>10.1</b></a><ul>1444 <li><em>Section 5</em> <a href="#rfc.xref.Part3.1">2.1 </a></li>1445 <li><em>Section 6.3</em> <a href="#rfc.xref.Part3.2">2.1 </a></li>1448 <li><em>Part3</em> <a href="#rfc.xref.Part3.1">2.1.1</a>, <a href="#rfc.xref.Part3.2">2.1.1</a>, <a href="#Part3"><b>10.1</b></a><ul> 1449 <li><em>Section 5</em> <a href="#rfc.xref.Part3.1">2.1.1</a></li> 1450 <li><em>Section 6.3</em> <a href="#rfc.xref.Part3.2">2.1.1</a></li> 1446 1451 </ul> 1447 1452 </li> 1448 <li><em>Part5</em> <a href="#rfc.xref.Part5.1">2 </a>, <a href="#rfc.xref.Part5.2">4</a>, <a href="#rfc.xref.Part5.3">4</a>, <a href="#rfc.xref.Part5.4">6.3</a>, <a href="#Part5"><b>10.1</b></a><ul>1449 <li><em>Section 5.3</em> <a href="#rfc.xref.Part5.1">2 </a></li>1453 <li><em>Part5</em> <a href="#rfc.xref.Part5.1">2.1</a>, <a href="#rfc.xref.Part5.2">4</a>, <a href="#rfc.xref.Part5.3">4</a>, <a href="#rfc.xref.Part5.4">6.3</a>, <a href="#Part5"><b>10.1</b></a><ul> 1454 <li><em>Section 5.3</em> <a href="#rfc.xref.Part5.1">2.1</a></li> 1450 1455 <li><em>Section 5.4</em> <a href="#rfc.xref.Part5.4">6.3</a></li> 1451 1456 </ul> 1452 1457 </li> 1453 <li><em>Part6</em> <a href="# rfc.xref.Part6.1">1</a>, <a href="#Part6"><b>10.1</b></a></li>1458 <li><em>Part6</em> <a href="#Part6"><b>10.1</b></a></li> 1454 1459 </ul> 1455 1460 </li> 1456 1461 <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul> 1457 1462 <li><em>RFC2119</em> <a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>10.1</b></a></li> 1458 <li><em>RFC2616</em> <a href="# rfc.xref.RFC2616.1">1</a>, <a href="#RFC2616"><b>10.2</b></a>, <a href="#rfc.xref.RFC2616.2">C.1</a></li>1463 <li><em>RFC2616</em> <a href="#RFC2616"><b>10.2</b></a>, <a href="#rfc.xref.RFC2616.1">C.1</a></li> 1459 1464 <li><em>RFC3864</em> <a href="#rfc.xref.RFC3864.1">7.2</a>, <a href="#RFC3864"><b>10.2</b></a></li> 1465 <li><em>RFC4918</em> <a href="#rfc.xref.RFC4918.1">2</a>, <a href="#RFC4918"><b>10.2</b></a></li> 1460 1466 <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>10.1</b></a><ul> 1461 1467 <li><em>Appendix B.1</em> <a href="#rfc.xref.RFC5234.2">1.2</a></li> -
draft-ietf-httpbis/latest/p4-conditional.xml
r1243 r1251 216 216 <section title="Introduction" anchor="introduction"> 217 217 <t> 218 This document defines HTTP/1.1 response metadata for indicating potential 219 changes to payload content, including modification time stamps and opaque 220 entity-tags, and the HTTP conditional request mechanisms that allow 221 preconditions to be placed on a request method. Conditional GET requests 222 allow for efficient cache updates. Other conditional request methods are 223 used to protect against overwriting or misunderstanding the state of a 224 resource that has been changed unbeknownst to the requesting client. 218 This document defines the HTTP/1.1 conditional request mechanisms, 219 including both response metadata that can be used to indicate or 220 observe changes to resource state and request header fields that 221 specify preconditions to be checked before performing the action 222 given by the request method. Conditional GET requests are the most 223 efficient mechanism for HTTP cache updates. Conditionals can be 224 applied to state-changing methods, such as PUT and DELETE, to prevent 225 the "lost update" problem: one client accidentally overwriting 226 the work of another client that has been acting in parallel. 227 </t> 228 <t> 229 Conditional request preconditions are based on the state of the target 230 resource as a whole (its current value set) or the state as observed 231 in a previously obtained representation (one value in that set). 232 A resource might have multiple current representations, each with its 233 own observable state. The conditional request mechanisms assume that 234 the mapping of requests to corresponding representations will be 235 consistent over time if the server intends to take advantage of 236 conditionals. Regardless, if the mapping is inconsistent and 237 the server is unable to select the appropriate representation, then 238 no harm will result when the precondition evaluates to false. 225 239 </t> 226 240 <t><iref primary="true" item="selected representation"/> 227 We use the term "<x:dfn>selected representation</x:dfn>" to refer to the current 228 representation of the target resource that would have been selected 229 and sent as payload in a 200 (OK) response if the same request had used 230 the method GET and had excluded all of the conditional request header 231 fields. The conditions found within conditional requests are evaluated 232 on the basis of either the state of the target resource as a whole or 233 the state of the target resource's selected representation. 234 </t> 235 <t> 236 This document is currently disorganized in order to minimize the changes 237 between drafts and enable reviewers to see the smaller errata changes. 238 A future draft will reorganize the sections to better reflect the content. 239 In particular, the sections on resource metadata will be discussed first 240 and then followed by each conditional request header field, concluding with a 241 definition of precedence and the expectation of ordering strong validator 242 checks before weak validator checks. It is likely that more content from 243 &caching; will migrate to this part, where appropriate. 244 The current mess reflects how widely dispersed these topics and associated 245 requirements had become in <xref target="RFC2616"/>. 241 We use the term "<x:dfn>selected representation</x:dfn>" to refer to 242 the current representation of the target resource that would have been 243 selected in a successful response if the same request had used the method 244 GET and had excluded all of the conditional request header fields. 245 The conditional request preconditions are evaluated by comparing the 246 values provided in the request header fields to the current metadata 247 for the selected representation. 246 248 </t> 247 249 … … 271 273 <x:anchor-alias value="VCHAR"/> 272 274 <x:anchor-alias value="WSP"/> 275 <x:anchor-alias value="core.rules"/> 276 <x:anchor-alias value="quoted-string"/> 277 <x:anchor-alias value="OWS"/> 278 <x:anchor-alias value="HTTP-date"/> 273 279 <t> 274 280 This specification uses the ABNF syntax defined in ¬ation; (which … … 287 293 and WSP (whitespace). 288 294 </t> 289 290 <section title="Core Rules" anchor="core.rules"> 291 <x:anchor-alias value="quoted-string"/> 292 <x:anchor-alias value="OWS"/> 293 <t> 294 The core rules below are defined in &basic-rules;: 295 <t> 296 The ABNF rules below are defined in other parts: 295 297 </t> 296 298 <figure><artwork type="abnf2616"> 297 299 <x:ref>quoted-string</x:ref> = <quoted-string, defined in &basic-rules;> 298 300 <x:ref>OWS</x:ref> = <OWS, defined in &basic-rules;> 299 </artwork></figure>300 </section>301 302 <section title="ABNF Rules defined in other Parts of the Specification" anchor="abnf.dependencies">303 <x:anchor-alias value="HTTP-date"/>304 <t>305 The ABNF rules below are defined in other parts:306 </t>307 <figure><!--Part1--><artwork type="abnf2616">308 301 <x:ref>HTTP-date</x:ref> = <HTTP-date, defined in &full-date;> 309 302 </artwork></figure> 310 303 </section> 311 312 </section> 313 314 </section> 315 316 <section title="Entity-Tags" anchor="entity.tags"> 304 </section> 305 306 <section title="Resource State Metadata" anchor="resource.metadata"> 307 <t> 308 This specification defines two forms of metadata that are commonly used 309 to observe resource state and test for preconditions: modification dates 310 and opaque entity tags. Additional metadata that reflects resource state 311 has been defined by various extensions of HTTP, such as WebDAV 312 <xref target="RFC4918"/>, that are beyond the scope of this specification. 313 </t> 314 315 <section title="Entity Tags" anchor="entity.tags"> 317 316 <x:anchor-alias value="entity-tag"/> 318 317 <x:anchor-alias value="opaque-tag"/> … … 406 405 </t> 407 406 </x:note> 407 </section> 408 408 </section> 409 409 </section> … … 1445 1445 </reference> 1446 1446 1447 <reference anchor='RFC4918'> 1448 <front> 1449 <title>HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)</title> 1450 <author initials="L.M." surname="Dusseault" fullname="Lisa Dusseault" role="editor" > 1451 <organization abbrev="CommerceNet">CommerceNet</organization> 1452 <address><email>ldusseault@commerce.net</email></address> 1453 </author> 1454 <date month="June" year="2007" /> 1455 </front> 1456 <seriesInfo name='RFC' value='4918' /> 1457 </reference> 1447 1458 </references> 1448 1459
Note: See TracChangeset
for help on using the changeset viewer.