![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
Changeset 1253
- Timestamp:
- Mar 31, 2011, 5:51:27 AM (9 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
-
p4-conditional.html (modified) (38 diffs)
-
p4-conditional.xml (modified) (9 diffs)
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p4-conditional.html
r1251 r1253 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 Resource State Metadata" href="#rfc.section.2"> 385 <link rel="Chapter" title="3 Status Code Definitions" href="#rfc.section.3"> 386 <link rel="Chapter" title="4 Weak and Strong Validators" href="#rfc.section.4"> 387 <link rel="Chapter" title="5 Rules for When to Use Entity-tags and Last-Modified Dates" href="#rfc.section.5"> 388 <link rel="Chapter" title="6 Header Field Definitions" href="#rfc.section.6"> 389 <link rel="Chapter" title="7 IANA Considerations" href="#rfc.section.7"> 390 <link rel="Chapter" title="8 Security Considerations" href="#rfc.section.8"> 391 <link rel="Chapter" title="9 Acknowledgments" href="#rfc.section.9"> 392 <link rel="Chapter" href="#rfc.section.10" title="10 References"> 384 <link rel="Chapter" title="2 Resource State Metadata (Validators)" href="#rfc.section.2"> 385 <link rel="Chapter" title="3 Precondition Header Fields" href="#rfc.section.3"> 386 <link rel="Chapter" title="4 Status Code Definitions" href="#rfc.section.4"> 387 <link rel="Chapter" title="5 IANA Considerations" href="#rfc.section.5"> 388 <link rel="Chapter" title="6 Security Considerations" href="#rfc.section.6"> 389 <link rel="Chapter" title="7 Acknowledgments" href="#rfc.section.7"> 390 <link rel="Chapter" href="#rfc.section.8" title="8 References"> 393 391 <link rel="Appendix" title="A Changes from RFC 2616" href="#rfc.section.A"> 394 392 <link rel="Appendix" title="B Collected ABNF" href="#rfc.section.B"> … … 538 536 </ul> 539 537 </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> 538 <li>2. <a href="#resource.metadata">Resource State Metadata (Validators)</a><ul> 539 <li>2.1 <a href="#header.last-modified">Last-Modified</a></li> 540 <li>2.2 <a href="#entity.tags">Entity Tags</a><ul> 541 <li>2.2.1 <a href="#header.etag">ETag</a></li> 542 <li>2.2.2 <a href="#example.entity.tag.vs.conneg">Example: Entity-tags varying on Content-Negotiated Resources</a></li> 543 543 </ul> 544 544 </li> 545 <li>2.3 <a href="#weak.and.strong.validators">Weak and Strong Validators</a></li> 546 <li>2.4 <a href="#rules.for.when.to.use.entity.tags.and.last-modified.dates">Rules for When to Use Entity-tags and Last-Modified Dates</a></li> 545 547 </ul> 546 548 </li> 547 <li>3. <a href="#status.code.definitions">Status Code Definitions</a><ul> 548 <li>3.1 <a href="#status.304">304 Not Modified</a></li> 549 <li>3.2 <a href="#status.412">412 Precondition Failed</a></li> 549 <li>3. <a href="#header.fields">Precondition Header Fields</a><ul> 550 <li>3.1 <a href="#header.if-match">If-Match</a></li> 551 <li>3.2 <a href="#header.if-none-match">If-None-Match</a></li> 552 <li>3.3 <a href="#header.if-modified-since">If-Modified-Since</a></li> 553 <li>3.4 <a href="#header.if-unmodified-since">If-Unmodified-Since</a></li> 550 554 </ul> 551 555 </li> 552 <li>4. <a href="#weak.and.strong.validators">Weak and Strong Validators</a></li> 553 <li>5. <a href="#rules.for.when.to.use.entity.tags.and.last-modified.dates">Rules for When to Use Entity-tags and Last-Modified Dates</a></li> 554 <li>6. <a href="#header.fields">Header Field Definitions</a><ul> 555 <li>6.1 <a href="#header.etag">ETag</a></li> 556 <li>6.2 <a href="#header.if-match">If-Match</a></li> 557 <li>6.3 <a href="#header.if-modified-since">If-Modified-Since</a></li> 558 <li>6.4 <a href="#header.if-none-match">If-None-Match</a></li> 559 <li>6.5 <a href="#header.if-unmodified-since">If-Unmodified-Since</a></li> 560 <li>6.6 <a href="#header.last-modified">Last-Modified</a></li> 556 <li>4. <a href="#status.code.definitions">Status Code Definitions</a><ul> 557 <li>4.1 <a href="#status.304">304 Not Modified</a></li> 558 <li>4.2 <a href="#status.412">412 Precondition Failed</a></li> 561 559 </ul> 562 560 </li> 563 <li> 7. <a href="#IANA.considerations">IANA Considerations</a><ul>564 <li> 7.1 <a href="#status.code.registration">Status Code Registration</a></li>565 <li> 7.2 <a href="#header.field.registration">Header Field Registration</a></li>561 <li>5. <a href="#IANA.considerations">IANA Considerations</a><ul> 562 <li>5.1 <a href="#status.code.registration">Status Code Registration</a></li> 563 <li>5.2 <a href="#header.field.registration">Header Field Registration</a></li> 566 564 </ul> 567 565 </li> 568 <li> 8. <a href="#security.considerations">Security Considerations</a></li>569 <li> 9. <a href="#ack">Acknowledgments</a></li>570 <li> 10. <a href="#rfc.references">References</a><ul>571 <li> 10.1 <a href="#rfc.references.1">Normative References</a></li>572 <li> 10.2 <a href="#rfc.references.2">Informative References</a></li>566 <li>6. <a href="#security.considerations">Security Considerations</a></li> 567 <li>7. <a href="#ack">Acknowledgments</a></li> 568 <li>8. <a href="#rfc.references">References</a><ul> 569 <li>8.1 <a href="#rfc.references.1">Normative References</a></li> 570 <li>8.2 <a href="#rfc.references.2">Informative References</a></li> 573 571 </ul> 574 572 </li> … … 599 597 <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 598 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. 599 the action given by 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 be applied to state-changing methods, such as PUT and DELETE, to prevent the "lost update" problem: one 600 client accidentally overwriting the work of another client that has been acting in parallel. 604 601 </p> 605 602 <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 … … 635 632 <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 633 <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> 634 </pre><div id="rfc.iref.m.1"></div> 635 <div id="rfc.iref.v.1"></div> 636 <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="resource.metadata" href="#resource.metadata">Resource State Metadata (Validators)</a></h1> 638 637 <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 638 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 (<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 </p> 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> 639 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. Such metadata is referred to as a "<dfn>validator</dfn>" when it is used within a precondition. 640 </p> 641 <div id="rfc.iref.l.1"></div> 642 <div id="rfc.iref.h.1"></div> 643 <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> <a id="header.last-modified" href="#header.last-modified">Last-Modified</a></h2> 644 <p id="rfc.section.2.1.p.1">The "Last-Modified" header field indicates the date and time at which the origin server believes the representation was last 645 modified. 646 </p> 647 <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> 648 </pre><p id="rfc.section.2.1.p.3">An example of its use is</p> 649 <div id="rfc.figure.u.3"></div><pre class="text"> Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT 650 </pre><p id="rfc.section.2.1.p.5">A representation is typically the sum of many parts behind the resource interface. The last-modified time would usually be 651 the most recent time that any of those parts were changed. How that value is determined for any given resource is an implementation 652 detail beyond the scope of this specification. What matters to HTTP is how recipients of the Last-Modified header field can 653 use its value to make conditional requests and test the validity of locally cached responses. 654 </p> 655 <p id="rfc.section.2.1.p.6">An origin server <em class="bcp14">MUST NOT</em> send a Last-Modified date which is later than the server's time of message origination. In such cases, where the resource's 656 last modification would indicate some time in the future, the server <em class="bcp14">MUST</em> replace that date with the message origination date. 657 </p> 658 <p id="rfc.section.2.1.p.7">An origin server <em class="bcp14">SHOULD</em> obtain the Last-Modified value of the representation as close as possible to the time that it generates the Date value of 659 its response. This allows a recipient to make an accurate assessment of the representation's modification time, especially 660 if the representation changes near the time that the response is generated. 661 </p> 662 <p id="rfc.section.2.1.p.8">HTTP/1.1 servers <em class="bcp14">SHOULD</em> send Last-Modified whenever feasible. 663 </p> 664 <p id="rfc.section.2.1.p.9">The Last-Modified header field value is often used as a cache validator. In simple terms, a cache entry is considered to be 665 valid if the representation has not been modified since the Last-Modified value. 666 </p> 667 <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> <a id="entity.tags" href="#entity.tags">Entity Tags</a></h2> 668 <p id="rfc.section.2.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 669 (<a href="#header.etag" id="rfc.xref.header.etag.1" title="ETag">Section 2.2.1</a>), If-Match (<a href="#header.if-match" id="rfc.xref.header.if-match.1" title="If-Match">Section 3.1</a>), If-None-Match (<a href="#header.if-none-match" id="rfc.xref.header.if-none-match.1" title="If-None-Match">Section 3.2</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 2.3</a>. An entity-tag consists of an opaque quoted string, possibly prefixed by a weakness indicator. 670 </p> 671 <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> <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 672 <a href="#entity.tags" class="smpl">weak</a> = %x57.2F ; "W/", case-sensitive 648 673 <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 expect674 </pre><p id="rfc.section.2.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. 675 </p> 676 <p id="rfc.section.2.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. 677 </p> 678 <p id="rfc.section.2.2.p.5">Cache entries might persist for arbitrarily long periods, regardless of expiration times, so it is inappropriate to expect 654 679 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 680 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 682 of multiple resources at the same time and does not imply that those representations are equivalent). 658 683 </p> 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> 684 <div id="rfc.iref.e.1"></div> 685 <div id="rfc.iref.h.2"></div> 686 <h3 id="rfc.section.2.2.1"><a href="#rfc.section.2.2.1">2.2.1</a> <a id="header.etag" href="#header.etag">ETag</a></h3> 687 <p id="rfc.section.2.2.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.2</a>) for one representation of the target resource. An entity-tag is intended for use as a resource-local identifier for differentiating 688 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 2.3</a>). 689 </p> 690 <div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.g.5"></span> <a href="#header.etag" class="smpl">ETag</a> = <a href="#entity.tags" class="smpl">entity-tag</a> 691 </pre><div id="rfc.figure.u.6"></div> 692 <p>Examples:</p> <pre class="text"> ETag: "xyzzy" 693 ETag: W/"xyzzy" 694 ETag: "" 695 </pre><p id="rfc.section.2.2.1.p.4">An entity-tag provides an "opaque" cache validator that allows for more reliable validation than modification dates in situations 696 where it is inconvenient to store modification dates, where the one-second resolution of HTTP date values is not sufficient, 697 or where the origin server wishes to avoid certain paradoxes that might arise from the use of modification dates. 698 </p> 699 <p id="rfc.section.2.2.1.p.5">The principle behind entity-tags is that only the service author knows the semantics of a resource well enough to select an 700 appropriate cache validation mechanism, and the specification of any validator comparison function more complex than byte-equality 701 would open up a can of worms. Thus, comparisons of any other header fields (except Last-Modified, for compatibility with HTTP/1.0) 702 are never used for purposes of validating a cache entry. 703 </p> 704 <h3 id="rfc.section.2.2.2"><a href="#rfc.section.2.2.2">2.2.2</a> <a id="example.entity.tag.vs.conneg" href="#example.entity.tag.vs.conneg">Example: Entity-tags varying on Content-Negotiated Resources</a></h3> 705 <p id="rfc.section.2.2.2.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>): 706 </p> 707 <div id="rfc.figure.u.7"></div> 663 708 <p>>> Request:</p><pre class="text2">GET /index HTTP/1.1 664 709 Host: www.example.com 665 710 Accept-Encoding: gzip 666 711 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>712 </pre><p id="rfc.section.2.2.2.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> 713 <div id="rfc.figure.u.8"></div> 669 714 <p>>> Response:</p><pre class="text">HTTP/1.1 200 OK 670 715 Date: Thu, 26 Mar 2010 00:05:00 GMT … … 679 724 Hello World! 680 725 Hello World! 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>726 </span></pre><p id="rfc.section.2.2.2.p.5">An alternative representation that does use gzip content coding would be:</p> 727 <div id="rfc.figure.u.9"></div> 683 728 <p>>> Response:</p><pre class="text">HTTP/1.1 200 OK 684 729 Date: Thu, 26 Mar 2010 00:05:00 GMT … … 689 734 Content-Encoding: gzip 690 735 691 <em>...binary data...</em></pre><div class="note" id="rfc.section.2. 1.1.p.7">736 <em>...binary data...</em></pre><div class="note" id="rfc.section.2.2.2.p.7"> 692 737 <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 738 from an unencoded representation to prevent conflicts during cache updates and range requests. In contrast, transfer codings … … 695 740 </p> 696 741 </div> 697 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="status.code.definitions" href="#status.code.definitions">Status Code Definitions</a></h1> 698 <div id="rfc.iref.4"></div> 699 <div id="rfc.iref.s.2"></div> 700 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="status.304" href="#status.304">304 Not Modified</a></h2> 701 <p id="rfc.section.3.1.p.1">The 304 status code indicates that a conditional GET request has been received and would have resulted in a 200 (OK) response 702 if it were not for the fact that the condition has evaluated to false. In other words, there is no need for the server to 703 transfer a representation of the target resource because the client's request indicates that it already has a valid representation, 704 as indicated by the 304 response header fields, and is therefore redirecting the client to make use of that stored representation 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 </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.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 Expires, Last-Modified, or Vary, then those same header fields <em class="bcp14">MUST</em> be sent in a 304 response. 709 </p> 710 <p id="rfc.section.3.1.p.3">Since the goal of a 304 response is to minimize information transfer when the recipient already has one or more cached representations, 711 the response <em class="bcp14">SHOULD NOT</em> include representation metadata other than the above listed fields unless said metadata exists for the purpose of guiding 712 cache updates (e.g., future HTTP extensions). 713 </p> 714 <p id="rfc.section.3.1.p.4">If the recipient of a 304 response does not have a cached representation corresponding to the entity-tag indicated by the 715 304 response, then the recipient <em class="bcp14">MUST NOT</em> use the 304 to update its own cache. If this conditional request originated with an outbound client, such as a user agent 716 with its own cache sending a conditional GET to a shared proxy, then the 304 response <em class="bcp14">MAY</em> be forwarded to the outbound client. Otherwise, the recipient <em class="bcp14">MUST</em> disregard the 304 response and repeat the request without any preconditions. 717 </p> 718 <p id="rfc.section.3.1.p.5">If a cache uses a received 304 response to update a cache entry, the cache <em class="bcp14">MUST</em> update the entry to reflect any new field values given in the response. 719 </p> 720 <div id="rfc.iref.5"></div> 721 <div id="rfc.iref.s.3"></div> 722 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="status.412" href="#status.412">412 Precondition Failed</a></h2> 723 <p id="rfc.section.3.2.p.1">The 412 status code indicates that one or more preconditions given in the request header fields evaluated to false when tested 724 on the server. This response code allows the client to place preconditions on the current resource state (its current representations 725 and metadata) and thus prevent the request method from being applied if the target resource is in an unexpected state. 726 </p> 727 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="weak.and.strong.validators" href="#weak.and.strong.validators">Weak and Strong Validators</a></h1> 728 <p id="rfc.section.4.p.1">Since both origin servers and caches will compare two validators to decide if they represent the same or different representations, 742 <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a> <a id="weak.and.strong.validators" href="#weak.and.strong.validators">Weak and Strong Validators</a></h2> 743 <p id="rfc.section.2.3.p.1">Since both origin servers and caches will compare two validators to decide if they represent the same or different representations, 729 744 one normally would expect that if the representation (including both representation header fields and representation body) 730 745 changes in any way, then the associated validator would change as well. If this is true, then we call this validator a "strong … … 732 747 is changed. 733 748 </p> 734 <p id="rfc.section. 4.p.2">However, there might be cases when a server prefers to change the validator only when it desires cached representations to749 <p id="rfc.section.2.3.p.2">However, there might be cases when a server prefers to change the validator only when it desires cached representations to 735 750 be invalidated. For example, the representation of a weather report that changes in content every second, based on dynamic 736 751 measurements, might be grouped into sets of equivalent representations (from the origin server's perspective) in order to … … 738 753 or weather quality). A validator that does not always change when the representation changes is a "weak validator". 739 754 </p> 740 <p id="rfc.section. 4.p.3">An entity-tag is normally a strong validator, but the protocol provides a mechanism to tag an entity-tag as "weak". One can755 <p id="rfc.section.2.3.p.3">An entity-tag is normally a strong validator, but the protocol provides a mechanism to tag an entity-tag as "weak". One can 741 756 think of a strong validator as part of an identifier for a specific representation, whereas a weak validator is part of an 742 757 identifier for a set of equivalent representations (where this notion of equivalence is entirely governed by the origin server … … 752 767 </li> 753 768 </ul> 754 <p id="rfc.section. 4.p.4">A strong entity-tag <em class="bcp14">MUST</em> change whenever the associated representation changes in any way. A weak entity-tag <em class="bcp14">SHOULD</em> change whenever the origin server considers prior representations to be unacceptable as a substitute for the current representation.769 <p id="rfc.section.2.3.p.4">A strong entity-tag <em class="bcp14">MUST</em> change whenever the associated representation changes in any way. A weak entity-tag <em class="bcp14">SHOULD</em> change whenever the origin server considers prior representations to be unacceptable as a substitute for the current representation. 755 770 In other words, a weak entity tag <em class="bcp14">SHOULD</em> change whenever the origin server wants caches to invalidate old responses. 756 771 </p> 757 <p id="rfc.section. 4.p.5">A "use" of a validator is either when a client generates a request and includes the validator in a validating header field,772 <p id="rfc.section.2.3.p.5">A "use" of a validator is either when a client generates a request and includes the validator in a validating header field, 758 773 or when a server compares two validators. 759 774 </p> 760 <p id="rfc.section. 4.p.6">Strong validators are usable in any context. Weak validators are only usable in contexts that do not depend on exact equality775 <p id="rfc.section.2.3.p.6">Strong validators are usable in any context. Weak validators are only usable in contexts that do not depend on exact equality 761 776 of a representation. For example, either kind is usable for a normal conditional GET. However, only a strong validator is 762 777 usable for range retrieval (<a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>), since otherwise the client might end up with an internally inconsistent representation. Clients <em class="bcp14">MUST NOT</em> use weak validators in range requests. 763 778 </p> 764 <p id="rfc.section. 4.p.7">The only function that HTTP/1.1 defines on validators is comparison. There are two validator comparison functions, depending779 <p id="rfc.section.2.3.p.7">The only function that HTTP/1.1 defines on validators is comparison. There are two validator comparison functions, depending 765 780 on whether the comparison context allows the use of weak validators or not: 766 781 </p> … … 771 786 </li> 772 787 </ul> 773 <p id="rfc.section. 4.p.8">The example below shows the results for a set of entity-tag pairs, and both the weak and strong comparison function results:</p>788 <p id="rfc.section.2.3.p.8">The example below shows the results for a set of entity-tag pairs, and both the weak and strong comparison function results:</p> 774 789 <div id="rfc.table.u.1"> 775 790 <table class="tt full left" cellpadding="3" cellspacing="0"> … … 810 825 </table> 811 826 </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.1</a> gives the syntax for entity-tags.813 </p> 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 is827 <p id="rfc.section.2.3.p.9">An entity-tag is strong unless it is explicitly tagged as weak. <a href="#entity.tags" title="Entity Tags">Section 2.2</a> gives the syntax for entity-tags. 828 </p> 829 <p id="rfc.section.2.3.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 815 830 strong, using the following rules: 816 831 </p> … … 821 836 </li> 822 837 </ul> 823 <p id="rfc.section. 4.p.11">or </p>838 <p id="rfc.section.2.3.p.11">or </p> 824 839 <ul> 825 840 <li>The validator is about to be used by a client in an If-Modified-Since or If-Unmodified-Since header field, because the client … … 829 844 <li>The presented Last-Modified time is at least 60 seconds before the Date value.</li> 830 845 </ul> 831 <p id="rfc.section. 4.p.12">or </p>846 <p id="rfc.section.2.3.p.12">or </p> 832 847 <ul> 833 848 <li>The validator is being compared by an intermediate cache to the validator stored in its cache entry for the representation, … … 837 852 <li>The presented Last-Modified time is at least 60 seconds before the Date value.</li> 838 853 </ul> 839 <p id="rfc.section. 4.p.13">This method relies on the fact that if two different responses were sent by the origin server during the same second, but854 <p id="rfc.section.2.3.p.13">This method relies on the fact that if two different responses were sent by the origin server during the same second, but 840 855 both had the same Last-Modified time, then at least one of those responses would have a Date value equal to its Last-Modified 841 856 time. The arbitrary 60-second limit guards against the possibility that the Date and Last-Modified values are generated from 842 857 different clocks, or at somewhat different times during the preparation of the response. An implementation <em class="bcp14">MAY</em> use a value larger than 60 seconds, if it is believed that 60 seconds is too short. 843 858 </p> 844 <p id="rfc.section. 4.p.14">If a client wishes to perform a sub-range retrieval on a value for which it has only a Last-Modified time and no opaque validator,859 <p id="rfc.section.2.3.p.14">If a client wishes to perform a sub-range retrieval on a value for which it has only a Last-Modified time and no opaque validator, 845 860 it <em class="bcp14">MAY</em> do this only if the Last-Modified time is strong in the sense described here. 846 861 </p> 847 <p id="rfc.section. 4.p.15">A cache or origin server receiving a conditional range request (<a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) <em class="bcp14">MUST</em> use the strong comparison function to evaluate the condition.848 </p> 849 <p id="rfc.section. 4.p.16">These rules allow HTTP/1.1 caches and clients to safely perform sub-range retrievals on values that have been obtained from862 <p id="rfc.section.2.3.p.15">A cache or origin server receiving a conditional range request (<a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) <em class="bcp14">MUST</em> use the strong comparison function to evaluate the condition. 863 </p> 864 <p id="rfc.section.2.3.p.16">These rules allow HTTP/1.1 caches and clients to safely perform sub-range retrievals on values that have been obtained from 850 865 HTTP/1.0 servers. 851 866 </p> 852 <h 1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="rules.for.when.to.use.entity.tags.and.last-modified.dates" href="#rules.for.when.to.use.entity.tags.and.last-modified.dates">Rules for When to Use Entity-tags and Last-Modified Dates</a></h1>853 <p id="rfc.section. 5.p.1">We adopt a set of rules and recommendations for origin servers, clients, and caches regarding when various validator types867 <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a> <a id="rules.for.when.to.use.entity.tags.and.last-modified.dates" href="#rules.for.when.to.use.entity.tags.and.last-modified.dates">Rules for When to Use Entity-tags and Last-Modified Dates</a></h2> 868 <p id="rfc.section.2.4.p.1">We adopt a set of rules and recommendations for origin servers, clients, and caches regarding when various validator types 854 869 ought to be used, and for what purposes. 855 870 </p> 856 <p id="rfc.section. 5.p.2">HTTP/1.1 origin servers: </p>871 <p id="rfc.section.2.4.p.2">HTTP/1.1 origin servers: </p> 857 872 <ul> 858 873 <li><em class="bcp14">SHOULD</em> send an entity-tag validator unless it is not feasible to generate one. … … 864 879 </li> 865 880 </ul> 866 <p id="rfc.section. 5.p.3">In other words, the preferred behavior for an HTTP/1.1 origin server is to send both a strong entity-tag and a Last-Modified881 <p id="rfc.section.2.4.p.3">In other words, the preferred behavior for an HTTP/1.1 origin server is to send both a strong entity-tag and a Last-Modified 867 882 value. 868 883 </p> 869 <p id="rfc.section. 5.p.4">HTTP/1.1 clients: </p>884 <p id="rfc.section.2.4.p.4">HTTP/1.1 clients: </p> 870 885 <ul> 871 886 <li><em class="bcp14">MUST</em> use that entity-tag in any cache-conditional request (using If-Match or If-None-Match) if an entity-tag has been provided … … 882 897 </li> 883 898 </ul> 884 <p id="rfc.section. 5.p.5">An HTTP/1.1 origin server, upon receiving a conditional request that includes both a Last-Modified date (e.g., in an If-Modified-Since899 <p id="rfc.section.2.4.p.5">An HTTP/1.1 origin server, upon receiving a conditional request that includes both a Last-Modified date (e.g., in an If-Modified-Since 885 900 or If-Unmodified-Since header field) and one or more entity-tags (e.g., in an If-Match, If-None-Match, or If-Range header 886 901 field) as cache validators, <em class="bcp14">MUST NOT</em> return a response status code of 304 (Not Modified) unless doing so is consistent with all of the conditional header fields 887 902 in the request. 888 903 </p> 889 <p id="rfc.section. 5.p.6">An HTTP/1.1 caching proxy, upon receiving a conditional request that includes both a Last-Modified date and one or more entity-tags904 <p id="rfc.section.2.4.p.6">An HTTP/1.1 caching proxy, upon receiving a conditional request that includes both a Last-Modified date and one or more entity-tags 890 905 as cache validators, <em class="bcp14">MUST NOT</em> return a locally cached response to the client unless that cached response is consistent with all of the conditional header 891 906 fields in the request. … … 902 917 </li> 903 918 </ul> 904 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> 905 <p id="rfc.section.6.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to conditional requests.</p> 906 <div id="rfc.iref.e.1"></div> 907 <div id="rfc.iref.h.1"></div> 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.1</a>) for one representation of the target resource. An entity-tag is intended for use as a resource-local identifier for differentiating 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 </p> 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 <p>Examples:</p> <pre class="text"> ETag: "xyzzy" 915 ETag: W/"xyzzy" 916 ETag: "" 917 </pre><p id="rfc.section.6.1.p.4">An entity-tag provides an "opaque" cache validator that allows for more reliable validation than modification dates in situations 918 where it is inconvenient to store modification dates, where the one-second resolution of HTTP date values is not sufficient, 919 or where the origin server wishes to avoid certain paradoxes that might arise from the use of modification dates. 920 </p> 921 <p id="rfc.section.6.1.p.5">The principle behind entity-tags is that only the service author knows the semantics of a resource well enough to select an 922 appropriate cache validation mechanism, and the specification of any validator comparison function more complex than byte-equality 923 would open up a can of worms. Thus, comparisons of any other header fields (except Last-Modified, for compatibility with HTTP/1.0) 924 are never used for purposes of validating a cache entry. 925 </p> 919 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="header.fields" href="#header.fields">Precondition Header Fields</a></h1> 920 <p id="rfc.section.3.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields for applying preconditions on requests.</p> 926 921 <div id="rfc.iref.i.1"></div> 927 <div id="rfc.iref.h. 2"></div>928 <h2 id="rfc.section. 6.2"><a href="#rfc.section.6.2">6.2</a> <a id="header.if-match" href="#header.if-match">If-Match</a></h2>929 <p id="rfc.section. 6.2.p.1">The "If-Match" header field <em class="bcp14">MAY</em> be used to make a request method conditional on the current existence or value of an entity-tag for one or more representations922 <div id="rfc.iref.h.3"></div> 923 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="header.if-match" href="#header.if-match">If-Match</a></h2> 924 <p id="rfc.section.3.1.p.1">The "If-Match" header field <em class="bcp14">MAY</em> be used to make a request method conditional on the current existence or value of an entity-tag for one or more representations 930 925 of the target resource. If-Match is generally useful for resource update requests, such as PUT requests, as a means for protecting 931 926 against accidental overwrites when multiple clients are acting in parallel on the same resource (i.e., the "lost update" problem). 932 927 An If-Match field-value of "*" places the precondition on the existence of any current representation for the target resource. 933 928 </p> 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 </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 target929 <div id="rfc.figure.u.10"></div><pre class="inline"><span id="rfc.iref.g.6"></span> <a href="#header.if-match" class="smpl">If-Match</a> = "*" / 1#<a href="#entity.tags" class="smpl">entity-tag</a> 930 </pre><p id="rfc.section.3.1.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 931 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. 937 932 </p> 938 <p id="rfc.section. 6.2.p.4">If none of the entity-tags match, or if "*" is given and no current representation exists, the server <em class="bcp14">MUST NOT</em> perform the requested method. Instead, the server <em class="bcp14">MUST</em> respond with the 412 (Precondition Failed) status code.939 </p> 940 <p id="rfc.section. 6.2.p.5">If the request would, without the If-Match header field, result in anything other than a 2xx or 412 status code, then the933 <p id="rfc.section.3.1.p.4">If none of the entity-tags match, or if "*" is given and no current representation exists, the server <em class="bcp14">MUST NOT</em> perform the requested method. Instead, the server <em class="bcp14">MUST</em> respond with the 412 (Precondition Failed) status code. 934 </p> 935 <p id="rfc.section.3.1.p.5">If the request would, without the If-Match header field, result in anything other than a 2xx or 412 status code, then the 941 936 If-Match header field <em class="bcp14">MUST</em> be ignored. 942 937 </p> 943 <p id="rfc.section. 6.2.p.6">Examples:</p>944 <div id="rfc.figure.u. 9"></div><pre class="text"> If-Match: "xyzzy"938 <p id="rfc.section.3.1.p.6">Examples:</p> 939 <div id="rfc.figure.u.11"></div><pre class="text"> If-Match: "xyzzy" 945 940 If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" 946 941 If-Match: * 947 </pre><p id="rfc.section. 6.2.p.8">The result of a request having both an If-Match header field and either an If-None-Match or an If-Modified-Since header fields942 </pre><p id="rfc.section.3.1.p.8">The result of a request having both an If-Match header field and either an If-None-Match or an If-Modified-Since header fields 948 943 is undefined by this specification. 949 944 </p> 950 945 <div id="rfc.iref.i.2"></div> 951 <div id="rfc.iref.h.3"></div> 952 <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a> <a id="header.if-modified-since" href="#header.if-modified-since">If-Modified-Since</a></h2> 953 <p id="rfc.section.6.3.p.1">The "If-Modified-Since" header field <em class="bcp14">MAY</em> be used to make a request method conditional by modification date: if the selected representation has not been modified since 946 <div id="rfc.iref.h.4"></div> 947 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="header.if-none-match" href="#header.if-none-match">If-None-Match</a></h2> 948 <p id="rfc.section.3.2.p.1">The "If-None-Match" header field <em class="bcp14">MAY</em> be used to make a request method conditional on not matching any of the current entity-tag values for representations of the 949 target resource. If-None-Match is primarily used in conditional GET requests to enable efficient updates of cached information 950 with a minimum amount of transaction overhead. A client that has one or more representations previously obtained from the 951 target resource can send If-None-Match with a list of the associated entity-tags in the hope of receiving a 304 response if 952 at least one of those representations matches the selected representation. 953 </p> 954 <p id="rfc.section.3.2.p.2">If-None-Match MAY also be used with a value of "*" to prevent an unsafe request method (e.g., PUT) from inadvertently modifying 955 an existing representation of the target resource when the client believes that the resource does not have a current representation. 956 This is a variation on the "lost update" problem that might arise if more than one client attempts to create an initial representation 957 for the target resource. 958 </p> 959 <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> 960 </pre><p id="rfc.section.3.2.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 961 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 962 representation that has a matching entity-tag. For all other request methods, the server <em class="bcp14">MUST</em> respond with a 412 (Precondition Failed) status code. 963 </p> 964 <p id="rfc.section.3.2.p.5">If none of the entity-tags match, then the server <em class="bcp14">MAY</em> perform the requested method as if the If-None-Match header field did not exist, but <em class="bcp14">MUST</em> also ignore any If-Modified-Since header field(s) in the request. That is, if no entity-tags match, then the server <em class="bcp14">MUST NOT</em> return a 304 (Not Modified) response. 965 </p> 966 <p id="rfc.section.3.2.p.6">If the request would, without the If-None-Match header field, result in anything other than a 2xx or 304 status code, then 967 the If-None-Match header field <em class="bcp14">MUST</em> be ignored. (See <a href="#rules.for.when.to.use.entity.tags.and.last-modified.dates" title="Rules for When to Use Entity-tags and Last-Modified Dates">Section 2.4</a> for a discussion of server behavior when both If-Modified-Since and If-None-Match appear in the same request.) 968 </p> 969 <p id="rfc.section.3.2.p.7">Examples:</p> 970 <div id="rfc.figure.u.13"></div><pre class="text"> If-None-Match: "xyzzy" 971 If-None-Match: W/"xyzzy" 972 If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" 973 If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz" 974 If-None-Match: * 975 </pre><p id="rfc.section.3.2.p.9">The result of a request having both an If-None-Match header field and either an If-Match or an If-Unmodified-Since header 976 fields is undefined by this specification. 977 </p> 978 <div id="rfc.iref.i.3"></div> 979 <div id="rfc.iref.h.5"></div> 980 <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a> <a id="header.if-modified-since" href="#header.if-modified-since">If-Modified-Since</a></h2> 981 <p id="rfc.section.3.3.p.1">The "If-Modified-Since" header field <em class="bcp14">MAY</em> be used to make a request method conditional by modification date: if the selected representation has not been modified since 954 982 the time specified in this field, then do not perform the request method; instead, respond as detailed below. 955 983 </p> 956 <div id="rfc.figure.u.1 0"></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 </pre><p id="rfc.section. 6.3.p.3">An example of the field is:</p>958 <div id="rfc.figure.u.1 1"></div><pre class="text"> If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT959 </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 be984 <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.8"></span> <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> = <a href="#notation" class="smpl">HTTP-date</a> 985 </pre><p id="rfc.section.3.3.p.3">An example of the field is:</p> 986 <div id="rfc.figure.u.15"></div><pre class="text"> If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT 987 </pre><p id="rfc.section.3.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 988 transferred only if it has been modified since the date given by the If-Modified-Since header field. The algorithm for determining 961 989 this includes the following cases: … … 972 1000 </li> 973 1001 </ol> 974 <p id="rfc.section. 6.3.p.6">The purpose of this feature is to allow efficient updates of cached information with a minimum amount of transaction overhead. </p>1002 <p id="rfc.section.3.3.p.6">The purpose of this feature is to allow efficient updates of cached information with a minimum amount of transaction overhead. </p> 975 1003 <ul class="empty"> 976 1004 <li> <b>Note:</b> The Range header field modifies the meaning of If-Modified-Since; see <a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.4"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a> for full details. … … 992 1020 </li> 993 1021 </ul> 994 <p id="rfc.section. 6.3.p.7">The result of a request having both an If-Modified-Since header field and either an If-Match or an If-Unmodified-Since header1022 <p id="rfc.section.3.3.p.7">The result of a request having both an If-Modified-Since header field and either an If-Match or an If-Unmodified-Since header 995 1023 fields is undefined by this specification. 996 1024 </p> 997 <div id="rfc.iref.i.3"></div>998 <div id="rfc.iref.h.4"></div>999 <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a> <a id="header.if-none-match" href="#header.if-none-match">If-None-Match</a></h2>1000 <p id="rfc.section.6.4.p.1">The "If-None-Match" header field <em class="bcp14">MAY</em> be used to make a request method conditional on not matching any of the current entity-tag values for representations of the1001 target resource. If-None-Match is primarily used in conditional GET requests to enable efficient updates of cached information1002 with a minimum amount of transaction overhead. A client that has one or more representations previously obtained from the1003 target resource can send If-None-Match with a list of the associated entity-tags in the hope of receiving a 304 response if1004 at least one of those representations matches the selected representation.1005 </p>1006 <p id="rfc.section.6.4.p.2">If-None-Match MAY also be used with a value of "*" to prevent an unsafe request method (e.g., PUT) from inadvertently modifying1007 an existing representation of the target resource when the client believes that the resource does not have a current representation.1008 This is a variation on the "lost update" problem that might arise if more than one client attempts to create an initial representation1009 for the target resource.1010 </p>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 </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, or1013 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 selected1014 representation that has a matching entity-tag. For all other request methods, the server <em class="bcp14">MUST</em> respond with a 412 (Precondition Failed) status code.1015 </p>1016 <p id="rfc.section.6.4.p.5">If none of the entity-tags match, then the server <em class="bcp14">MAY</em> perform the requested method as if the If-None-Match header field did not exist, but <em class="bcp14">MUST</em> also ignore any If-Modified-Since header field(s) in the request. That is, if no entity-tags match, then the server <em class="bcp14">MUST NOT</em> return a 304 (Not Modified) response.1017 </p>1018 <p id="rfc.section.6.4.p.6">If the request would, without the If-None-Match header field, result in anything other than a 2xx or 304 status code, then1019 the If-None-Match header field <em class="bcp14">MUST</em> be ignored. (See <a href="#rules.for.when.to.use.entity.tags.and.last-modified.dates" title="Rules for When to Use Entity-tags and Last-Modified Dates">Section 5</a> for a discussion of server behavior when both If-Modified-Since and If-None-Match appear in the same request.)1020 </p>1021 <p id="rfc.section.6.4.p.7">Examples:</p>1022 <div id="rfc.figure.u.13"></div><pre class="text"> If-None-Match: "xyzzy"1023 If-None-Match: W/"xyzzy"1024 If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"1025 If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"1026 If-None-Match: *1027 </pre><p id="rfc.section.6.4.p.9">The result of a request having both an If-None-Match header field and either an If-Match or an If-Unmodified-Since header1028 fields is undefined by this specification.1029 </p>1030 1025 <div id="rfc.iref.i.4"></div> 1031 <div id="rfc.iref.h. 5"></div>1032 <h2 id="rfc.section. 6.5"><a href="#rfc.section.6.5">6.5</a> <a id="header.if-unmodified-since" href="#header.if-unmodified-since">If-Unmodified-Since</a></h2>1033 <p id="rfc.section. 6.5.p.1">The "If-Unmodified-Since" header field <em class="bcp14">MAY</em> be used to make a request method conditional by modification date: if the selected representation has been modified since1026 <div id="rfc.iref.h.6"></div> 1027 <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a> <a id="header.if-unmodified-since" href="#header.if-unmodified-since">If-Unmodified-Since</a></h2> 1028 <p id="rfc.section.3.4.p.1">The "If-Unmodified-Since" header field <em class="bcp14">MAY</em> be used to make a request method conditional by modification date: if the selected representation has been modified since 1034 1029 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 412 (Precondition Failed) status code. If the selected representation has not been modified since 1035 1030 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 1031 </p> 1037 <div id="rfc.figure.u.1 4"></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 </pre><p id="rfc.section. 6.5.p.3">An example of the field is:</p>1039 <div id="rfc.figure.u.1 5"></div><pre class="text"> If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT1040 </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 or1032 <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.9"></span> <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> = <a href="#notation" class="smpl">HTTP-date</a> 1033 </pre><p id="rfc.section.3.4.p.3">An example of the field is:</p> 1034 <div id="rfc.figure.u.17"></div><pre class="text"> If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT 1035 </pre><p id="rfc.section.3.4.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 1036 412 status code, the If-Unmodified-Since header field <em class="bcp14">SHOULD</em> be ignored. 1042 1037 </p> 1043 <p id="rfc.section. 6.5.p.6">If the specified date is invalid, the header field <em class="bcp14">MUST</em> be ignored.1044 </p> 1045 <p id="rfc.section. 6.5.p.7">The result of a request having both an If-Unmodified-Since header field and either an If-None-Match or an If-Modified-Since1038 <p id="rfc.section.3.4.p.6">If the specified date is invalid, the header field <em class="bcp14">MUST</em> be ignored. 1039 </p> 1040 <p id="rfc.section.3.4.p.7">The result of a request having both an If-Unmodified-Since header field and either an If-None-Match or an If-Modified-Since 1046 1041 header fields is undefined by this specification. 1047 1042 </p> 1048 <div id="rfc.iref.l.1"></div> 1049 <div id="rfc.iref.h.6"></div> 1050 <h2 id="rfc.section.6.6"><a href="#rfc.section.6.6">6.6</a> <a id="header.last-modified" href="#header.last-modified">Last-Modified</a></h2> 1051 <p id="rfc.section.6.6.p.1">The "Last-Modified" header field indicates the date and time at which the origin server believes the representation was last 1052 modified. 1053 </p> 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 </pre><p id="rfc.section.6.6.p.3">An example of its use is</p> 1056 <div id="rfc.figure.u.17"></div><pre class="text"> Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT 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 the most recent time that any of those parts were changed. How that value is determined for any given resource is an implementation 1059 detail beyond the scope of this specification. What matters to HTTP is how recipients of the Last-Modified header field can 1060 use its value to make conditional requests and test the validity of locally cached responses. 1061 </p> 1062 <p id="rfc.section.6.6.p.6">An origin server <em class="bcp14">MUST NOT</em> send a Last-Modified date which is later than the server's time of message origination. In such cases, where the resource's 1063 last modification would indicate some time in the future, the server <em class="bcp14">MUST</em> replace that date with the message origination date. 1064 </p> 1065 <p id="rfc.section.6.6.p.7">An origin server <em class="bcp14">SHOULD</em> obtain the Last-Modified value of the representation as close as possible to the time that it generates the Date value of 1066 its response. This allows a recipient to make an accurate assessment of the representation's modification time, especially 1067 if the representation changes near the time that the response is generated. 1068 </p> 1069 <p id="rfc.section.6.6.p.8">HTTP/1.1 servers <em class="bcp14">SHOULD</em> send Last-Modified whenever feasible. 1070 </p> 1071 <p id="rfc.section.6.6.p.9">The Last-Modified header field value is often used as a cache validator. In simple terms, a cache entry is considered to be 1072 valid if the representation has not been modified since the Last-Modified value. 1073 </p> 1074 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> 1075 <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a> <a id="status.code.registration" href="#status.code.registration">Status Code Registration</a></h2> 1076 <p id="rfc.section.7.1.p.1">The HTTP Status Code Registry located at <<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>> shall be updated with the registrations below: 1043 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="status.code.definitions" href="#status.code.definitions">Status Code Definitions</a></h1> 1044 <div id="rfc.iref.24"></div> 1045 <div id="rfc.iref.s.2"></div> 1046 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="status.304" href="#status.304">304 Not Modified</a></h2> 1047 <p id="rfc.section.4.1.p.1">The 304 status code indicates that a conditional GET request has been received and would have resulted in a 200 (OK) response 1048 if it were not for the fact that the condition has evaluated to false. In other words, there is no need for the server to 1049 transfer a representation of the target resource because the client's request indicates that it already has a valid representation, 1050 as indicated by the 304 response header fields, and is therefore redirecting the client to make use of that stored representation 1051 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. 1052 </p> 1053 <p id="rfc.section.4.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, 1054 Expires, Last-Modified, or Vary, then those same header fields <em class="bcp14">MUST</em> be sent in a 304 response. 1055 </p> 1056 <p id="rfc.section.4.1.p.3">Since the goal of a 304 response is to minimize information transfer when the recipient already has one or more cached representations, 1057 the response <em class="bcp14">SHOULD NOT</em> include representation metadata other than the above listed fields unless said metadata exists for the purpose of guiding 1058 cache updates (e.g., future HTTP extensions). 1059 </p> 1060 <p id="rfc.section.4.1.p.4">If the recipient of a 304 response does not have a cached representation corresponding to the entity-tag indicated by the 1061 304 response, then the recipient <em class="bcp14">MUST NOT</em> use the 304 to update its own cache. If this conditional request originated with an outbound client, such as a user agent 1062 with its own cache sending a conditional GET to a shared proxy, then the 304 response <em class="bcp14">MAY</em> be forwarded to the outbound client. Otherwise, the recipient <em class="bcp14">MUST</em> disregard the 304 response and repeat the request without any preconditions. 1063 </p> 1064 <p id="rfc.section.4.1.p.5">If a cache uses a received 304 response to update a cache entry, the cache <em class="bcp14">MUST</em> update the entry to reflect any new field values given in the response. 1065 </p> 1066 <div id="rfc.iref.25"></div> 1067 <div id="rfc.iref.s.3"></div> 1068 <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="status.412" href="#status.412">412 Precondition Failed</a></h2> 1069 <p id="rfc.section.4.2.p.1">The 412 status code indicates that one or more preconditions given in the request header fields evaluated to false when tested 1070 on the server. This response code allows the client to place preconditions on the current resource state (its current representations 1071 and metadata) and thus prevent the request method from being applied if the target resource is in an unexpected state. 1072 </p> 1073 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> 1074 <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> 1075 <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: 1077 1076 </p> 1078 1077 <div id="rfc.table.1"> … … 1090 1089 <td class="left">304</td> 1091 1090 <td class="left">Not Modified</td> 1092 <td class="left"> <a href="#status.304" id="rfc.xref.status.304.1" title="304 Not Modified">Section 3.1</a>1091 <td class="left"> <a href="#status.304" id="rfc.xref.status.304.1" title="304 Not Modified">Section 4.1</a> 1093 1092 </td> 1094 1093 </tr> … … 1096 1095 <td class="left">412</td> 1097 1096 <td class="left">Precondition Failed</td> 1098 <td class="left"> <a href="#status.412" id="rfc.xref.status.412.1" title="412 Precondition Failed">Section 3.2</a>1097 <td class="left"> <a href="#status.412" id="rfc.xref.status.412.1" title="412 Precondition Failed">Section 4.2</a> 1099 1098 </td> 1100 1099 </tr> … … 1102 1101 </table> 1103 1102 </div> 1104 <h2 id="rfc.section. 7.2"><a href="#rfc.section.7.2">7.2</a> <a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2>1105 <p id="rfc.section. 7.2.p.1">The Message Header Field Registry located at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>> shall be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):1103 <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> 1104 <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>): 1106 1105 </p> 1107 1106 <div id="rfc.table.2"> … … 1121 1120 <td class="left">http</td> 1122 1121 <td class="left">standard</td> 1123 <td class="left"> <a href="#header.etag" id="rfc.xref.header.etag.2" title="ETag">Section 6.1</a>1122 <td class="left"> <a href="#header.etag" id="rfc.xref.header.etag.2" title="ETag">Section 2.2.1</a> 1124 1123 </td> 1125 1124 </tr> … … 1128 1127 <td class="left">http</td> 1129 1128 <td class="left">standard</td> 1130 <td class="left"> <a href="#header.if-match" id="rfc.xref.header.if-match.2" title="If-Match">Section 6.2</a>1129 <td class="left"> <a href="#header.if-match" id="rfc.xref.header.if-match.2" title="If-Match">Section 3.1</a> 1131 1130 </td> 1132 1131 </tr> … … 1135 1134 <td class="left">http</td> 1136 1135 <td class="left">standard</td> 1137 <td class="left"> <a href="#header.if-modified-since" id="rfc.xref.header.if-modified-since.1" title="If-Modified-Since">Section 6.3</a>1136 <td class="left"> <a href="#header.if-modified-since" id="rfc.xref.header.if-modified-since.1" title="If-Modified-Since">Section 3.3</a> 1138 1137 </td> 1139 1138 </tr> … … 1142 1141 <td class="left">http</td> 1143 1142 <td class="left">standard</td> 1144 <td class="left"> <a href="#header.if-none-match" id="rfc.xref.header.if-none-match.2" title="If-None-Match">Section 6.4</a>1143 <td class="left"> <a href="#header.if-none-match" id="rfc.xref.header.if-none-match.2" title="If-None-Match">Section 3.2</a> 1145 1144 </td> 1146 1145 </tr> … … 1149 1148 <td class="left">http</td> 1150 1149 <td class="left">standard</td> 1151 <td class="left"> <a href="#header.if-unmodified-since" id="rfc.xref.header.if-unmodified-since.1" title="If-Unmodified-Since">Section 6.5</a>1150 <td class="left"> <a href="#header.if-unmodified-since" id="rfc.xref.header.if-unmodified-since.1" title="If-Unmodified-Since">Section 3.4</a> 1152 1151 </td> 1153 1152 </tr> … … 1156 1155 <td class="left">http</td> 1157 1156 <td class="left">standard</td> 1158 <td class="left"> <a href="#header.last-modified" id="rfc.xref.header.last-modified.1" title="Last-Modified">Section 6.6</a>1157 <td class="left"> <a href="#header.last-modified" id="rfc.xref.header.last-modified.1" title="Last-Modified">Section 2.1</a> 1159 1158 </td> 1160 1159 </tr> … … 1162 1161 </table> 1163 1162 </div> 1164 <p id="rfc.section. 7.2.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>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.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.1167 </p> 1168 <h1 id="rfc.section. 9"><a href="#rfc.section.9">9.</a> <a id="ack" href="#ack">Acknowledgments</a></h1>1169 <h1 id="rfc.references"><a id="rfc.section. 10" href="#rfc.section.10">10.</a> References1163 <p id="rfc.section.5.2.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p> 1164 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1> 1165 <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.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 1166 </p> 1167 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="ack" href="#ack">Acknowledgments</a></h1> 1168 <h1 id="rfc.references"><a id="rfc.section.8" href="#rfc.section.8">8.</a> References 1170 1169 </h1> 1171 <h2 id="rfc.references.1"><a href="#rfc.section. 10.1" id="rfc.section.10.1">10.1</a> Normative References1170 <h2 id="rfc.references.1"><a href="#rfc.section.8.1" id="rfc.section.8.1">8.1</a> Normative References 1172 1171 </h2> 1173 1172 <table> … … 1203 1202 </tr> 1204 1203 </table> 1205 <h2 id="rfc.references.2"><a href="#rfc.section. 10.2" id="rfc.section.10.2">10.2</a> Informative References1204 <h2 id="rfc.references.2"><a href="#rfc.section.8.2" id="rfc.section.8.2">8.2</a> Informative References 1206 1205 </h2> 1207 1206 <table> … … 1241 1240 </div> 1242 1241 <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h1> 1243 <p id="rfc.section.A.p.1">Allow weak entity-tags in all requests except range requests (Sections <a href="#weak.and.strong.validators" title="Weak and Strong Validators"> 4</a> and <a href="#header.if-none-match" id="rfc.xref.header.if-none-match.3" title="If-None-Match">6.4</a>).1244 </p> 1245 <p id="rfc.section.A.p.2">Change ABNF productions for header fields to only define the field value. (<a href="#header.fields" title=" Header Field Definitions">Section 6</a>)1242 <p id="rfc.section.A.p.1">Allow weak entity-tags in all requests except range requests (Sections <a href="#weak.and.strong.validators" title="Weak and Strong Validators">2.3</a> and <a href="#header.if-none-match" id="rfc.xref.header.if-none-match.3" title="If-None-Match">3.2</a>). 1243 </p> 1244 <p id="rfc.section.A.p.2">Change ABNF productions for header fields to only define the field value. (<a href="#header.fields" title="Precondition Header Fields">Section 3</a>) 1246 1245 </p> 1247 1246 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> … … 1380 1379 </ul> 1381 1380 <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> 1382 <p class="noprint"><a href="#rfc.index.3">3</a> <a href="#rfc.index.4">4</a> <a href="#rfc.index.E">E</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.L">L</a> <a href="#rfc.index. P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a>1381 <p class="noprint"><a href="#rfc.index.3">3</a> <a href="#rfc.index.4">4</a> <a href="#rfc.index.E">E</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.L">L</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.V">V</a> 1383 1382 </p> 1384 1383 <div class="print2col"> 1385 1384 <ul class="ind"> 1386 1385 <li><a id="rfc.index.3" href="#rfc.index.3"><b>3</b></a><ul> 1387 <li>304 Not Modified (status code) <a href="#rfc.iref. 4"><b>3.1</b></a>, <a href="#rfc.xref.status.304.1">7.1</a></li>1386 <li>304 Not Modified (status code) <a href="#rfc.iref.24"><b>4.1</b></a>, <a href="#rfc.xref.status.304.1">5.1</a></li> 1388 1387 </ul> 1389 1388 </li> 1390 1389 <li><a id="rfc.index.4" href="#rfc.index.4"><b>4</b></a><ul> 1391 <li>412 Precondition Failed (status code) <a href="#rfc.iref. 5"><b>3.2</b></a>, <a href="#rfc.xref.status.412.1">7.1</a></li>1390 <li>412 Precondition Failed (status code) <a href="#rfc.iref.25"><b>4.2</b></a>, <a href="#rfc.xref.status.412.1">5.1</a></li> 1392 1391 </ul> 1393 1392 </li> 1394 1393 <li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul> 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>1394 <li>ETag header field <a href="#rfc.xref.header.etag.1">2.2</a>, <a href="#rfc.iref.e.1"><b>2.2.1</b></a>, <a href="#rfc.xref.header.etag.2">5.2</a></li> 1396 1395 </ul> 1397 1396 </li> … … 1399 1398 <li><tt>Grammar</tt> 1400 1399 <ul> 1401 <li><tt>entity-tag</tt> <a href="#rfc.iref.g. 1"><b>2.1</b></a></li>1402 <li><tt>ETag</tt> <a href="#rfc.iref.g. 4"><b>6.1</b></a></li>1403 <li><tt>If-Match</tt> <a href="#rfc.iref.g. 5"><b>6.2</b></a></li>1404 <li><tt>If-Modified-Since</tt> <a href="#rfc.iref.g. 6"><b>6.3</b></a></li>1405 <li><tt>If-None-Match</tt> <a href="#rfc.iref.g.7"><b> 6.4</b></a></li>1406 <li><tt>If-Unmodified-Since</tt> <a href="#rfc.iref.g. 8"><b>6.5</b></a></li>1407 <li><tt>Last-Modified</tt> <a href="#rfc.iref.g. 9"><b>6.6</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>1400 <li><tt>entity-tag</tt> <a href="#rfc.iref.g.2"><b>2.2</b></a></li> 1401 <li><tt>ETag</tt> <a href="#rfc.iref.g.5"><b>2.2.1</b></a></li> 1402 <li><tt>If-Match</tt> <a href="#rfc.iref.g.6"><b>3.1</b></a></li> 1403 <li><tt>If-Modified-Since</tt> <a href="#rfc.iref.g.8"><b>3.3</b></a></li> 1404 <li><tt>If-None-Match</tt> <a href="#rfc.iref.g.7"><b>3.2</b></a></li> 1405 <li><tt>If-Unmodified-Since</tt> <a href="#rfc.iref.g.9"><b>3.4</b></a></li> 1406 <li><tt>Last-Modified</tt> <a href="#rfc.iref.g.1"><b>2.1</b></a></li> 1407 <li><tt>opaque-tag</tt> <a href="#rfc.iref.g.4"><b>2.2</b></a></li> 1408 <li><tt>weak</tt> <a href="#rfc.iref.g.3"><b>2.2</b></a></li> 1410 1409 </ul> 1411 1410 </li> … … 1415 1414 <li>Header Fields 1416 1415 <ul> 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>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>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>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>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>1416 <li>ETag <a href="#rfc.xref.header.etag.1">2.2</a>, <a href="#rfc.iref.h.2"><b>2.2.1</b></a>, <a href="#rfc.xref.header.etag.2">5.2</a></li> 1417 <li>If-Match <a href="#rfc.xref.header.if-match.1">2.2</a>, <a href="#rfc.iref.h.3"><b>3.1</b></a>, <a href="#rfc.xref.header.if-match.2">5.2</a></li> 1418 <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> 1419 <li>If-None-Match <a href="#rfc.xref.header.if-none-match.1">2.2</a>, <a href="#rfc.iref.h.4"><b>3.2</b></a>, <a href="#rfc.xref.header.if-none-match.2">5.2</a>, <a href="#rfc.xref.header.if-none-match.3">A</a></li> 1420 <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> 1421 <li>Last-Modified <a href="#rfc.iref.h.1"><b>2.1</b></a>, <a href="#rfc.xref.header.last-modified.1">5.2</a></li> 1423 1422 </ul> 1424 1423 </li> … … 1426 1425 </li> 1427 1426 <li><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul> 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>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>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>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 <li>If-Match header field <a href="#rfc.xref.header.if-match.1">2.2</a>, <a href="#rfc.iref.i.1"><b>3.1</b></a>, <a href="#rfc.xref.header.if-match.2">5.2</a></li> 1428 <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> 1429 <li>If-None-Match header field <a href="#rfc.xref.header.if-none-match.1">2.2</a>, <a href="#rfc.iref.i.2"><b>3.2</b></a>, <a href="#rfc.xref.header.if-none-match.2">5.2</a>, <a href="#rfc.xref.header.if-none-match.3">A</a></li> 1430 <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> 1432 1431 </ul> 1433 1432 </li> 1434 1433 <li><a id="rfc.index.L" href="#rfc.index.L"><b>L</b></a><ul> 1435 <li>Last-Modified header field <a href="#rfc.iref.l.1"><b>6.6</b></a>, <a href="#rfc.xref.header.last-modified.1">7.2</a></li> 1434 <li>Last-Modified header field <a href="#rfc.iref.l.1"><b>2.1</b></a>, <a href="#rfc.xref.header.last-modified.1">5.2</a></li> 1435 </ul> 1436 </li> 1437 <li><a id="rfc.index.M" href="#rfc.index.M"><b>M</b></a><ul> 1438 <li>metadata <a href="#rfc.iref.m.1"><b>2</b></a></li> 1436 1439 </ul> 1437 1440 </li> 1438 1441 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</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>1442 <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.2.2</a>, <a href="#rfc.xref.Part1.6">4.1</a>, <a href="#rfc.xref.Part1.7">4.1</a>, <a href="#rfc.xref.Part1.8">6</a>, <a href="#Part1"><b>8.1</b></a><ul> 1440 1443 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.1">1.2</a></li> 1441 1444 <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 1445 <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>1446 <li><em>Section 6.2</em> <a href="#rfc.xref.Part1.5">2.2.2</a></li> 1447 <li><em>Section 9.3</em> <a href="#rfc.xref.Part1.6">4.1</a></li> 1448 <li><em>Section 9.3.1</em> <a href="#rfc.xref.Part1.7">4.1</a></li> 1446 1449 </ul> 1447 1450 </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>1451 <li><em>Part3</em> <a href="#rfc.xref.Part3.1">2.2.2</a>, <a href="#rfc.xref.Part3.2">2.2.2</a>, <a href="#Part3"><b>8.1</b></a><ul> 1452 <li><em>Section 5</em> <a href="#rfc.xref.Part3.1">2.2.2</a></li> 1453 <li><em>Section 6.3</em> <a href="#rfc.xref.Part3.2">2.2.2</a></li> 1451 1454 </ul> 1452 1455 </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>1455 <li><em>Section 5.4</em> <a href="#rfc.xref.Part5.4"> 6.3</a></li>1456 <li><em>Part5</em> <a href="#rfc.xref.Part5.1">2.2</a>, <a href="#rfc.xref.Part5.2">2.3</a>, <a href="#rfc.xref.Part5.3">2.3</a>, <a href="#rfc.xref.Part5.4">3.3</a>, <a href="#Part5"><b>8.1</b></a><ul> 1457 <li><em>Section 5.3</em> <a href="#rfc.xref.Part5.1">2.2</a></li> 1458 <li><em>Section 5.4</em> <a href="#rfc.xref.Part5.4">3.3</a></li> 1456 1459 </ul> 1457 1460 </li> 1458 <li><em>Part6</em> <a href="# Part6"><b>10.1</b></a></li>1461 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">1</a>, <a href="#Part6"><b>8.1</b></a></li> 1459 1462 </ul> 1460 1463 </li> 1461 1464 <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul> 1462 <li><em>RFC2119</em> <a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b> 10.1</b></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>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>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>1465 <li><em>RFC2119</em> <a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>8.1</b></a></li> 1466 <li><em>RFC2616</em> <a href="#RFC2616"><b>8.2</b></a>, <a href="#rfc.xref.RFC2616.1">C.1</a></li> 1467 <li><em>RFC3864</em> <a href="#rfc.xref.RFC3864.1">5.2</a>, <a href="#RFC3864"><b>8.2</b></a></li> 1468 <li><em>RFC4918</em> <a href="#rfc.xref.RFC4918.1">2</a>, <a href="#RFC4918"><b>8.2</b></a></li> 1469 <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> 1467 1470 <li><em>Appendix B.1</em> <a href="#rfc.xref.RFC5234.2">1.2</a></li> 1468 1471 </ul> … … 1474 1477 <li>Status Codes 1475 1478 <ul> 1476 <li>304 Not Modified <a href="#rfc.iref.s.2"><b> 3.1</b></a>, <a href="#rfc.xref.status.304.1">7.1</a></li>1477 <li>412 Precondition Failed <a href="#rfc.iref.s.3"><b> 3.2</b></a>, <a href="#rfc.xref.status.412.1">7.1</a></li>1479 <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> 1480 <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> 1478 1481 </ul> 1479 1482 </li> 1483 </ul> 1484 </li> 1485 <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul> 1486 <li>validator <a href="#rfc.iref.v.1"><b>2</b></a></li> 1480 1487 </ul> 1481 1488 </li> -
draft-ietf-httpbis/latest/p4-conditional.xml
r1251 r1253 221 221 specify preconditions to be checked before performing the action 222 222 given by the request method. Conditional GET requests are the most 223 efficient mechanism for HTTP cache updates . Conditionals can be223 efficient mechanism for HTTP cache updates &caching;. Conditionals can be 224 224 applied to state-changing methods, such as PUT and DELETE, to prevent 225 225 the "lost update" problem: one client accidentally overwriting … … 304 304 </section> 305 305 306 <section title="Resource State Metadata" anchor="resource.metadata"> 306 <section title="Resource State Metadata (Validators)" anchor="resource.metadata"> 307 <iref primary="true" item="metadata"/> 308 <iref primary="true" item="validator"/> 307 309 <t> 308 310 This specification defines two forms of metadata that are commonly used … … 311 313 has been defined by various extensions of HTTP, such as WebDAV 312 314 <xref target="RFC4918"/>, that are beyond the scope of this specification. 313 </t> 315 Such metadata is referred to as a "<x:dfn>validator</x:dfn>" when it is 316 used within a precondition. 317 </t> 318 319 <section title="Last-Modified" anchor="header.last-modified"> 320 <iref primary="true" item="Last-Modified header field" x:for-anchor=""/> 321 <iref primary="true" item="Header Fields" subitem="Last-Modified" x:for-anchor=""/> 322 <x:anchor-alias value="Last-Modified"/> 323 <t> 324 The "Last-Modified" header field indicates the date and time at 325 which the origin server believes the representation was last modified. 326 </t> 327 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Last-Modified"/> 328 <x:ref>Last-Modified</x:ref> = <x:ref>HTTP-date</x:ref> 329 </artwork></figure> 330 <t> 331 An example of its use is 332 </t> 333 <figure><artwork type="example"> 334 Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT 335 </artwork></figure> 336 <t> 337 A representation is typically the sum of many parts behind the 338 resource interface. The last-modified time would usually be 339 the most recent time that any of those parts were changed. 340 How that value is determined for any given resource is an 341 implementation detail beyond the scope of this specification. 342 What matters to HTTP is how recipients of the Last-Modified 343 header field can use its value to make conditional requests 344 and test the validity of locally cached responses. 345 </t> 346 <t> 347 An origin server &MUST-NOT; send a Last-Modified date which is later 348 than the server's time of message origination. In such cases, where 349 the resource's last modification would indicate some time in the 350 future, the server &MUST; replace that date with the message 351 origination date. 352 </t> 353 <t> 354 An origin server &SHOULD; obtain the Last-Modified value of the representation 355 as close as possible to the time that it generates the Date value of 356 its response. This allows a recipient to make an accurate assessment 357 of the representation's modification time, especially if the representation changes 358 near the time that the response is generated. 359 </t> 360 <t> 361 HTTP/1.1 servers &SHOULD; send Last-Modified whenever feasible. 362 </t> 363 <t> 364 The Last-Modified header field value is often used as a cache 365 validator. In simple terms, a cache entry is considered to be valid 366 if the representation has not been modified since the Last-Modified value. 367 </t> 368 </section> 314 369 315 370 <section title="Entity Tags" anchor="entity.tags"> … … 353 408 </t> 354 409 410 <section title="ETag" anchor="header.etag"> 411 <iref primary="true" item="ETag header field" x:for-anchor=""/> 412 <iref primary="true" item="Header Fields" subitem="ETag" x:for-anchor=""/> 413 <x:anchor-alias value="ETag"/> 414 <t> 415 The "ETag" header field provides the current value of the 416 entity-tag (see <xref target="entity.tags"/>) for one representation of 417 the target resource. An entity-tag 418 is intended for use as a resource-local identifier for differentiating 419 between representations of the same resource that vary over time or via 420 content negotiation (see <xref target="weak.and.strong.validators"/>). 421 </t> 422 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="ETag"/> 423 <x:ref>ETag</x:ref> = <x:ref>entity-tag</x:ref> 424 </artwork></figure> 425 <figure><preamble> 426 Examples: 427 </preamble> 428 <artwork type="example"> 429 ETag: "xyzzy" 430 ETag: W/"xyzzy" 431 ETag: "" 432 </artwork></figure> 433 <t> 434 An entity-tag provides an "opaque" cache validator that allows for 435 more reliable validation than modification dates in situations where 436 it is inconvenient to store modification dates, 437 where the one-second resolution of HTTP date values is not 438 sufficient, or where the origin server wishes to avoid certain 439 paradoxes that might arise from the use of modification dates. 440 </t> 441 <t> 442 The principle behind entity-tags is that only the service author 443 knows the semantics of a resource well enough to select an 444 appropriate cache validation mechanism, and the specification of any 445 validator comparison function more complex than byte-equality would 446 open up a can of worms. Thus, comparisons of any other header fields 447 (except Last-Modified, for compatibility with HTTP/1.0) are never 448 used for purposes of validating a cache entry. 449 </t> 450 </section> 451 355 452 <section title="Example: Entity-tags varying on Content-Negotiated Resources" anchor="example.entity.tag.vs.conneg"> 356 453 <t> … … 405 502 </t> 406 503 </x:note> 407 </section>408 </section>409 </section>410 411 <section title="Status Code Definitions" anchor="status.code.definitions">412 <section title="304 Not Modified" anchor="status.304">413 <iref primary="true" item="304 Not Modified (status code)" x:for-anchor=""/>414 <iref primary="true" item="Status Codes" subitem="304 Not Modified" x:for-anchor=""/>415 <t>416 The 304 status code indicates that a conditional GET request has been417 received and would have resulted in a 200 (OK) response if it were not418 for the fact that the condition has evaluated to false. In other words,419 there is no need for the server to transfer a representation of the420 target resource because the client's request indicates that it already421 has a valid representation, as indicated by the 304 response header422 fields, and is therefore redirecting the client to make use of that423 stored representation as if it were the payload of a 200 response.424 The 304 response &MUST-NOT; contain a message-body, and thus is always425 terminated by the first empty line after the header fields.426 </t>427 <t>428 A 304 response &MUST; include a Date header field (&header-date;)429 unless its omission is required by &clockless;. If a 200 response430 to the same request would have included any of the header fields431 Cache-Control, Content-Location, ETag, Expires, Last-Modified, or432 Vary, then those same header fields &MUST; be sent in a 304 response.433 </t>434 <t>435 Since the goal of a 304 response is to minimize information transfer436 when the recipient already has one or more cached representations,437 the response &SHOULD-NOT; include representation metadata other438 than the above listed fields unless said metadata exists for the439 purpose of guiding cache updates (e.g., future HTTP extensions).440 </t>441 <t>442 If the recipient of a 304 response does not have a cached representation443 corresponding to the entity-tag indicated by the 304 response, then the444 recipient &MUST-NOT; use the 304 to update its own cache. If this445 conditional request originated with an outbound client, such as a446 user agent with its own cache sending a conditional GET to a shared447 proxy, then the 304 response &MAY; be forwarded to the outbound client.448 Otherwise, the recipient &MUST; disregard the 304 response and repeat449 the request without any preconditions.450 </t>451 <t>452 If a cache uses a received 304 response to update a cache entry, the453 cache &MUST; update the entry to reflect any new field values given in454 the response.455 </t>456 </section>457 458 <section title="412 Precondition Failed" anchor="status.412">459 <iref primary="true" item="412 Precondition Failed (status code)" x:for-anchor=""/>460 <iref primary="true" item="Status Codes" subitem="412 Precondition Failed" x:for-anchor=""/>461 <t>462 The 412 status code indicates that one or more preconditions given in463 the request header fields evaluated to false when tested on the server.464 This response code allows the client to place preconditions on the465 current resource state (its current representations and metadata)466 and thus prevent the request method from being applied if the target467 resource is in an unexpected state.468 </t>469 504 </section> 470 505 </section> … … 725 760 </section> 726 761 727 <section title="Header Field Definitions" anchor="header.fields"> 762 </section> 763 764 <section title="Precondition Header Fields" anchor="header.fields"> 728 765 <t> 729 766 This section defines the syntax and semantics of HTTP/1.1 header fields 730 related to conditional requests. 731 </t> 732 733 <section title="ETag" anchor="header.etag"> 734 <iref primary="true" item="ETag header field" x:for-anchor=""/> 735 <iref primary="true" item="Header Fields" subitem="ETag" x:for-anchor=""/> 736 <x:anchor-alias value="ETag"/> 737 <t> 738 The "ETag" header field provides the current value of the 739 entity-tag (see <xref target="entity.tags"/>) for one representation of 740 the target resource. An entity-tag 741 is intended for use as a resource-local identifier for differentiating 742 between representations of the same resource that vary over time or via 743 content negotiation (see <xref target="weak.and.strong.validators"/>). 744 </t> 745 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="ETag"/> 746 <x:ref>ETag</x:ref> = <x:ref>entity-tag</x:ref> 747 </artwork></figure> 748 <figure><preamble> 749 Examples: 750 </preamble> 751 <artwork type="example"> 752 ETag: "xyzzy" 753 ETag: W/"xyzzy" 754 ETag: "" 755 </artwork></figure> 756 <t> 757 An entity-tag provides an "opaque" cache validator that allows for 758 more reliable validation than modification dates in situations where 759 it is inconvenient to store modification dates, 760 where the one-second resolution of HTTP date values is not 761 sufficient, or where the origin server wishes to avoid certain 762 paradoxes that might arise from the use of modification dates. 763 </t> 764 <t> 765 The principle behind entity-tags is that only the service author 766 knows the semantics of a resource well enough to select an 767 appropriate cache validation mechanism, and the specification of any 768 validator comparison function more complex than byte-equality would 769 open up a can of worms. Thus, comparisons of any other header fields 770 (except Last-Modified, for compatibility with HTTP/1.0) are never 771 used for purposes of validating a cache entry. 772 </t> 773 </section> 767 for applying preconditions on requests. 768 </t> 774 769 775 770 <section title="If-Match" anchor="header.if-match"> … … 820 815 The result of a request having both an If-Match header field and 821 816 either an If-None-Match or an If-Modified-Since header fields is 817 undefined by this specification. 818 </t> 819 </section> 820 821 <section title="If-None-Match" anchor="header.if-none-match"> 822 <iref primary="true" item="If-None-Match header field" x:for-anchor=""/> 823 <iref primary="true" item="Header Fields" subitem="If-None-Match" x:for-anchor=""/> 824 <x:anchor-alias value="If-None-Match"/> 825 <t> 826 The "If-None-Match" header field &MAY; be used to make a request method 827 conditional on not matching any of the current entity-tag values for 828 representations of the target resource. If-None-Match is primarily 829 used in conditional GET requests to enable efficient updates of cached 830 information with a minimum amount of transaction overhead. A client 831 that has one or more representations previously obtained from the 832 target resource can send If-None-Match with a list of the associated 833 entity-tags in the hope of receiving a 304 response if at least one 834 of those representations matches the selected representation. 835 </t> 836 <t> 837 If-None-Match MAY also be used with a value of "*" to prevent an unsafe 838 request method (e.g., PUT) from inadvertently modifying an existing 839 representation of the target resource when the client believes that 840 the resource does not have a current representation. This is a variation 841 on the "lost update" problem that might arise if more than one client 842 attempts to create an initial representation for the target resource. 843 </t> 844 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-None-Match"/> 845 <x:ref>If-None-Match</x:ref> = "*" / 1#<x:ref>entity-tag</x:ref> 846 </artwork></figure> 847 <t> 848 If any of the entity-tags listed in the If-None-Match field-value match 849 the entity-tag of the selected representation, or if "*" is 850 given and any current representation exists for that resource, then the 851 server &MUST-NOT; perform the requested method. 852 Instead, if the request method was GET or HEAD, the server &SHOULD; 853 respond with a 304 (Not Modified) status code, including the cache-related 854 header fields (particularly ETag) of the selected representation that has 855 a matching entity-tag. For all other request methods, the server &MUST; 856 respond with a 412 (Precondition Failed) status code. 857 </t> 858 <t> 859 If none of the entity-tags match, then the server &MAY; perform the 860 requested method as if the If-None-Match header field did not exist, 861 but &MUST; also ignore any If-Modified-Since header field(s) in the 862 request. That is, if no entity-tags match, then the server &MUST-NOT; 863 return a 304 (Not Modified) response. 864 </t> 865 <t> 866 If the request would, without the If-None-Match header field, result 867 in anything other than a 2xx or 304 status code, then the If-None-Match 868 header field &MUST; be ignored. (See <xref 869 target="rules.for.when.to.use.entity.tags.and.last-modified.dates"/> for 870 a discussion of server behavior when both If-Modified-Since and 871 If-None-Match appear in the same request.) 872 </t> 873 <t> 874 Examples: 875 </t> 876 <figure><artwork type="example"> 877 If-None-Match: "xyzzy" 878 If-None-Match: W/"xyzzy" 879 If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" 880 If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz" 881 If-None-Match: * 882 </artwork></figure> 883 <t> 884 The result of a request having both an If-None-Match header field and 885 either an If-Match or an If-Unmodified-Since header fields is 822 886 undefined by this specification. 823 887 </t> … … 907 971 </section> 908 972 909 <section title="If-None-Match" anchor="header.if-none-match">910 <iref primary="true" item="If-None-Match header field" x:for-anchor=""/>911 <iref primary="true" item="Header Fields" subitem="If-None-Match" x:for-anchor=""/>912 <x:anchor-alias value="If-None-Match"/>913 <t>914 The "If-None-Match" header field &MAY; be used to make a request method915 conditional on not matching any of the current entity-tag values for916 representations of the target resource. If-None-Match is primarily917 used in conditional GET requests to enable efficient updates of cached918 information with a minimum amount of transaction overhead. A client919 that has one or more representations previously obtained from the920 target resource can send If-None-Match with a list of the associated921 entity-tags in the hope of receiving a 304 response if at least one922 of those representations matches the selected representation.923 </t>924 <t>925 If-None-Match MAY also be used with a value of "*" to prevent an unsafe926 request method (e.g., PUT) from inadvertently modifying an existing927 representation of the target resource when the client believes that928 the resource does not have a current representation. This is a variation929 on the "lost update" problem that might arise if more than one client930 attempts to create an initial representation for the target resource.931 </t>932 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-None-Match"/>933 <x:ref>If-None-Match</x:ref> = "*" / 1#<x:ref>entity-tag</x:ref>934 </artwork></figure>935 <t>936 If any of the entity-tags listed in the If-None-Match field-value match937 the entity-tag of the selected representation, or if "*" is938 given and any current representation exists for that resource, then the939 server &MUST-NOT; perform the requested method.940 Instead, if the request method was GET or HEAD, the server &SHOULD;941 respond with a 304 (Not Modified) status code, including the cache-related942 header fields (particularly ETag) of the selected representation that has943 a matching entity-tag. For all other request methods, the server &MUST;944 respond with a 412 (Precondition Failed) status code.945 </t>946 <t>947 If none of the entity-tags match, then the server &MAY; perform the948 requested method as if the If-None-Match header field did not exist,949 but &MUST; also ignore any If-Modified-Since header field(s) in the950 request. That is, if no entity-tags match, then the server &MUST-NOT;951 return a 304 (Not Modified) response.952 </t>953 <t>954 If the request would, without the If-None-Match header field, result955 in anything other than a 2xx or 304 status code, then the If-None-Match956 header field &MUST; be ignored. (See <xref957 target="rules.for.when.to.use.entity.tags.and.last-modified.dates"/> for958 a discussion of server behavior when both If-Modified-Since and959 If-None-Match appear in the same request.)960 </t>961 <t>962 Examples:963 </t>964 <figure><artwork type="example">965 If-None-Match: "xyzzy"966 If-None-Match: W/"xyzzy"967 If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"968 If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"969 If-None-Match: *970 </artwork></figure>971 <t>972 The result of a request having both an If-None-Match header field and973 either an If-Match or an If-Unmodified-Since header fields is974 undefined by this specification.975 </t>976 </section>977 978 973 <section title="If-Unmodified-Since" anchor="header.if-unmodified-since"> 979 974 <iref primary="true" item="If-Unmodified-Since header field" x:for-anchor=""/> … … 1014 1009 </section> 1015 1010 1016 <section title="Last-Modified" anchor="header.last-modified"> 1017 <iref primary="true" item="Last-Modified header field" x:for-anchor=""/> 1018 <iref primary="true" item="Header Fields" subitem="Last-Modified" x:for-anchor=""/> 1019 <x:anchor-alias value="Last-Modified"/> 1020 <t> 1021 The "Last-Modified" header field indicates the date and time at 1022 which the origin server believes the representation was last modified. 1023 </t> 1024 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Last-Modified"/> 1025 <x:ref>Last-Modified</x:ref> = <x:ref>HTTP-date</x:ref> 1026 </artwork></figure> 1027 <t> 1028 An example of its use is 1029 </t> 1030 <figure><artwork type="example"> 1031 Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT 1032 </artwork></figure> 1033 <t> 1034 A representation is typically the sum of many parts behind the 1035 resource interface. The last-modified time would usually be 1036 the most recent time that any of those parts were changed. 1037 How that value is determined for any given resource is an 1038 implementation detail beyond the scope of this specification. 1039 What matters to HTTP is how recipients of the Last-Modified 1040 header field can use its value to make conditional requests 1041 and test the validity of locally cached responses. 1042 </t> 1043 <t> 1044 An origin server &MUST-NOT; send a Last-Modified date which is later 1045 than the server's time of message origination. In such cases, where 1046 the resource's last modification would indicate some time in the 1047 future, the server &MUST; replace that date with the message 1048 origination date. 1049 </t> 1050 <t> 1051 An origin server &SHOULD; obtain the Last-Modified value of the representation 1052 as close as possible to the time that it generates the Date value of 1053 its response. This allows a recipient to make an accurate assessment 1054 of the representation's modification time, especially if the representation changes 1055 near the time that the response is generated. 1056 </t> 1057 <t> 1058 HTTP/1.1 servers &SHOULD; send Last-Modified whenever feasible. 1059 </t> 1060 <t> 1061 The Last-Modified header field value is often used as a cache 1062 validator. In simple terms, a cache entry is considered to be valid 1063 if the representation has not been modified since the Last-Modified value. 1064 </t> 1065 </section> 1066 1011 </section> 1012 1013 <section title="Status Code Definitions" anchor="status.code.definitions"> 1014 <section title="304 Not Modified" anchor="status.304"> 1015 <iref primary="true" item="304 Not Modified (status code)" x:for-anchor=""/> 1016 <iref primary="true" item="Status Codes" subitem="304 Not Modified" x:for-anchor=""/> 1017 <t> 1018 The 304 status code indicates that a conditional GET request has been 1019 received and would have resulted in a 200 (OK) response if it were not 1020 for the fact that the condition has evaluated to false. In other words, 1021 there is no need for the server to transfer a representation of the 1022 target resource because the client's request indicates that it already 1023 has a valid representation, as indicated by the 304 response header 1024 fields, and is therefore redirecting the client to make use of that 1025 stored representation as if it were the payload of a 200 response. 1026 The 304 response &MUST-NOT; contain a message-body, and thus is always 1027 terminated by the first empty line after the header fields. 1028 </t> 1029 <t> 1030 A 304 response &MUST; include a Date header field (&header-date;) 1031 unless its omission is required by &clockless;. If a 200 response 1032 to the same request would have included any of the header fields 1033 Cache-Control, Content-Location, ETag, Expires, Last-Modified, or 1034 Vary, then those same header fields &MUST; be sent in a 304 response. 1035 </t> 1036 <t> 1037 Since the goal of a 304 response is to minimize information transfer 1038 when the recipient already has one or more cached representations, 1039 the response &SHOULD-NOT; include representation metadata other 1040 than the above listed fields unless said metadata exists for the 1041 purpose of guiding cache updates (e.g., future HTTP extensions). 1042 </t> 1043 <t> 1044 If the recipient of a 304 response does not have a cached representation 1045 corresponding to the entity-tag indicated by the 304 response, then the 1046 recipient &MUST-NOT; use the 304 to update its own cache. If this 1047 conditional request originated with an outbound client, such as a 1048 user agent with its own cache sending a conditional GET to a shared 1049 proxy, then the 304 response &MAY; be forwarded to the outbound client. 1050 Otherwise, the recipient &MUST; disregard the 304 response and repeat 1051 the request without any preconditions. 1052 </t> 1053 <t> 1054 If a cache uses a received 304 response to update a cache entry, the 1055 cache &MUST; update the entry to reflect any new field values given in 1056 the response. 1057 </t> 1058 </section> 1059 1060 <section title="412 Precondition Failed" anchor="status.412"> 1061 <iref primary="true" item="412 Precondition Failed (status code)" x:for-anchor=""/> 1062 <iref primary="true" item="Status Codes" subitem="412 Precondition Failed" x:for-anchor=""/> 1063 <t> 1064 The 412 status code indicates that one or more preconditions given in 1065 the request header fields evaluated to false when tested on the server. 1066 This response code allows the client to place preconditions on the 1067 current resource state (its current representations and metadata) 1068 and thus prevent the request method from being applied if the target 1069 resource is in an unexpected state. 1070 </t> 1071 </section> 1067 1072 </section> 1068 1073
Note: See TracChangeset
for help on using the changeset viewer.
