draft-ietf-httpbis-p4-conditional-13.txt | draft-ietf-httpbis-p4-conditional-14.txt | |||
---|---|---|---|---|
HTTPbis Working Group R. Fielding, Ed. | HTTPbis Working Group R. Fielding, Ed. | |||
Internet-Draft Adobe | Internet-Draft Adobe | |||
Obsoletes: 2616 (if approved) J. Gettys | Obsoletes: 2616 (if approved) J. Gettys | |||
Intended status: Standards Track Alcatel-Lucent | Intended status: Standards Track Alcatel-Lucent | |||
Expires: September 15, 2011 J. Mogul | Expires: October 20, 2011 J. Mogul | |||
HP | HP | |||
H. Frystyk | H. Frystyk | |||
Microsoft | Microsoft | |||
L. Masinter | L. Masinter | |||
Adobe | Adobe | |||
P. Leach | P. Leach | |||
Microsoft | Microsoft | |||
T. Berners-Lee | T. Berners-Lee | |||
W3C/MIT | W3C/MIT | |||
Y. Lafon, Ed. | Y. Lafon, Ed. | |||
W3C | W3C | |||
J. Reschke, Ed. | J. Reschke, Ed. | |||
greenbytes | greenbytes | |||
March 14, 2011 | April 18, 2011 | |||
HTTP/1.1, part 4: Conditional Requests | HTTP/1.1, part 4: Conditional Requests | |||
draft-ietf-httpbis-p4-conditional-13 | draft-ietf-httpbis-p4-conditional-14 | |||
Abstract | Abstract | |||
The Hypertext Transfer Protocol (HTTP) is an application-level | The Hypertext Transfer Protocol (HTTP) is an application-level | |||
protocol for distributed, collaborative, hypermedia information | protocol for distributed, collaborative, hypermedia information | |||
systems. HTTP has been in use by the World Wide Web global | systems. HTTP has been in use by the World Wide Web global | |||
information initiative since 1990. This document is Part 4 of the | information initiative since 1990. This document is Part 4 of the | |||
seven-part specification that defines the protocol referred to as | seven-part specification that defines the protocol referred to as | |||
"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines | "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines | |||
request header fields for indicating conditional requests and the | request header fields for indicating conditional requests and the | |||
rules for constructing responses to those requests. | rules for constructing responses to those requests. | |||
Editorial Note (To be removed by RFC Editor) | Editorial Note (To be removed by RFC Editor) | |||
Discussion of this draft should take place on the HTTPBIS working | Discussion of this draft should take place on the HTTPBIS working | |||
group mailing list (ietf-http-wg@w3.org). The current issues list is | group mailing list (ietf-http-wg@w3.org), which is archived at | |||
at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related | <http://lists.w3.org/Archives/Public/ietf-http-wg/>. | |||
The current issues list is at | ||||
<http://tools.ietf.org/wg/httpbis/trac/report/3> and related | ||||
documents (including fancy diffs) can be found at | documents (including fancy diffs) can be found at | |||
<http://tools.ietf.org/wg/httpbis/>. | <http://tools.ietf.org/wg/httpbis/>. | |||
The changes in this draft are summarized in Appendix C.14. | The changes in this draft are summarized in Appendix C.15. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on September 15, 2011. | This Internet-Draft will expire on October 20, 2011. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2011 IETF Trust and the persons identified as the | Copyright (c) 2011 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 3, line 9 | skipping to change at page 3, line 4 | |||
the copyright in such materials, this document may not be modified | the copyright in such materials, this document may not be modified | |||
outside the IETF Standards Process, and derivative works of it may | outside the IETF Standards Process, and derivative works of it may | |||
not be created outside the IETF Standards Process, except to format | not be created outside the IETF Standards Process, except to format | |||
it for publication as an RFC or to translate it into languages other | it for publication as an RFC or to translate it into languages other | |||
than English. | than English. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 | 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 | 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 | |||
1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6 | 2. Resource State Metadata (Validators) . . . . . . . . . . . . . 6 | |||
1.2.2. ABNF Rules defined in other Parts of the | 2.1. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 6 | |||
Specification . . . . . . . . . . . . . . . . . . . . 6 | 2.1.1. Generation . . . . . . . . . . . . . . . . . . . . . . 6 | |||
2. Entity-Tags . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 2.1.2. Comparison . . . . . . . . . . . . . . . . . . . . . . 7 | |||
2.1. Example: Entity-tags varying on Content-Negotiated | 2.2. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
Resources . . . . . . . . . . . . . . . . . . . . . . . . 7 | 2.2.1. Generation . . . . . . . . . . . . . . . . . . . . . . 9 | |||
3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 8 | 2.2.2. Weak versus Strong . . . . . . . . . . . . . . . . . . 9 | |||
3.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 8 | 2.2.3. Comparison . . . . . . . . . . . . . . . . . . . . . . 11 | |||
3.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 8 | 2.2.4. Rules for When to Use Entity-tags and | |||
4. Weak and Strong Validators . . . . . . . . . . . . . . . . . . 9 | Last-Modified Dates . . . . . . . . . . . . . . . . . 11 | |||
5. Rules for When to Use Entity-tags and Last-Modified Dates . . 11 | 2.2.5. Example: Entity-tags varying on Content-Negotiated | |||
6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 13 | Resources . . . . . . . . . . . . . . . . . . . . . . 13 | |||
6.1. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 3. Precondition Header Fields . . . . . . . . . . . . . . . . . . 14 | |||
6.2. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 14 | 3.1. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
6.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 15 | 3.2. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 15 | |||
6.4. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 17 | 3.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 16 | |||
6.5. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 18 | 3.4. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 18 | |||
6.6. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 19 | 3.5. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 | 4. Status Code Definitions . . . . . . . . . . . . . . . . . . . 18 | |||
7.1. Status Code Registration . . . . . . . . . . . . . . . . . 19 | 4.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 18 | |||
7.2. Header Field Registration . . . . . . . . . . . . . . . . 20 | 4.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 19 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 | |||
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 | 5.1. Status Code Registration . . . . . . . . . . . . . . . . . 19 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 | 5.2. Header Field Registration . . . . . . . . . . . . . . . . 20 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . . 21 | 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 | ||||
8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 | ||||
8.2. Informative References . . . . . . . . . . . . . . . . . . 21 | ||||
Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 21 | Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 21 | |||
Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 22 | Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 22 | |||
Appendix C. Change Log (to be removed by RFC Editor before | Appendix C. Change Log (to be removed by RFC Editor before | |||
publication) . . . . . . . . . . . . . . . . . . . . 22 | publication) . . . . . . . . . . . . . . . . . . . . 22 | |||
C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 22 | C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 22 | |||
C.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 23 | C.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 22 | |||
C.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 23 | C.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 23 | |||
C.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 23 | C.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 23 | |||
C.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 23 | C.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 23 | |||
C.6. Since draft-ietf-httpbis-p4-conditional-04 . . . . . . . . 24 | C.6. Since draft-ietf-httpbis-p4-conditional-04 . . . . . . . . 23 | |||
C.7. Since draft-ietf-httpbis-p4-conditional-05 . . . . . . . . 24 | C.7. Since draft-ietf-httpbis-p4-conditional-05 . . . . . . . . 24 | |||
C.8. Since draft-ietf-httpbis-p4-conditional-06 . . . . . . . . 24 | C.8. Since draft-ietf-httpbis-p4-conditional-06 . . . . . . . . 24 | |||
C.9. Since draft-ietf-httpbis-p4-conditional-07 . . . . . . . . 24 | C.9. Since draft-ietf-httpbis-p4-conditional-07 . . . . . . . . 24 | |||
C.10. Since draft-ietf-httpbis-p4-conditional-08 . . . . . . . . 24 | C.10. Since draft-ietf-httpbis-p4-conditional-08 . . . . . . . . 24 | |||
C.11. Since draft-ietf-httpbis-p4-conditional-09 . . . . . . . . 24 | C.11. Since draft-ietf-httpbis-p4-conditional-09 . . . . . . . . 24 | |||
C.12. Since draft-ietf-httpbis-p4-conditional-10 . . . . . . . . 25 | C.12. Since draft-ietf-httpbis-p4-conditional-10 . . . . . . . . 24 | |||
C.13. Since draft-ietf-httpbis-p4-conditional-11 . . . . . . . . 25 | C.13. Since draft-ietf-httpbis-p4-conditional-11 . . . . . . . . 25 | |||
C.14. Since draft-ietf-httpbis-p4-conditional-12 . . . . . . . . 25 | C.14. Since draft-ietf-httpbis-p4-conditional-12 . . . . . . . . 25 | |||
C.15. Since draft-ietf-httpbis-p4-conditional-13 . . . . . . . . 25 | ||||
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 | Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 | |||
1. Introduction | 1. Introduction | |||
This document defines HTTP/1.1 response metadata for indicating | This document defines the HTTP/1.1 conditional request mechanisms, | |||
potential changes to payload content, including modification time | including both response metadata that can be used to indicate or | |||
stamps and opaque entity-tags, and the HTTP conditional request | observe changes to resource state and request header fields that | |||
mechanisms that allow preconditions to be placed on a request method. | specify preconditions to be checked before performing the action | |||
Conditional GET requests allow for efficient cache updates. Other | given by the request method. Conditional GET requests are the most | |||
conditional request methods are used to protect against overwriting | efficient mechanism for HTTP cache updates [Part6]. Conditionals can | |||
or misunderstanding the state of a resource that has been changed | also be applied to state-changing methods, such as PUT and DELETE, to | |||
unbeknownst to the requesting client. | prevent the "lost update" problem: one client accidentally | |||
overwriting the work of another client that has been acting in | ||||
parallel. | ||||
This document is currently disorganized in order to minimize the | Conditional request preconditions are based on the state of the | |||
changes between drafts and enable reviewers to see the smaller errata | target resource as a whole (its current value set) or the state as | |||
changes. A future draft will reorganize the sections to better | observed in a previously obtained representation (one value in that | |||
reflect the content. In particular, the sections on resource | set). A resource might have multiple current representations, each | |||
metadata will be discussed first and then followed by each | with its own observable state. The conditional request mechanisms | |||
conditional request header field, concluding with a definition of | assume that the mapping of requests to corresponding representations | |||
precedence and the expectation of ordering strong validator checks | will be consistent over time if the server intends to take advantage | |||
before weak validator checks. It is likely that more content from | of conditionals. Regardless, if the mapping is inconsistent and the | |||
[Part6] will migrate to this part, where appropriate. The current | server is unable to select the appropriate representation, then no | |||
mess reflects how widely dispersed these topics and associated | harm will result when the precondition evaluates to false. | |||
requirements had become in [RFC2616]. | ||||
We use the term "selected representation" to refer to the current | ||||
representation of the target resource that would have been selected | ||||
in a successful response if the same request had used the method GET | ||||
and had excluded all of the conditional request header fields. The | ||||
conditional request preconditions are evaluated by comparing the | ||||
values provided in the request header fields to the current metadata | ||||
for the selected representation. | ||||
1.1. Requirements | 1.1. Requirements | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in [RFC2119]. | document are to be interpreted as described in [RFC2119]. | |||
An implementation is not compliant if it fails to satisfy one or more | An implementation is not compliant if it fails to satisfy one or more | |||
of the "MUST" or "REQUIRED" level requirements for the protocols it | of the "MUST" or "REQUIRED" level requirements for the protocols it | |||
implements. An implementation that satisfies all the "MUST" or | implements. An implementation that satisfies all the "MUST" or | |||
skipping to change at page 6, line 8 | skipping to change at page 6, line 19 | |||
rule). Appendix B shows the collected ABNF, with the list rule | rule). Appendix B shows the collected ABNF, with the list rule | |||
expanded. | expanded. | |||
The following core rules are included by reference, as defined in | The following core rules are included by reference, as defined in | |||
[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF | [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF | |||
(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), | (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), | |||
HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit | HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit | |||
sequence of data), SP (space), VCHAR (any visible USASCII character), | sequence of data), SP (space), VCHAR (any visible USASCII character), | |||
and WSP (whitespace). | and WSP (whitespace). | |||
1.2.1. Core Rules | The ABNF rules below are defined in other parts: | |||
The core rules below are defined in Section 1.2.2 of [Part1]: | ||||
quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> | quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> | |||
OWS = <OWS, defined in [Part1], Section 1.2.2> | OWS = <OWS, defined in [Part1], Section 1.2.2> | |||
HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> | ||||
1.2.2. ABNF Rules defined in other Parts of the Specification | 2. Resource State Metadata (Validators) | |||
The ABNF rules below are defined in other parts: | This specification defines two forms of metadata that are commonly | |||
used to observe resource state and test for preconditions: | ||||
modification dates and opaque entity tags. Additional metadata that | ||||
reflects resource state has been defined by various extensions of | ||||
HTTP, such as WebDAV [RFC4918], that are beyond the scope of this | ||||
specification. A resource metadata value is referred to as a | ||||
"validator" when it is used within a precondition. | ||||
HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> | 2.1. Last-Modified | |||
2. Entity-Tags | The "Last-Modified" header field indicates the date and time at which | |||
the origin server believes the selected representation was last | ||||
modified. | ||||
Entity-tags are used for comparing two or more representations of the | Last-Modified = HTTP-date | |||
same resource. HTTP/1.1 uses entity-tags in the ETag (Section 6.1), | ||||
If-Match (Section 6.2), If-None-Match (Section 6.4), and If-Range | ||||
(Section 5.3 of [Part5]) header fields. The definition of how they | ||||
are used and compared as cache validators is in Section 4. An | ||||
entity-tag consists of an opaque quoted string, possibly prefixed by | ||||
a weakness indicator. | ||||
entity-tag = [ weak ] opaque-tag | An example of its use is | |||
weak = %x57.2F ; "W/", case-sensitive | ||||
opaque-tag = quoted-string | ||||
A "strong entity-tag" MAY be shared by two representations of a | Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT | |||
resource only if they are equivalent by octet equality. | ||||
A "weak entity-tag", indicated by the "W/" prefix, MAY be shared by | 2.1.1. Generation | |||
two representations of a resource only if the representations are | ||||
equivalent and could be substituted for each other with no | ||||
significant change in semantics. A weak entity-tag can only be used | ||||
for weak comparison. | ||||
An entity-tag MUST be unique across all versions of all | Origin servers SHOULD send Last-Modified for any selected | |||
representations associated with a particular resource. A given | representation for which a last modification date can be reasonably | |||
entity-tag value MAY be used for representations obtained by requests | and consistently determined, since its use in conditional requests | |||
on different URIs. The use of the same entity-tag value in | and evaluating cache freshness ([Part6]) results in a substantial | |||
conjunction with representations obtained by requests on different | reduction of HTTP traffic on the Internet and can be a significant | |||
URIs does not imply the equivalence of those representations. | factor in improving service scalability and reliability. | |||
2.1. Example: Entity-tags varying on Content-Negotiated Resources | A representation is typically the sum of many parts behind the | |||
resource interface. The last-modified time would usually be the most | ||||
recent time that any of those parts were changed. How that value is | ||||
determined for any given resource is an implementation detail beyond | ||||
the scope of this specification. What matters to HTTP is how | ||||
recipients of the Last-Modified header field can use its value to | ||||
make conditional requests and test the validity of locally cached | ||||
responses. | ||||
Consider a resource that is subject to content negotiation (Section 5 | An origin server SHOULD obtain the Last-Modified value of the | |||
of [Part3]), and where the representations returned upon a GET | representation as close as possible to the time that it generates the | |||
request vary based on the Accept-Encoding request header field | Date field-value for its response. This allows a recipient to make | |||
(Section 6.3 of [Part3]): | an accurate assessment of the representation's modification time, | |||
especially if the representation changes near the time that the | ||||
response is generated. | ||||
>> Request: | An origin server with a clock MUST NOT send a Last-Modified date that | |||
is later than the server's time of message origination (Date). If | ||||
the last modification time is derived from implementation-specific | ||||
metadata that evaluates to some time in the future, according to the | ||||
origin server's clock, then the origin server MUST replace that value | ||||
with the message origination date. This prevents a future | ||||
modification date from having an adverse impact on cache validation. | ||||
GET /index HTTP/1.1 | 2.1.2. Comparison | |||
Host: www.example.com | ||||
Accept-Encoding: gzip | ||||
In this case, the response might or might not use the gzip content | A Last-Modified time, when used as a validator in a request, is | |||
coding. If it does not, the response might look like: | implicitly weak unless it is possible to deduce that it is strong, | |||
using the following rules: | ||||
>> Response: | o The validator is being compared by an origin server to the actual | |||
current validator for the representation and, | ||||
HTTP/1.1 200 OK | o That origin server reliably knows that the associated | |||
Date: Thu, 26 Mar 2010 00:05:00 GMT | representation did not change twice during the second covered by | |||
ETag: "123-a" | the presented validator. | |||
Content-Length: 70 | ||||
Vary: Accept-Encoding | ||||
Content-Type: text/plain | ||||
Hello World! | or | |||
Hello World! | ||||
Hello World! | ||||
Hello World! | ||||
Hello World! | ||||
An alternative representation that does use gzip content coding would | o The validator is about to be used by a client in an If-Modified- | |||
be: | Since or If-Unmodified-Since header field, because the client has | |||
a cache entry for the associated representation, and | ||||
>> Response: | o That cache entry includes a Date value, which gives the time when | |||
the origin server sent the original response, and | ||||
HTTP/1.1 200 OK | o The presented Last-Modified time is at least 60 seconds before the | |||
Date: Thu, 26 Mar 2010 00:05:00 GMT | Date value. | |||
ETag: "123-b" | ||||
Content-Length: 43 | ||||
Vary: Accept-Encoding | ||||
Content-Type: text/plain | ||||
Content-Encoding: gzip | ||||
...binary data... | or | |||
Note: Content codings are a property of the representation, so | o The validator is being compared by an intermediate cache to the | |||
therefore an entity-tag of an encoded representation must be | validator stored in its cache entry for the representation, and | |||
distinct from an unencoded representation to prevent conflicts | ||||
during cache updates and range requests. In contrast, transfer | ||||
codings (Section 6.2 of [Part1]) apply only during message | ||||
transfer and do not require distinct entity-tags. | ||||
3. Status Code Definitions | o That cache entry includes a Date value, which gives the time when | |||
the origin server sent the original response, and | ||||
3.1. 304 Not Modified | o The presented Last-Modified time is at least 60 seconds before the | |||
Date value. | ||||
If the client has performed a conditional GET request and access is | This method relies on the fact that if two different responses were | |||
allowed, but the document has not been modified, the server SHOULD | sent by the origin server during the same second, but both had the | |||
respond with this status code. The 304 response MUST NOT contain a | same Last-Modified time, then at least one of those responses would | |||
message-body, and thus is always terminated by the first empty line | have a Date value equal to its Last-Modified time. The arbitrary 60- | |||
after the header fields. | second limit guards against the possibility that the Date and Last- | |||
Modified values are generated from different clocks, or at somewhat | ||||
different times during the preparation of the response. An | ||||
implementation MAY use a value larger than 60 seconds, if it is | ||||
believed that 60 seconds is too short. | ||||
A 304 response MUST include a Date header field (Section 9.3 of | 2.2. ETag | |||
[Part1]) unless its omission is required by Section 9.3.1 of [Part1]. | ||||
If a 200 response to the same request would have included any of the | ||||
header fields Cache-Control, Content-Location, ETag, Expires, Last- | ||||
Modified, or Vary, then those same header fields MUST be sent in a | ||||
304 response. | ||||
Since the goal of a 304 response is to minimize information transfer | The ETag header field provides the current entity-tag for the | |||
when the recipient already has one or more cached representations, | selected representation. An entity-tag is an opaque validator for | |||
the response SHOULD NOT include representation metadata other than | differentiating between multiple representations of the same | |||
the above listed fields unless said metadata exists for the purpose | resource, regardless of whether those multiple representations are | |||
of guiding cache updates (e.g., future HTTP extensions). | due to resource state changes over time, content negotiation | |||
resulting in multiple representations being valid at the same time, | ||||
or both. An entity-tag consists of an opaque quoted string, possibly | ||||
prefixed by a weakness indicator. | ||||
If a 304 response includes an entity-tag that indicates a | ETag = entity-tag | |||
representation not currently cached, then the recipient MUST NOT use | ||||
the 304 to update its own cache. If that conditional request | ||||
originated with an outbound client, such as a user agent with its own | ||||
cache sending a conditional GET to a shared proxy, then the 304 | ||||
response MAY be forwarded to the outbound client. Otherwise, | ||||
disregard the response and repeat the request without the | ||||
conditional. | ||||
If a cache uses a received 304 response to update a cache entry, the | entity-tag = [ weak ] opaque-tag | |||
cache MUST update the entry to reflect any new field values given in | weak = %x57.2F ; "W/", case-sensitive | |||
the response. | opaque-tag = quoted-string | |||
3.2. 412 Precondition Failed | An entity-tag can be more reliable for validation than a modification | |||
date in situations where it is inconvenient to store modification | ||||
dates, where the one-second resolution of HTTP date values is not | ||||
sufficient, or where modification dates are not consistently | ||||
maintained. | ||||
The precondition given in one or more of the header fields evaluated | Examples: | |||
to false when it was tested on the server. This response code allows | ||||
the client to place preconditions on the current resource metadata | ||||
(header field data) and thus prevent the requested method from being | ||||
applied to a resource other than the one intended. | ||||
4. Weak and Strong Validators | ETag: "xyzzy" | |||
ETag: W/"xyzzy" | ||||
ETag: "" | ||||
2.2.1. Generation | ||||
The principle behind entity-tags is that only the service author | ||||
knows the implementation of a resource well enough to select the most | ||||
accurate and efficient validation mechanism for that resource, and | ||||
that any such mechanism can be mapped to a simple sequence of octets | ||||
for easy comparison. Since the value is opaque, there is no need for | ||||
the client to be aware of how each entity-tag is constructed. | ||||
For example, a resource that has implementation-specific versioning | ||||
applied to all changes might use an internal revision number, perhaps | ||||
combined with a variance identifier for content negotiation, to | ||||
accurately differentiate between representations. Other | ||||
implementations might use a stored hash of representation content, a | ||||
combination of various filesystem attributes, or a modification | ||||
timestamp that has sub-second resolution. | ||||
Origin servers SHOULD send ETag for any selected representation for | ||||
which detection of changes can be reasonably and consistently | ||||
determined, since the entity-tag's use in conditional requests and | ||||
evaluating cache freshness ([Part6]) can result in a substantial | ||||
reduction of HTTP network traffic and can be a significant factor in | ||||
improving service scalability and reliability. | ||||
2.2.2. Weak versus Strong | ||||
Since both origin servers and caches will compare two validators to | Since both origin servers and caches will compare two validators to | |||
decide if they represent the same or different representations, one | decide if they indicate the same or different representations, one | |||
normally would expect that if the representation (including both | normally would expect that if the representation (including both | |||
representation header fields and representation body) changes in any | representation header fields and representation body) changes in any | |||
way, then the associated validator would change as well. If this is | way, then the associated validator would change as well. If this is | |||
true, then we call this validator a "strong validator". | true, then we call that validator a "strong validator". One example | |||
of a strong validator is an integer that is incremented in stable | ||||
storage every time a representation is changed. | ||||
However, there might be cases when a server prefers to change the | However, there might be cases when a server prefers to change the | |||
validator only on semantically significant changes, and not when | validator only when it desires cached representations to be | |||
insignificant aspects of the representation change. A validator that | invalidated. For example, the representation of a weather report | |||
does not always change when the representation changes is a "weak | that changes in content every second, based on dynamic measurements, | |||
validator". | might be grouped into sets of equivalent representations (from the | |||
origin server's perspective) in order to allow cached representations | ||||
to be valid for a reasonable period of time (perhaps adjusted | ||||
dynamically based on server load or weather quality). A validator | ||||
that does not always change when the representation changes is a | ||||
"weak validator". | ||||
An entity-tag is normally a strong validator, but the protocol | One can think of a strong validator as part of an identifier for a | |||
provides a mechanism to tag an entity-tag as "weak". One can think | specific representation, whereas a weak validator is part of an | |||
of a strong validator as one that changes whenever the sequence of | identifier for a set of equivalent representations (where this notion | |||
bits in a representation changes, while a weak value changes whenever | of equivalence is entirely governed by the origin server and beyond | |||
the meaning of a representation changes. Alternatively, one can | the scope of this specification). | |||
think of a strong validator as part of an identifier for a specific | ||||
representation, whereas a weak validator is part of an identifier for | ||||
a set of semantically equivalent representations. | ||||
Note: One example of a strong validator is an integer that is | An entity-tag is normally a strong validator, but the protocol | |||
incremented in stable storage every time a representation is | provides a mechanism to tag an entity-tag as "weak". | |||
changed. | ||||
A representation's modification time, if defined with only one- | A representation's modification time, if defined with only one- | |||
second resolution, could be a weak validator, since it is possible | second resolution, could be a weak validator, since it is possible | |||
that the representation might be modified twice during a single | that the representation might be modified twice during a single | |||
second. | second. | |||
Support for weak validators is optional. However, weak validators | Support for weak validators is optional. However, weak validators | |||
allow for more efficient caching of equivalent objects; for | allow for more efficient caching of equivalent objects; for | |||
example, a hit counter on a site is probably good enough if it is | example, a hit counter on a site is probably good enough if it is | |||
updated every few days or weeks, and any value during that period | updated every few days or weeks, and any value during that period | |||
is likely "good enough" to be equivalent. | is likely "good enough" to be equivalent. | |||
A "use" of a validator is either when a client generates a request | A strong entity-tag MUST change whenever the associated | |||
and includes the validator in a validating header field, or when a | representation changes in any way. A weak entity-tag SHOULD change | |||
server compares two validators. | whenever the origin server considers prior representations to be | |||
unacceptable as a substitute for the current representation. In | ||||
other words, a weak entity tag SHOULD change whenever the origin | ||||
server wants caches to invalidate old responses. | ||||
Strong validators are usable in any context. Weak validators are | A "strong entity-tag" MAY be shared by two representations of a | |||
only usable in contexts that do not depend on exact equality of a | resource only if they are equivalent by octet equality. | |||
representation. For example, either kind is usable for a normal | ||||
conditional GET. However, only a strong validator is usable for a | ||||
sub-range retrieval, since otherwise the client might end up with an | ||||
internally inconsistent representation. | ||||
Clients MUST NOT use weak validators in range requests ([Part5]). | A "weak entity-tag", indicated by the "W/" prefix, MAY be shared by | |||
two representations of a resource. A weak entity-tag can only be | ||||
used for weak comparison. | ||||
The only function that HTTP/1.1 defines on validators is comparison. | Cache entries might persist for arbitrarily long periods, regardless | |||
There are two validator comparison functions, depending on whether | of expiration times. Thus, a cache might attempt to validate an | |||
entry using a validator that it obtained in the distant past. A | ||||
strong entity-tag MUST be unique across all versions of all | ||||
representations associated with a particular resource over time. | ||||
However, there is no implication of uniqueness across entity-tags of | ||||
different resources (i.e., the same entity-tag value might be in use | ||||
for representations of multiple resources at the same time and does | ||||
not imply that those representations are equivalent). | ||||
2.2.3. Comparison | ||||
There are two entity-tag comparison functions, depending on whether | ||||
the comparison context allows the use of weak validators or not: | the comparison context allows the use of weak validators or not: | |||
o The strong comparison function: in order to be considered equal, | o The strong comparison function: in order to be considered equal, | |||
both opaque-tags MUST be identical character-by-character, and | both opaque-tags MUST be identical character-by-character, and | |||
both MUST NOT be weak. | both MUST NOT be weak. | |||
o The weak comparison function: in order to be considered equal, | o The weak comparison function: in order to be considered equal, | |||
both opaque-tags MUST be identical character-by-character, but | both opaque-tags MUST be identical character-by-character, but | |||
either or both of them MAY be tagged as "weak" without affecting | either or both of them MAY be tagged as "weak" without affecting | |||
the result. | the result. | |||
A "use" of a validator is either when a client generates a request | ||||
and includes the validator in a precondition, or when a server | ||||
compares two validators. | ||||
Strong validators are usable in any context. Weak validators are | ||||
only usable in contexts that do not depend on exact equality of a | ||||
representation. For example, either kind is usable for a normal | ||||
conditional GET. | ||||
The example below shows the results for a set of entity-tag pairs, | The example below shows the results for a set of entity-tag pairs, | |||
and both the weak and strong comparison function results: | and both the weak and strong comparison function results: | |||
+--------+--------+-------------------+-----------------+ | +--------+--------+-------------------+-----------------+ | |||
| ETag 1 | ETag 2 | Strong Comparison | Weak Comparison | | | ETag 1 | ETag 2 | Strong Comparison | Weak Comparison | | |||
+--------+--------+-------------------+-----------------+ | +--------+--------+-------------------+-----------------+ | |||
| W/"1" | W/"1" | no match | match | | | W/"1" | W/"1" | no match | match | | |||
| W/"1" | W/"2" | no match | no match | | | W/"1" | W/"2" | no match | no match | | |||
| W/"1" | "1" | no match | match | | | W/"1" | "1" | no match | match | | |||
| "1" | "1" | match | match | | | "1" | "1" | match | match | | |||
+--------+--------+-------------------+-----------------+ | +--------+--------+-------------------+-----------------+ | |||
An entity-tag is strong unless it is explicitly tagged as weak. | An entity-tag is strong unless it is explicitly tagged as weak. | |||
Section 2 gives the syntax for entity-tags. | ||||
A Last-Modified time, when used as a validator in a request, is | 2.2.4. Rules for When to Use Entity-tags and Last-Modified Dates | |||
implicitly weak unless it is possible to deduce that it is strong, | ||||
using the following rules: | ||||
o The validator is being compared by an origin server to the actual | ||||
current validator for the representation and, | ||||
o That origin server reliably knows that the associated | ||||
representation did not change twice during the second covered by | ||||
the presented validator. | ||||
or | ||||
o The validator is about to be used by a client in an If-Modified- | ||||
Since or If-Unmodified-Since header field, because the client has | ||||
a cache entry for the associated representation, and | ||||
o That cache entry includes a Date value, which gives the time when | ||||
the origin server sent the original response, and | ||||
o The presented Last-Modified time is at least 60 seconds before the | ||||
Date value. | ||||
or | ||||
o The validator is being compared by an intermediate cache to the | ||||
validator stored in its cache entry for the representation, and | ||||
o That cache entry includes a Date value, which gives the time when | ||||
the origin server sent the original response, and | ||||
o The presented Last-Modified time is at least 60 seconds before the | ||||
Date value. | ||||
This method relies on the fact that if two different responses were | ||||
sent by the origin server during the same second, but both had the | ||||
same Last-Modified time, then at least one of those responses would | ||||
have a Date value equal to its Last-Modified time. The arbitrary 60- | ||||
second limit guards against the possibility that the Date and Last- | ||||
Modified values are generated from different clocks, or at somewhat | ||||
different times during the preparation of the response. An | ||||
implementation MAY use a value larger than 60 seconds, if it is | ||||
believed that 60 seconds is too short. | ||||
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, it | ||||
MAY do this only if the Last-Modified time is strong in the sense | ||||
described here. | ||||
A cache or origin server receiving a conditional range request | ||||
([Part5]) MUST use the strong comparison function to evaluate the | ||||
condition. | ||||
These rules allow HTTP/1.1 caches and clients to safely perform sub- | ||||
range retrievals on values that have been obtained from HTTP/1.0 | ||||
servers. | ||||
5. Rules for When to Use Entity-tags and Last-Modified Dates | ||||
We adopt a set of rules and recommendations for origin servers, | We adopt a set of rules and recommendations for origin servers, | |||
clients, and caches regarding when various validator types ought to | clients, and caches regarding when various validator types ought to | |||
be used, and for what purposes. | be used, and for what purposes. | |||
HTTP/1.1 origin servers: | HTTP/1.1 origin servers: | |||
o SHOULD send an entity-tag validator unless it is not feasible to | o SHOULD send an entity-tag validator unless it is not feasible to | |||
generate one. | generate one. | |||
o MAY send a weak entity-tag instead of a strong entity-tag, if | o MAY send a weak entity-tag instead of a strong entity-tag, if | |||
performance considerations support the use of weak entity-tags, or | performance considerations support the use of weak entity-tags, or | |||
if it is unfeasible to send a strong entity-tag. | if it is unfeasible to send a strong entity-tag. | |||
o SHOULD send a Last-Modified value if it is feasible to send one, | o SHOULD send a Last-Modified value if it is feasible to send one. | |||
unless the risk of a breakdown in semantic transparency that could | ||||
result from using this date in an If-Modified-Since header field | ||||
would lead to serious problems. | ||||
In other words, the preferred behavior for an HTTP/1.1 origin server | 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 value. | is to send both a strong entity-tag and a Last-Modified value. | |||
In order to be legitimate, a strong entity-tag MUST change whenever | ||||
the associated representation changes in any way. A weak entity-tag | ||||
SHOULD change whenever the associated representation changes in a | ||||
semantically significant way. | ||||
Note: In order to provide semantically transparent caching, an | ||||
origin server must avoid reusing a specific strong entity-tag | ||||
value for two different representations, or reusing a specific | ||||
weak entity-tag value for two semantically different | ||||
representations. Cache entries might persist for arbitrarily long | ||||
periods, regardless of expiration times, so it might be | ||||
inappropriate to expect that a cache will never again attempt to | ||||
validate an entry using a validator that it obtained at some point | ||||
in the past. | ||||
HTTP/1.1 clients: | HTTP/1.1 clients: | |||
o MUST use that entity-tag in any cache-conditional request (using | o MUST use that entity-tag in any cache-conditional request (using | |||
If-Match or If-None-Match) if an entity-tag has been provided by | If-Match or If-None-Match) if an entity-tag has been provided by | |||
the origin server. | the origin server. | |||
o SHOULD use the Last-Modified value in non-subrange cache- | o SHOULD use the Last-Modified value in non-subrange cache- | |||
conditional requests (using If-Modified-Since) if only a Last- | conditional requests (using If-Modified-Since) if only a Last- | |||
Modified value has been provided by the origin server. | Modified value has been provided by the origin server. | |||
skipping to change at page 13, line 38 | skipping to change at page 13, line 13 | |||
conservative assumptions about the validators they receive. | conservative assumptions about the validators they receive. | |||
HTTP/1.0 clients and caches might ignore entity-tags. Generally, | HTTP/1.0 clients and caches might ignore entity-tags. Generally, | |||
last-modified values received or used by these systems will | last-modified values received or used by these systems will | |||
support transparent and efficient caching, and so HTTP/1.1 origin | support transparent and efficient caching, and so HTTP/1.1 origin | |||
servers should provide Last-Modified values. In those rare cases | servers should provide Last-Modified values. In those rare cases | |||
where the use of a Last-Modified value as a validator by an | where the use of a Last-Modified value as a validator by an | |||
HTTP/1.0 system could result in a serious problem, then HTTP/1.1 | HTTP/1.0 system could result in a serious problem, then HTTP/1.1 | |||
origin servers should not provide one. | origin servers should not provide one. | |||
6. Header Field Definitions | 2.2.5. Example: Entity-tags varying on Content-Negotiated Resources | |||
This section defines the syntax and semantics of HTTP/1.1 header | Consider a resource that is subject to content negotiation (Section 5 | |||
fields related to conditional requests. | of [Part3]), and where the representations returned upon a GET | |||
request vary based on the Accept-Encoding request header field | ||||
(Section 6.3 of [Part3]): | ||||
6.1. ETag | >> Request: | |||
The "ETag" header field provides the current value of the entity-tag | GET /index HTTP/1.1 | |||
(see Section 2) for one representation of the target resource. An | Host: www.example.com | |||
entity-tag is intended for use as a resource-local identifier for | Accept-Encoding: gzip | |||
differentiating between representations of the same resource that | ||||
vary over time or via content negotiation (see Section 4). | ||||
ETag = "ETag" ":" OWS ETag-v | In this case, the response might or might not use the gzip content | |||
ETag-v = entity-tag | coding. If it does not, the response might look like: | |||
Examples: | >> Response: | |||
ETag: "xyzzy" | HTTP/1.1 200 OK | |||
ETag: W/"xyzzy" | Date: Thu, 26 Mar 2010 00:05:00 GMT | |||
ETag: "" | ETag: "123-a" | |||
Content-Length: 70 | ||||
Vary: Accept-Encoding | ||||
Content-Type: text/plain | ||||
An entity-tag provides an "opaque" cache validator that allows for | Hello World! | |||
more reliable validation than modification dates in situations where | Hello World! | |||
it is inconvenient to store modification dates, where the one-second | Hello World! | |||
resolution of HTTP date values is not sufficient, or where the origin | Hello World! | |||
server wishes to avoid certain paradoxes that might arise from the | Hello World! | |||
use of modification dates. | ||||
The principle behind entity-tags is that only the service author | An alternative representation that does use gzip content coding would | |||
knows the semantics of a resource well enough to select an | be: | |||
appropriate cache validation mechanism, and the specification of any | ||||
validator comparison function more complex than byte-equality would | ||||
open up a can of worms. Thus, comparisons of any other header fields | ||||
(except Last-Modified, for compatibility with HTTP/1.0) are never | ||||
used for purposes of validating a cache entry. | ||||
6.2. If-Match | >> Response: | |||
The "If-Match" header field is used to make a request method | HTTP/1.1 200 OK | |||
conditional. A client that has one or more representations | Date: Thu, 26 Mar 2010 00:05:00 GMT | |||
previously obtained from the resource can verify that one of those | ETag: "123-b" | |||
representations is current by including a list of their associated | Content-Length: 43 | |||
entity-tags in the If-Match header field. | Vary: Accept-Encoding | |||
Content-Type: text/plain | ||||
Content-Encoding: gzip | ||||
This allows efficient updates of cached information with a minimum | ...binary data... | |||
amount of transaction overhead. It is also used when updating | ||||
resources, to prevent inadvertent modification of the wrong version | ||||
of a resource. As a special case, the value "*" matches any current | ||||
representation of the resource. | ||||
If-Match = "If-Match" ":" OWS If-Match-v | Note: Content codings are a property of the representation, so | |||
If-Match-v = "*" / 1#entity-tag | therefore an entity-tag of an encoded representation must be | |||
distinct from an unencoded representation to prevent conflicts | ||||
during cache updates and range requests. In contrast, transfer | ||||
codings (Section 6.2 of [Part1]) apply only during message | ||||
transfer and do not require distinct entity-tags. | ||||
If any of the entity-tags match the entity-tag of the representation | 3. Precondition Header Fields | |||
that would have been returned in the response to a similar GET | ||||
request (without the If-Match header field) on that resource, or if | This section defines the syntax and semantics of HTTP/1.1 header | |||
"*" is given and any current representation exists for that resource, | fields for applying preconditions on requests. | |||
then the server MAY perform the requested method as if the If-Match | ||||
header field did not exist. | 3.1. If-Match | |||
The "If-Match" header field MAY be used to make a request method | ||||
conditional on the current existence or value of an entity-tag for | ||||
one or more representations of the target resource. If-Match is | ||||
generally useful for resource update requests, such as PUT requests, | ||||
as a means for protecting against accidental overwrites when multiple | ||||
clients are acting in parallel on the same resource (i.e., the "lost | ||||
update" problem). An If-Match field-value of "*" places the | ||||
precondition on the existence of any current representation for the | ||||
target resource. | ||||
If-Match = "*" / 1#entity-tag | ||||
If any of the entity-tags listed in the If-Match field value match | ||||
(as per Section 2.2.3) the entity-tag of the selected representation | ||||
for the target resource, or if "*" is given and any current | ||||
representation exists for the target resource, then the server MAY | ||||
perform the request method as if the If-Match header field was not | ||||
present. | ||||
If none of the entity-tags match, or if "*" is given and no current | If none of the entity-tags match, or if "*" is given and no current | |||
representation exists, the server MUST NOT perform the requested | representation exists, the server MUST NOT perform the requested | |||
method, and MUST return a 412 (Precondition Failed) response. This | method. Instead, the server MUST respond with the 412 (Precondition | |||
behavior is most useful when the client wants to prevent an updating | Failed) status code. | |||
request method, such as PUT, from modifying a resource that has | ||||
changed since the client last retrieved it. | ||||
If the request would, without the If-Match header field, result in | If the request would, without the If-Match header field, result in | |||
anything other than a 2xx or 412 status code, then the If-Match | anything other than a 2xx or 412 status code, then the If-Match | |||
header field MUST be ignored. | header field MUST be ignored. | |||
The meaning of "If-Match: *" is that the request method SHOULD be | Examples: | |||
performed if the representation selected by the origin server (or by | ||||
a cache, possibly using the Vary mechanism, see Section 3.5 of | ||||
[Part6]) exists, and MUST NOT be performed if the representation does | ||||
not exist. | ||||
A request intended to update a resource (e.g., a PUT) MAY include an | ||||
If-Match header field to signal that the request method MUST NOT be | ||||
applied if the representation corresponding to the If-Match value (a | ||||
single entity-tag) is no longer a representation of that resource. | ||||
This allows the user to indicate that they do not wish the request to | ||||
be successful if the resource has been changed without their | ||||
knowledge. Examples: | ||||
If-Match: "xyzzy" | If-Match: "xyzzy" | |||
If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" | If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" | |||
If-Match: * | If-Match: * | |||
The result of a request having both an If-Match header field and | 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 is | either an If-None-Match or an If-Modified-Since header fields is | |||
undefined by this specification. | undefined by this specification. | |||
6.3. If-Modified-Since | 3.2. If-None-Match | |||
The "If-Modified-Since" header field is used to make a request method | The "If-None-Match" header field MAY be used to make a request method | |||
conditional by date: if the representation that would have been | conditional on not matching any of the current entity-tag values for | |||
transferred in a 200 response to a GET request has not been modified | representations of the target resource. If-None-Match is primarily | |||
since the time specified in this field, then do not perform the | used in conditional GET requests to enable efficient updates of | |||
method; instead, respond as detailed below. | cached information with a minimum amount of transaction overhead. A | |||
client that has one or more representations previously obtained from | ||||
the target resource can send If-None-Match with a list of the | ||||
associated entity-tags in the hope of receiving a 304 response if at | ||||
least one of those representations matches the selected | ||||
representation. | ||||
If-Modified-Since = "If-Modified-Since" ":" OWS | If-None-Match MAY also be used with a value of "*" to prevent an | |||
If-Modified-Since-v | unsafe request method (e.g., PUT) from inadvertently modifying an | |||
If-Modified-Since-v = HTTP-date | existing representation of the target resource when the client | |||
believes that the resource does not have a current representation. | ||||
This is a variation on the "lost update" problem that might arise if | ||||
more than one client attempts to create an initial representation for | ||||
the target resource. | ||||
If-None-Match = "*" / 1#entity-tag | ||||
If any of the entity-tags listed in the If-None-Match field-value | ||||
match (as per Section 2.2.3) the entity-tag of the selected | ||||
representation, or if "*" is given and any current representation | ||||
exists for that resource, then the server MUST NOT perform the | ||||
requested method. Instead, if the request method was GET or HEAD, | ||||
the server SHOULD respond with a 304 (Not Modified) status code, | ||||
including the cache-related header fields (particularly ETag) of the | ||||
selected representation that has a matching entity-tag. For all | ||||
other request methods, the server MUST respond with a 412 | ||||
(Precondition Failed) status code. | ||||
If none of the entity-tags match, then the server MAY perform the | ||||
requested method as if the If-None-Match header field did not exist, | ||||
but MUST also ignore any If-Modified-Since header field(s) in the | ||||
request. That is, if no entity-tags match, then the server MUST NOT | ||||
return a 304 (Not Modified) response. | ||||
If the request would, without the If-None-Match header field, result | ||||
in anything other than a 2xx or 304 status code, then the If-None- | ||||
Match header field MUST be ignored. (See Section 2.2.4 for a | ||||
discussion of server behavior when both If-Modified-Since and If- | ||||
None-Match appear in the same request.) | ||||
Examples: | ||||
If-None-Match: "xyzzy" | ||||
If-None-Match: W/"xyzzy" | ||||
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" | ||||
If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz" | ||||
If-None-Match: * | ||||
The result of a request having both an If-None-Match header field and | ||||
either an If-Match or an If-Unmodified-Since header fields is | ||||
undefined by this specification. | ||||
3.3. If-Modified-Since | ||||
The "If-Modified-Since" header field MAY be used to make a request | ||||
method conditional by modification date: if the selected | ||||
representation has not been modified since the time specified in this | ||||
field, then do not perform the request method; instead, respond as | ||||
detailed below. | ||||
If-Modified-Since = HTTP-date | ||||
An example of the field is: | An example of the field is: | |||
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT | If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT | |||
A GET method with an If-Modified-Since header field and no Range | A GET method with an If-Modified-Since header field and no Range | |||
header field requests that the representation be transferred only if | header field requests that the selected representation be transferred | |||
it has been modified since the date given by the If-Modified-Since | only if it has been modified since the date given by the If-Modified- | |||
header field. The algorithm for determining this includes the | Since header field. The algorithm for determining this includes the | |||
following cases: | following cases: | |||
1. If the request would normally result in anything other than a 200 | 1. If the request would normally result in anything other than a 200 | |||
(OK) status code, or if the passed If-Modified-Since date is | (OK) status code, or if the passed If-Modified-Since date is | |||
invalid, the response is exactly the same as for a normal GET. A | invalid, the response is exactly the same as for a normal GET. A | |||
date which is later than the server's current time is invalid. | date which is later than the server's current time is invalid. | |||
2. If the representation has been modified since the If-Modified- | 2. If the selected representation has been modified since the If- | |||
Since date, the response is exactly the same as for a normal GET. | Modified-Since date, the response is exactly the same as for a | |||
normal GET. | ||||
3. If the representation has not been modified since a valid If- | 3. If the selected representation has not been modified since a | |||
Modified-Since date, the server SHOULD return a 304 (Not | valid If-Modified-Since date, the server SHOULD return a 304 (Not | |||
Modified) response. | Modified) response. | |||
The purpose of this feature is to allow efficient updates of cached | The purpose of this feature is to allow efficient updates of cached | |||
information with a minimum amount of transaction overhead. | information with a minimum amount of transaction overhead. | |||
Note: The Range header field modifies the meaning of If-Modified- | Note: The Range header field modifies the meaning of If-Modified- | |||
Since; see Section 5.4 of [Part5] for full details. | Since; see Section 5.4 of [Part5] for full details. | |||
Note: If-Modified-Since times are interpreted by the server, whose | Note: If-Modified-Since times are interpreted by the server, whose | |||
clock might not be synchronized with the client. | clock might not be synchronized with the client. | |||
skipping to change at page 17, line 7 | skipping to change at page 18, line 5 | |||
Modified-Since date of a subsequent request, and the possibility | Modified-Since date of a subsequent request, and the possibility | |||
of clock-skew-related problems if the If-Modified-Since date is | of clock-skew-related problems if the If-Modified-Since date is | |||
derived from the client's clock without correction to the server's | derived from the client's clock without correction to the server's | |||
clock. Corrections for different time bases between client and | clock. Corrections for different time bases between client and | |||
server are at best approximate due to network latency. | server are at best approximate due to network latency. | |||
The result of a request having both an If-Modified-Since header field | The result of a request having both an If-Modified-Since header field | |||
and either an If-Match or an If-Unmodified-Since header fields is | and either an If-Match or an If-Unmodified-Since header fields is | |||
undefined by this specification. | undefined by this specification. | |||
6.4. If-None-Match | 3.4. If-Unmodified-Since | |||
The "If-None-Match" header field is used to make a request method | ||||
conditional. A client that has one or more representations | ||||
previously obtained from the resource can verify that none of those | ||||
representations is current by including a list of their associated | ||||
entity-tags in the If-None-Match header field. | ||||
This allows efficient updates of cached information with a minimum | ||||
amount of transaction overhead. It is also used to prevent a request | ||||
method (e.g., PUT) from inadvertently modifying an existing resource | ||||
when the client believes that the resource does not exist. | ||||
As a special case, the value "*" matches any current representation | ||||
of the resource. | ||||
If-None-Match = "If-None-Match" ":" OWS If-None-Match-v | ||||
If-None-Match-v = "*" / 1#entity-tag | ||||
If any of the entity-tags match the entity-tag of the representation | ||||
that would have been returned in the response to a similar GET | ||||
request (without the If-None-Match header field) on that resource, or | ||||
if "*" is given and any current representation exists for that | ||||
resource, then the server MUST NOT perform the requested method, | ||||
unless required to do so because the resource's modification date | ||||
fails to match that supplied in an If-Modified-Since header field in | ||||
the request. Instead, if the request method was GET or HEAD, the | ||||
server SHOULD respond with a 304 (Not Modified) response, including | ||||
the cache-related header fields (particularly ETag) of one of the | ||||
representations that matched. For all other request methods, the | ||||
server MUST respond with a 412 (Precondition Failed) status code. | ||||
If none of the entity-tags match, then the server MAY perform the | ||||
requested method as if the If-None-Match header field did not exist, | ||||
but MUST also ignore any If-Modified-Since header field(s) in the | ||||
request. That is, if no entity-tags match, then the server MUST NOT | ||||
return a 304 (Not Modified) response. | ||||
If the request would, without the If-None-Match header field, result | ||||
in anything other than a 2xx or 304 status code, then the If-None- | ||||
Match header field MUST be ignored. (See Section 5 for a discussion | ||||
of server behavior when both If-Modified-Since and If-None-Match | ||||
appear in the same request.) | ||||
The meaning of "If-None-Match: *" is that the request method MUST NOT | ||||
be performed if the representation selected by the origin server (or | ||||
by a cache, possibly using the Vary mechanism, see Section 3.5 of | ||||
[Part6]) exists, and SHOULD be performed if the representation does | ||||
not exist. This feature is intended to be useful in preventing races | ||||
between PUT operations. | ||||
Examples: | ||||
If-None-Match: "xyzzy" | ||||
If-None-Match: W/"xyzzy" | ||||
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" | ||||
If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz" | ||||
If-None-Match: * | ||||
The result of a request having both an If-None-Match header field and | ||||
either an If-Match or an If-Unmodified-Since header fields is | ||||
undefined by this specification. | ||||
6.5. If-Unmodified-Since | ||||
The "If-Unmodified-Since" header field is used to make a request | ||||
method conditional. If the representation that would have been | ||||
transferred in a 200 response to a GET request on the same resource | ||||
has not been modified since the time specified in this field, the | ||||
server SHOULD perform the requested operation as if the If- | ||||
Unmodified-Since header field were not present. | ||||
If the representation has been modified since the specified time, the | The "If-Unmodified-Since" header field MAY be used to make a request | |||
server MUST NOT perform the requested operation, and MUST return a | method conditional by modification date: if the selected | |||
412 (Precondition Failed). | representation has been modified since the time specified in this | |||
field, then the server MUST NOT perform the requested operation and | ||||
MUST instead respond with the 412 (Precondition Failed) status code. | ||||
If the selected representation has not been modified since the time | ||||
specified in this field, the server SHOULD perform the request method | ||||
as if the If-Unmodified-Since header field were not present. | ||||
If-Unmodified-Since = "If-Unmodified-Since" ":" OWS | If-Unmodified-Since = HTTP-date | |||
If-Unmodified-Since-v | ||||
If-Unmodified-Since-v = HTTP-date | ||||
An example of the field is: | An example of the field is: | |||
If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT | If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT | |||
If the request normally (i.e., without the If-Unmodified-Since header | If the request normally (i.e., without the If-Unmodified-Since header | |||
field) would result in anything other than a 2xx or 412 status code, | field) would result in anything other than a 2xx or 412 status code, | |||
the If-Unmodified-Since header field SHOULD be ignored. | the If-Unmodified-Since header field SHOULD be ignored. | |||
If the specified date is invalid, the header field is ignored. | If the specified date is invalid, the header field MUST be ignored. | |||
The result of a request having both an If-Unmodified-Since header | The result of a request having both an If-Unmodified-Since header | |||
field and either an If-None-Match or an If-Modified-Since header | field and either an If-None-Match or an If-Modified-Since header | |||
fields is undefined by this specification. | fields is undefined by this specification. | |||
6.6. Last-Modified | 3.5. If-Range | |||
The "Last-Modified" header field indicates the date and time at which | The If-Range header field provides a special conditional request | |||
the origin server believes the representation was last modified. | mechanism that is similar to If-Match and If-Unmodified-Since but | |||
specific to HTTP range requests. If-Range is defined in Section 5.3 | ||||
of [Part5]. | ||||
Last-Modified = "Last-Modified" ":" OWS Last-Modified-v | 4. Status Code Definitions | |||
Last-Modified-v = HTTP-date | ||||
An example of its use is | 4.1. 304 Not Modified | |||
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT | The 304 status code indicates that a conditional GET request has been | |||
received and would have resulted in a 200 (OK) response 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 transfer a representation | ||||
of the target resource because the client's request indicates that it | ||||
already has a valid representation, as indicated by the 304 response | ||||
header fields, and is therefore redirecting the client to make use of | ||||
that stored representation as if it were the payload of a 200 | ||||
response. The 304 response MUST NOT contain a message-body, and thus | ||||
is always terminated by the first empty line after the header fields. | ||||
A representation is typically the sum of many parts behind the | A 304 response MUST include a Date header field (Section 9.3 of | |||
resource interface. The last-modified time would usually be the most | [Part1]) unless its omission is required by Section 9.3.1 of [Part1]. | |||
recent time that any of those parts were changed. How that value is | If a 200 response to the same request would have included any of the | |||
determined for any given resource is an implementation detail beyond | header fields Cache-Control, Content-Location, ETag, Expires, Last- | |||
the scope of this specification. What matters to HTTP is how | Modified, or Vary, then those same header fields MUST be sent in a | |||
recipients of the Last-Modified header field can use its value to | 304 response. | |||
make conditional requests and test the validity of locally cached | ||||
responses. | ||||
An origin server MUST NOT send a Last-Modified date which is later | Since the goal of a 304 response is to minimize information transfer | |||
than the server's time of message origination. In such cases, where | when the recipient already has one or more cached representations, | |||
the resource's last modification would indicate some time in the | the response SHOULD NOT include representation metadata other than | |||
future, the server MUST replace that date with the message | the above listed fields unless said metadata exists for the purpose | |||
origination date. | of guiding cache updates (e.g., future HTTP extensions). | |||
An origin server SHOULD obtain the Last-Modified value of the | If the recipient of a 304 response does not have a cached | |||
representation as close as possible to the time that it generates the | representation corresponding to the entity-tag indicated by the 304 | |||
Date value of its response. This allows a recipient to make an | response, then the recipient MUST NOT use the 304 to update its own | |||
accurate assessment of the representation's modification time, | cache. If this conditional request originated with an outbound | |||
especially if the representation changes near the time that the | client, such as a user agent with its own cache sending a conditional | |||
response is generated. | GET to a shared proxy, then the 304 response MAY be forwarded to the | |||
outbound client. Otherwise, the recipient MUST disregard the 304 | ||||
response and repeat the request without any preconditions. | ||||
HTTP/1.1 servers SHOULD send Last-Modified whenever feasible. | If a cache uses a received 304 response to update a cache entry, the | |||
cache MUST update the entry to reflect any new field values given in | ||||
the response. | ||||
The Last-Modified header field value is often used as a cache | 4.2. 412 Precondition Failed | |||
validator. In simple terms, a cache entry is considered to be valid | ||||
if the representation has not been modified since the Last-Modified | ||||
value. | ||||
7. IANA Considerations | The 412 status code indicates that one or more preconditions given in | |||
the request header fields evaluated to false when tested on the | ||||
server. This response code allows the client to place preconditions | ||||
on the current resource state (its current representations and | ||||
metadata) and thus prevent the request method from being applied if | ||||
the target resource is in an unexpected state. | ||||
7.1. Status Code Registration | 5. IANA Considerations | |||
5.1. Status Code Registration | ||||
The HTTP Status Code Registry located at | The HTTP Status Code Registry located at | |||
<http://www.iana.org/assignments/http-status-codes> shall be updated | <http://www.iana.org/assignments/http-status-codes> shall be updated | |||
with the registrations below: | with the registrations below: | |||
+-------+---------------------+-------------+ | +-------+---------------------+-------------+ | |||
| Value | Description | Reference | | | Value | Description | Reference | | |||
+-------+---------------------+-------------+ | +-------+---------------------+-------------+ | |||
| 304 | Not Modified | Section 3.1 | | | 304 | Not Modified | Section 4.1 | | |||
| 412 | Precondition Failed | Section 3.2 | | | 412 | Precondition Failed | Section 4.2 | | |||
+-------+---------------------+-------------+ | +-------+---------------------+-------------+ | |||
7.2. Header Field Registration | 5.2. Header Field Registration | |||
The Message Header Field Registry located at <http://www.iana.org/ | The Message Header Field Registry located at <http://www.iana.org/ | |||
assignments/message-headers/message-header-index.html> shall be | assignments/message-headers/message-header-index.html> shall be | |||
updated with the permanent registrations below (see [RFC3864]): | updated with the permanent registrations below (see [RFC3864]): | |||
+---------------------+----------+----------+-------------+ | +---------------------+----------+----------+-------------+ | |||
| Header Field Name | Protocol | Status | Reference | | | Header Field Name | Protocol | Status | Reference | | |||
+---------------------+----------+----------+-------------+ | +---------------------+----------+----------+-------------+ | |||
| ETag | http | standard | Section 6.1 | | | ETag | http | standard | Section 2.2 | | |||
| If-Match | http | standard | Section 6.2 | | | If-Match | http | standard | Section 3.1 | | |||
| If-Modified-Since | http | standard | Section 6.3 | | | If-Modified-Since | http | standard | Section 3.3 | | |||
| If-None-Match | http | standard | Section 6.4 | | | If-None-Match | http | standard | Section 3.2 | | |||
| If-Unmodified-Since | http | standard | Section 6.5 | | | If-Unmodified-Since | http | standard | Section 3.4 | | |||
| Last-Modified | http | standard | Section 6.6 | | | Last-Modified | http | standard | Section 2.1 | | |||
+---------------------+----------+----------+-------------+ | +---------------------+----------+----------+-------------+ | |||
The change controller is: "IETF (iesg@ietf.org) - Internet | The change controller is: "IETF (iesg@ietf.org) - Internet | |||
Engineering Task Force". | Engineering Task Force". | |||
8. Security Considerations | 6. Security Considerations | |||
No additional security considerations have been identified beyond | No additional security considerations have been identified beyond | |||
those applicable to HTTP in general [Part1]. | those applicable to HTTP in general [Part1]. | |||
9. Acknowledgments | 7. Acknowledgments | |||
10. References | 8. References | |||
10.1. Normative References | 8.1. Normative References | |||
[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | |||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | |||
and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, | and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, | |||
and Message Parsing", draft-ietf-httpbis-p1-messaging-13 | and Message Parsing", draft-ietf-httpbis-p1-messaging-14 | |||
(work in progress), March 2011. | (work in progress), April 2011. | |||
[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | |||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | |||
and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload | and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload | |||
and Content Negotiation", draft-ietf-httpbis-p3-payload-13 | and Content Negotiation", draft-ietf-httpbis-p3-payload-14 | |||
(work in progress), March 2011. | (work in progress), April 2011. | |||
[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | |||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | |||
and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and | and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and | |||
Partial Responses", draft-ietf-httpbis-p5-range-13 (work | Partial Responses", draft-ietf-httpbis-p5-range-14 (work | |||
in progress), March 2011. | in progress), April 2011. | |||
[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., | |||
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., | |||
Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part | Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part | |||
6: Caching", draft-ietf-httpbis-p6-cache-13 (work in | 6: Caching", draft-ietf-httpbis-p6-cache-14 (work in | |||
progress), March 2011. | progress), April 2011. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax | |||
Specifications: ABNF", STD 68, RFC 5234, January 2008. | Specifications: ABNF", STD 68, RFC 5234, January 2008. | |||
10.2. Informative References | 8.2. Informative References | |||
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., | [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., | |||
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext | Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext | |||
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. | Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. | |||
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration | [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration | |||
Procedures for Message Header Fields", BCP 90, RFC 3864, | Procedures for Message Header Fields", BCP 90, RFC 3864, | |||
September 2004. | September 2004. | |||
[RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed | ||||
Authoring and Versioning (WebDAV)", RFC 4918, June 2007. | ||||
Appendix A. Changes from RFC 2616 | Appendix A. Changes from RFC 2616 | |||
Allow weak entity-tags in all requests except range requests | Allow weak entity-tags in all requests except range requests | |||
(Sections 4 and 6.4). | (Sections 2.2.2 and 3.2). | |||
Change ABNF productions for header fields to only define the field | ||||
value. (Section 3) | ||||
Appendix B. Collected ABNF | Appendix B. Collected ABNF | |||
ETag = "ETag:" OWS ETag-v | ETag = entity-tag | |||
ETag-v = entity-tag | ||||
HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> | HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> | |||
If-Match = "If-Match:" OWS If-Match-v | If-Match = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS | |||
If-Match-v = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS | ||||
entity-tag ] ) ) | entity-tag ] ) ) | |||
If-Modified-Since = "If-Modified-Since:" OWS If-Modified-Since-v | If-Modified-Since = HTTP-date | |||
If-Modified-Since-v = HTTP-date | If-None-Match = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS | |||
If-None-Match = "If-None-Match:" OWS If-None-Match-v | ||||
If-None-Match-v = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS | ||||
entity-tag ] ) ) | entity-tag ] ) ) | |||
If-Unmodified-Since = "If-Unmodified-Since:" OWS | If-Unmodified-Since = HTTP-date | |||
If-Unmodified-Since-v | ||||
If-Unmodified-Since-v = HTTP-date | ||||
Last-Modified = "Last-Modified:" OWS Last-Modified-v | Last-Modified = HTTP-date | |||
Last-Modified-v = HTTP-date | ||||
OWS = <OWS, defined in [Part1], Section 1.2.2> | OWS = <OWS, defined in [Part1], Section 1.2.2> | |||
entity-tag = [ weak ] opaque-tag | entity-tag = [ weak ] opaque-tag | |||
opaque-tag = quoted-string | opaque-tag = quoted-string | |||
quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> | quoted-string = <quoted-string, defined in [Part1], Section 1.2.2> | |||
weak = %x57.2F ; W/ | weak = %x57.2F ; W/ | |||
skipping to change at page 25, line 29 | skipping to change at page 25, line 16 | |||
None. | None. | |||
C.14. Since draft-ietf-httpbis-p4-conditional-12 | C.14. Since draft-ietf-httpbis-p4-conditional-12 | |||
Closed issues: | Closed issues: | |||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header | o <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header | |||
Classification" | Classification" | |||
C.15. Since draft-ietf-httpbis-p4-conditional-13 | ||||
Closed issues: | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/89>: "If-* and | ||||
entities" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/101>: "Definition of | ||||
validator weakness" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle | ||||
ABNFs for header fields" | ||||
o <http://tools.ietf.org/wg/httpbis/trac/ticket/269>: "ETags and | ||||
Quotes" | ||||
Index | Index | |||
3 | 3 | |||
304 Not Modified (status code) 8 | 304 Not Modified (status code) 18 | |||
4 | 4 | |||
412 Precondition Failed (status code) 8 | 412 Precondition Failed (status code) 19 | |||
E | E | |||
ETag header field 13 | ETag header field 8 | |||
G | G | |||
Grammar | Grammar | |||
entity-tag 6 | entity-tag 8 | |||
ETag 13 | ETag 8 | |||
ETag-v 13 | ||||
If-Match 14 | If-Match 14 | |||
If-Match-v 14 | If-Modified-Since 16 | |||
If-Modified-Since 15 | If-None-Match 15 | |||
If-Modified-Since-v 15 | ||||
If-None-Match 17 | ||||
If-None-Match-v 17 | ||||
If-Unmodified-Since 18 | If-Unmodified-Since 18 | |||
If-Unmodified-Since-v 18 | Last-Modified 6 | |||
Last-Modified 19 | opaque-tag 8 | |||
Last-Modified-v 19 | weak 8 | |||
opaque-tag 6 | ||||
weak 6 | ||||
H | H | |||
Header Fields | Header Fields | |||
ETag 13 | ETag 8 | |||
If-Match 14 | If-Match 14 | |||
If-Modified-Since 15 | If-Modified-Since 16 | |||
If-None-Match 17 | If-None-Match 15 | |||
If-Unmodified-Since 18 | If-Unmodified-Since 18 | |||
Last-Modified 19 | Last-Modified 6 | |||
I | I | |||
If-Match header field 14 | If-Match header field 14 | |||
If-Modified-Since header field 15 | If-Modified-Since header field 16 | |||
If-None-Match header field 17 | If-None-Match header field 15 | |||
If-Unmodified-Since header field 18 | If-Unmodified-Since header field 18 | |||
L | L | |||
Last-Modified header field 19 | Last-Modified header field 6 | |||
M | ||||
metadata 6 | ||||
S | S | |||
selected representation 5 | ||||
Status Codes | Status Codes | |||
304 Not Modified 8 | 304 Not Modified 18 | |||
412 Precondition Failed 8 | 412 Precondition Failed 19 | |||
V | ||||
validator 6 | ||||
Authors' Addresses | Authors' Addresses | |||
Roy T. Fielding (editor) | Roy T. Fielding (editor) | |||
Adobe Systems Incorporated | Adobe Systems Incorporated | |||
345 Park Ave | 345 Park Ave | |||
San Jose, CA 95110 | San Jose, CA 95110 | |||
USA | USA | |||
EMail: fielding@gbiv.com | EMail: fielding@gbiv.com | |||
End of changes. 132 change blocks. | ||||
520 lines changed or deleted | 531 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |