rfc7232.txt   draft-ietf-httpbis-conditional-00.txt 
Internet Engineering Task Force (IETF) R. Fielding, Ed. HTTP Working Group R. Fielding, Ed.
Request for Comments: 7232 Adobe Internet-Draft Adobe
Obsoletes: 2616 J. Reschke, Ed. Obsoletes: 7232 (if approved) M. Nottingham, Ed.
Category: Standards Track greenbytes Intended status: Standards Track Fastly
ISSN: 2070-1721 June 2014 Expires: October 5, 2018 J. Reschke, Ed.
greenbytes
April 3, 2018
Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests Hypertext Transfer Protocol (HTTP): Conditional Requests
draft-ietf-httpbis-conditional-00
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is a stateless application- The Hypertext Transfer Protocol (HTTP) is a stateless application-
level protocol for distributed, collaborative, hypertext information level protocol for distributed, collaborative, hypertext information
systems. This document defines HTTP/1.1 conditional requests, systems. This document defines HTTP/1.1 conditional requests,
including metadata header fields for indicating state changes, including metadata header fields for indicating state changes,
request header fields for making preconditions on such state, and request header fields for making preconditions on such state, and
rules for constructing the responses to a conditional request when rules for constructing the responses to a conditional request when
one or more preconditions evaluate to false. one or more preconditions evaluate to false.
This document obsoletes RFC 7232.
Editorial Note
This note is to be removed before publishing as an RFC.
Discussion of this draft takes place on the HTTP working group
mailing list (ietf-http-wg@w3.org), which is archived at
<http://lists.w3.org/Archives/Public/ietf-http-wg/>.
Working Group information can be found at <http://httpwg.github.io/>;
source code and issues list for this draft can be found at
<https://github.com/httpwg/http-core>.
The changes in this draft are summarized in Appendix D.1.
Status of This Memo Status of This Memo
This is an Internet Standards Track document. This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
This document is a product of the Internet Engineering Task Force Internet-Drafts are working documents of the Internet Engineering
(IETF). It represents the consensus of the IETF community. It has Task Force (IETF). Note that other groups may also distribute
received public review and has been approved for publication by the working documents as Internet-Drafts. The list of current Internet-
Internet Engineering Steering Group (IESG). Further information on Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata, Internet-Drafts are draft documents valid for a maximum of six months
and how to provide feedback on it may be obtained at and may be updated, replaced, or obsoleted by other documents at any
http://www.rfc-editor.org/info/rfc7232. time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 5, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2018 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 (https://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
skipping to change at page 3, line 7 skipping to change at page 2, line 41
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
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 ....................................................4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conformance and Error Handling .............................4 1.1. Conformance and Error Handling . . . . . . . . . . . . . 4
1.2. Syntax Notation ............................................4 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4
2. Validators ......................................................5 2. Validators . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Weak versus Strong .........................................5 2.1. Weak versus Strong . . . . . . . . . . . . . . . . . . . 5
2.2. Last-Modified ..............................................7 2.2. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1. Generation ..........................................7 2.2.1. Generation . . . . . . . . . . . . . . . . . . . . . 7
2.2.2. Comparison ..........................................8 2.2.2. Comparison . . . . . . . . . . . . . . . . . . . . . 7
2.3. ETag .......................................................9 2.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.1. Generation .........................................10 2.3.1. Generation . . . . . . . . . . . . . . . . . . . . . 9
2.3.2. Comparison .........................................10 2.3.2. Comparison . . . . . . . . . . . . . . . . . . . . . 10
2.3.3. Example: Entity-Tags Varying on 2.3.3. Example: Entity-Tags Varying on Content-Negotiated
Content-Negotiated Resources .......................11 Resources . . . . . . . . . . . . . . . . . . . . . . 10
2.4. When to Use Entity-Tags and Last-Modified Dates ...........12 2.4. When to Use Entity-Tags and Last-Modified Dates . . . . . 11
3. Precondition Header Fields .....................................13 3. Precondition Header Fields . . . . . . . . . . . . . . . . . 12
3.1. If-Match ..................................................13 3.1. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2. If-None-Match .............................................14 3.2. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 13
3.3. If-Modified-Since .........................................16 3.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 15
3.4. If-Unmodified-Since .......................................17 3.4. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 16
3.5. If-Range ..................................................18 3.5. If-Range . . . . . . . . . . . . . . . . . . . . . . . . 17
4. Status Code Definitions ........................................18 4. Status Code Definitions . . . . . . . . . . . . . . . . . . . 17
4.1. 304 Not Modified ..........................................18 4.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . 17
4.2. 412 Precondition Failed ...................................19 4.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 18
5. Evaluation .....................................................19 5. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . 18
6. Precedence .....................................................20 6. Precedence . . . . . . . . . . . . . . . . . . . . . . . . . 19
7. IANA Considerations ............................................22 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7.1. Status Code Registration ..................................22 7.1. Status Code Registration . . . . . . . . . . . . . . . . 20
7.2. Header Field Registration .................................22 7.2. Header Field Registration . . . . . . . . . . . . . . . . 21
8. Security Considerations ........................................22 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9. Acknowledgments ................................................23 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
10. References ....................................................24 9.1. Normative References . . . . . . . . . . . . . . . . . . 22
10.1. Normative References .....................................24 9.2. Informative References . . . . . . . . . . . . . . . . . 23
10.2. Informative References ...................................24 Appendix A. Changes from RFC 7232 . . . . . . . . . . . . . . . 24
Appendix A. Changes from RFC 2616 .................................25 Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . 24
Appendix B. Imported ABNF .........................................25 Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 24
Appendix C. Collected ABNF ........................................26 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 25
Index .............................................................27 D.1. Since RFC 7232 . . . . . . . . . . . . . . . . . . . . . 25
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
Conditional requests are HTTP requests [RFC7231] that include one or Conditional requests are HTTP requests [SEMNTCS] that include one or
more header fields indicating a precondition to be tested before more header fields indicating a precondition to be tested before
applying the method semantics to the target resource. This document applying the method semantics to the target resource. This document
defines the HTTP/1.1 conditional request mechanisms in terms of the defines the HTTP/1.1 conditional request mechanisms in terms of the
architecture, syntax notation, and conformance criteria defined in architecture, syntax notation, and conformance criteria defined in
[RFC7230]. [MESSGNG].
Conditional GET requests are the most efficient mechanism for HTTP Conditional GET requests are the most efficient mechanism for HTTP
cache updates [RFC7234]. Conditionals can also be applied to cache updates [CACHING]. Conditionals can also be applied to state-
state-changing methods, such as PUT and DELETE, to prevent the "lost changing methods, such as PUT and DELETE, to prevent the "lost
update" problem: one client accidentally overwriting the work of update" problem: one client accidentally overwriting the work of
another client that has been acting in parallel. another client that has been acting in parallel.
Conditional request preconditions are based on the state of the Conditional request preconditions are based on the state of the
target resource as a whole (its current value set) or the state as target resource as a whole (its current value set) or the state as
observed in a previously obtained representation (one value in that observed in a previously obtained representation (one value in that
set). A resource might have multiple current representations, each set). A resource might have multiple current representations, each
with its own observable state. The conditional request mechanisms with its own observable state. The conditional request mechanisms
assume that the mapping of requests to a "selected representation" assume that the mapping of requests to a "selected representation"
(Section 3 of [RFC7231]) will be consistent over time if the server (Section 3 of [SEMNTCS]) will be consistent over time if the server
intends to take advantage of conditionals. Regardless, if the intends to take advantage of conditionals. Regardless, if the
mapping is inconsistent and the server is unable to select the mapping is inconsistent and the server is unable to select the
appropriate representation, then no harm will result when the appropriate representation, then no harm will result when the
precondition evaluates to false. precondition evaluates to false.
The conditional request preconditions defined by this specification The conditional request preconditions defined by this specification
(Section 3) are evaluated when applicable to the recipient (Section 3) are evaluated when applicable to the recipient
(Section 5) according to their order of precedence (Section 6). (Section 5) according to their order of precedence (Section 6).
This specification obsoletes RFC 7232, with the changes being
summarized in Appendix A.
1.1. Conformance and Error Handling 1.1. Conformance and Error Handling
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].
Conformance criteria and considerations regarding error handling are Conformance criteria and considerations regarding error handling are
defined in Section 2.5 of [RFC7230]. defined in Section 2.5 of [MESSGNG].
1.2. Syntax Notation 1.2. Syntax Notation
This specification uses the Augmented Backus-Naur Form (ABNF) This specification uses the Augmented Backus-Naur Form (ABNF)
notation of [RFC5234] with a list extension, defined in Section 7 of notation of [RFC5234] with a list extension, defined in Section 7 of
[RFC7230], that allows for compact definition of comma-separated [MESSGNG], that allows for compact definition of comma-separated
lists using a '#' operator (similar to how the '*' operator indicates lists using a '#' operator (similar to how the '*' operator indicates
repetition). Appendix B describes rules imported from other repetition). Appendix B describes rules imported from other
documents. Appendix C shows the collected grammar with all list documents. Appendix C shows the collected grammar with all list
operators expanded to standard ABNF notation. operators expanded to standard ABNF notation.
2. Validators 2. Validators
This specification defines two forms of metadata that are commonly This specification defines two forms of metadata that are commonly
used to observe resource state and test for preconditions: used to observe resource state and test for preconditions:
modification dates (Section 2.2) and opaque entity tags modification dates (Section 2.2) and opaque entity tags
skipping to change at page 7, line 22 skipping to change at page 7, line 4
2.2. Last-Modified 2.2. Last-Modified
The "Last-Modified" header field in a response provides a timestamp The "Last-Modified" header field in a response provides a timestamp
indicating the date and time at which the origin server believes the indicating the date and time at which the origin server believes the
selected representation was last modified, as determined at the selected representation was last modified, as determined at the
conclusion of handling the request. conclusion of handling the request.
Last-Modified = HTTP-date Last-Modified = HTTP-date
An example of its use is An example of its use is
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
2.2.1. Generation 2.2.1. Generation
An origin server SHOULD send Last-Modified for any selected An origin server SHOULD send Last-Modified for any selected
representation for which a last modification date can be reasonably representation for which a last modification date can be reasonably
and consistently determined, since its use in conditional requests and consistently determined, since its use in conditional requests
and evaluating cache freshness ([RFC7234]) results in a substantial and evaluating cache freshness ([CACHING]) results in a substantial
reduction of HTTP traffic on the Internet and can be a significant reduction of HTTP traffic on the Internet and can be a significant
factor in improving service scalability and reliability. factor in improving service scalability and reliability.
A representation is typically the sum of many parts behind the A representation is typically the sum of many parts behind the
resource interface. The last-modified time would usually be the most resource interface. The last-modified time would usually be the most
recent time that any of those parts were changed. How that value is recent time that any of those parts were changed. How that value is
determined for any given resource is an implementation detail beyond determined for any given resource is an implementation detail beyond
the scope of this specification. What matters to HTTP is how the scope of this specification. What matters to HTTP is how
recipients of the Last-Modified header field can use its value to recipients of the Last-Modified header field can use its value to
make conditional requests and test the validity of locally cached make conditional requests and test the validity of locally cached
skipping to change at page 8, line 28 skipping to change at page 8, line 11
o The validator is being compared by an origin server to the actual o The validator is being compared by an origin server to the actual
current validator for the representation and, current validator for the representation and,
o That origin server reliably knows that the associated o That origin server reliably knows that the associated
representation did not change twice during the second covered by representation did not change twice during the second covered by
the presented validator. the presented validator.
or or
o The validator is about to be used by a client in an o The validator is about to be used by a client in an If-Modified-
If-Modified-Since, If-Unmodified-Since, or If-Range header field, Since, If-Unmodified-Since, or If-Range header field, because the
because the client has a cache entry for the associated client has a cache entry for the associated representation, and
representation, and
o That cache entry includes a Date value, which gives the time when o That cache entry includes a Date value, which gives the time when
the origin server sent the original response, and the origin server sent the original response, and
o The presented Last-Modified time is at least 60 seconds before the o The presented Last-Modified time is at least 60 seconds before the
Date value. Date value.
or or
o The validator is being compared by an intermediate cache to the o The validator is being compared by an intermediate cache to the
skipping to change at page 10, line 32 skipping to change at page 10, line 8
applied to all changes might use an internal revision number, perhaps applied to all changes might use an internal revision number, perhaps
combined with a variance identifier for content negotiation, to combined with a variance identifier for content negotiation, to
accurately differentiate between representations. Other accurately differentiate between representations. Other
implementations might use a collision-resistant hash of implementations might use a collision-resistant hash of
representation content, a combination of various file attributes, or representation content, a combination of various file attributes, or
a modification timestamp that has sub-second resolution. a modification timestamp that has sub-second resolution.
An origin server SHOULD send an ETag for any selected representation An origin server SHOULD send an ETag for any selected representation
for which detection of changes can be reasonably and consistently for which detection of changes can be reasonably and consistently
determined, since the entity-tag's use in conditional requests and determined, since the entity-tag's use in conditional requests and
evaluating cache freshness ([RFC7234]) can result in a substantial evaluating cache freshness ([CACHING]) can result in a substantial
reduction of HTTP network traffic and can be a significant factor in reduction of HTTP network traffic and can be a significant factor in
improving service scalability and reliability. improving service scalability and reliability.
2.3.2. Comparison 2.3.2. Comparison
There are two entity-tag comparison functions, depending on whether There are two entity-tag comparison functions, depending on whether
or not the comparison context allows the use of weak validators: or not the comparison context allows the use of weak validators:
o Strong comparison: two entity-tags are equivalent if both are not o Strong comparison: two entity-tags are equivalent if both are not
weak and their opaque-tags match character-by-character. weak and their opaque-tags match character-by-character.
o Weak comparison: two entity-tags are equivalent if their o Weak comparison: two entity-tags are equivalent if their opaque-
opaque-tags match character-by-character, regardless of either or tags match character-by-character, regardless of either or both
both being tagged as "weak". being tagged as "weak".
The example below shows the results for a set of entity-tag pairs and The example below shows the results for a set of entity-tag pairs and
both the weak and strong comparison function results: 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 |
+--------+--------+-------------------+-----------------+ +--------+--------+-------------------+-----------------+
2.3.3. Example: Entity-Tags Varying on Content-Negotiated Resources 2.3.3. Example: Entity-Tags Varying on Content-Negotiated Resources
Consider a resource that is subject to content negotiation (Section Consider a resource that is subject to content negotiation
3.4 of [RFC7231]), and where the representations sent in response to (Section 3.4 of [SEMNTCS]), and where the representations sent in
a GET request vary based on the Accept-Encoding request header field response to a GET request vary based on the Accept-Encoding request
(Section 5.3.4 of [RFC7231]): header field (Section 5.3.4 of [SEMNTCS]):
>> Request: >> Request:
GET /index HTTP/1.1 GET /index HTTP/1.1
Host: www.example.com Host: www.example.com
Accept-Encoding: gzip Accept-Encoding: gzip
In this case, the response might or might not use the gzip content In this case, the response might or might not use the gzip content
coding. If it does not, the response might look like: coding. If it does not, the response might look like:
skipping to change at page 12, line 24 skipping to change at page 11, line 39
Vary: Accept-Encoding Vary: Accept-Encoding
Content-Type: text/plain Content-Type: text/plain
Content-Encoding: gzip Content-Encoding: gzip
...binary data... ...binary data...
Note: Content codings are a property of the representation data, Note: Content codings are a property of the representation data,
so a strong entity-tag for a content-encoded representation has to so a strong entity-tag for a content-encoded representation has to
be distinct from the entity tag of an unencoded representation to be distinct from the entity tag of an unencoded representation to
prevent potential conflicts during cache updates and range prevent potential conflicts during cache updates and range
requests. In contrast, transfer codings (Section 4 of [RFC7230]) requests. In contrast, transfer codings (Section 4 of [MESSGNG])
apply only during message transfer and do not result in distinct apply only during message transfer and do not result in distinct
entity-tags. entity-tags.
2.4. When to Use Entity-Tags and Last-Modified Dates 2.4. When to Use Entity-Tags and Last-Modified Dates
In 200 (OK) responses to GET or HEAD, an origin server: In 200 (OK) responses to GET or HEAD, an origin server:
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.
skipping to change at page 13, line 6 skipping to change at page 12, line 18
send both a strong entity-tag and a Last-Modified value in successful send both a strong entity-tag and a Last-Modified value in successful
responses to a retrieval request. responses to a retrieval request.
A client: A client:
o MUST send that entity-tag in any cache validation request (using o MUST send that entity-tag in any cache validation 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 send the Last-Modified value in non-subrange cache o SHOULD send the Last-Modified value in non-subrange cache
validation requests (using If-Modified-Since) if only a validation requests (using If-Modified-Since) if only a Last-
Last-Modified value has been provided by the origin server. Modified value has been provided by the origin server.
o MAY send the Last-Modified value in subrange cache validation o MAY send the Last-Modified value in subrange cache validation
requests (using If-Unmodified-Since) if only a Last-Modified value requests (using If-Unmodified-Since) if only a Last-Modified value
has been provided by an HTTP/1.0 origin server. The user agent has been provided by an HTTP/1.0 origin server. The user agent
SHOULD provide a way to disable this, in case of difficulty. SHOULD provide a way to disable this, in case of difficulty.
o SHOULD send both validators in cache validation requests if both o SHOULD send both validators in cache validation requests if both
an entity-tag and a Last-Modified value have been provided by the an entity-tag and a Last-Modified value have been provided by the
origin server. This allows both HTTP/1.0 and HTTP/1.1 caches to origin server. This allows both HTTP/1.0 and HTTP/1.1 caches to
respond appropriately. respond appropriately.
skipping to change at page 15, line 26 skipping to change at page 14, line 30
stored responses that have entity-tags, the client SHOULD generate an stored responses that have entity-tags, the client SHOULD generate an
If-None-Match header field containing a list of those entity-tags If-None-Match header field containing a list of those entity-tags
when making a GET request; this allows recipient servers to send a when making a GET request; this allows recipient servers to send a
304 (Not Modified) response to indicate when one of those stored 304 (Not Modified) response to indicate when one of those stored
responses matches the selected representation. responses matches the selected representation.
If-None-Match can also be used with a value of "*" to prevent an If-None-Match can also be used with a value of "*" to prevent an
unsafe request method (e.g., PUT) from inadvertently modifying an unsafe request method (e.g., PUT) from inadvertently modifying an
existing representation of the target resource when the client existing representation of the target resource when the client
believes that the resource does not have a current representation believes that the resource does not have a current representation
(Section 4.2.1 of [RFC7231]). This is a variation on the "lost (Section 4.2.1 of [SEMNTCS]). This is a variation on the "lost
update" problem that might arise if more than one client attempts to update" problem that might arise if more than one client attempts to
create an initial representation for the target resource. create an initial representation for the target resource.
An origin server that receives an If-None-Match header field MUST An origin server that receives an If-None-Match header field MUST
evaluate the condition prior to performing the method (Section 5). evaluate the condition prior to performing the method (Section 5).
If the field-value is "*", the condition is false if the origin If the field-value is "*", the condition is false if the origin
server has a current representation for the target resource. If the server has a current representation for the target resource. If the
field-value is a list of entity-tags, the condition is false if one field-value is a list of entity-tags, the condition is false if one
of the listed tags match the entity-tag of the selected of the listed tags match the entity-tag of the selected
representation. representation.
An origin server MUST NOT perform the requested method if the An origin server MUST NOT perform the requested method if the
condition evaluates to false; instead, the origin server MUST respond condition evaluates to false; instead, the origin server MUST respond
with either a) the 304 (Not Modified) status code if the request with either a) the 304 (Not Modified) status code if the request
method is GET or HEAD or b) the 412 (Precondition Failed) status code method is GET or HEAD or b) the 412 (Precondition Failed) status code
for all other request methods. for all other request methods.
Requirements on cache handling of a received If-None-Match header Requirements on cache handling of a received If-None-Match header
field are defined in Section 4.3.2 of [RFC7234]. field are defined in Section 4.3.2 of [CACHING].
3.3. If-Modified-Since 3.3. If-Modified-Since
The "If-Modified-Since" header field makes a GET or HEAD request The "If-Modified-Since" header field makes a GET or HEAD request
method conditional on the selected representation's modification date method conditional on the selected representation's modification date
being more recent than the date provided in the field-value. being more recent than the date provided in the field-value.
Transfer of the selected representation's data is avoided if that Transfer of the selected representation's data is avoided if that
data has not changed. data has not changed.
If-Modified-Since = HTTP-date 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 recipient MUST ignore If-Modified-Since if the request contains an A recipient MUST ignore If-Modified-Since if the request contains an
If-None-Match header field; the condition in If-None-Match is If-None-Match header field; the condition in If-None-Match is
considered to be a more accurate replacement for the condition in considered to be a more accurate replacement for the condition in If-
If-Modified-Since, and the two are only combined for the sake of Modified-Since, and the two are only combined for the sake of
interoperating with older intermediaries that might not implement interoperating with older intermediaries that might not implement If-
If-None-Match. None-Match.
A recipient MUST ignore the If-Modified-Since header field if the A recipient MUST ignore the If-Modified-Since header field if the
received field-value is not a valid HTTP-date, or if the request received field-value is not a valid HTTP-date, or if the request
method is neither GET nor HEAD. method is neither GET nor HEAD.
A recipient MUST interpret an If-Modified-Since field-value's A recipient MUST interpret an If-Modified-Since field-value's
timestamp in terms of the origin server's clock. timestamp in terms of the origin server's clock.
If-Modified-Since is typically used for two distinct purposes: 1) to If-Modified-Since is typically used for two distinct purposes: 1) to
allow efficient updates of a cached representation that does not have allow efficient updates of a cached representation that does not have
an entity-tag and 2) to limit the scope of a web traversal to an entity-tag and 2) to limit the scope of a web traversal to
resources that have recently changed. resources that have recently changed.
When used for cache updates, a cache will typically use the value of When used for cache updates, a cache will typically use the value of
the cached message's Last-Modified field to generate the field value the cached message's Last-Modified field to generate the field value
of If-Modified-Since. This behavior is most interoperable for cases of If-Modified-Since. This behavior is most interoperable for cases
where clocks are poorly synchronized or when the server has chosen to where clocks are poorly synchronized or when the server has chosen to
only honor exact timestamp matches (due to a problem with only honor exact timestamp matches (due to a problem with Last-
Last-Modified dates that appear to go "back in time" when the origin Modified dates that appear to go "back in time" when the origin
server's clock is corrected or a representation is restored from an server's clock is corrected or a representation is restored from an
archived backup). However, caches occasionally generate the field archived backup). However, caches occasionally generate the field
value based on other data, such as the Date header field of the value based on other data, such as the Date header field of the
cached message or the local clock time that the message was received, cached message or the local clock time that the message was received,
particularly when the cached message does not contain a Last-Modified particularly when the cached message does not contain a Last-Modified
field. field.
When used for limiting the scope of retrieval to a recent time When used for limiting the scope of retrieval to a recent time
window, a user agent will generate an If-Modified-Since field value window, a user agent will generate an If-Modified-Since field value
based on either its own local clock or a Date header field received based on either its own local clock or a Date header field received
from the server in a prior response. Origin servers that choose an from the server in a prior response. Origin servers that choose an
exact timestamp match based on the selected representation's exact timestamp match based on the selected representation's Last-
Last-Modified field will not be able to help the user agent limit its Modified field will not be able to help the user agent limit its data
data transfers to only those changed during the specified window. transfers to only those changed during the specified window.
An origin server that receives an If-Modified-Since header field An origin server that receives an If-Modified-Since header field
SHOULD evaluate the condition prior to performing the method SHOULD evaluate the condition prior to performing the method
(Section 5). The origin server SHOULD NOT perform the requested (Section 5). The origin server SHOULD NOT perform the requested
method if the selected representation's last modification date is method if the selected representation's last modification date is
earlier than or equal to the date provided in the field-value; earlier than or equal to the date provided in the field-value;
instead, the origin server SHOULD generate a 304 (Not Modified) instead, the origin server SHOULD generate a 304 (Not Modified)
response, including only those metadata that are useful for response, including only those metadata that are useful for
identifying or updating a previously cached response. identifying or updating a previously cached response.
Requirements on cache handling of a received If-Modified-Since header Requirements on cache handling of a received If-Modified-Since header
field are defined in Section 4.3.2 of [RFC7234]. field are defined in Section 4.3.2 of [CACHING].
3.4. If-Unmodified-Since 3.4. If-Unmodified-Since
The "If-Unmodified-Since" header field makes the request method The "If-Unmodified-Since" header field makes the request method
conditional on the selected representation's last modification date conditional on the selected representation's last modification date
being earlier than or equal to the date provided in the field-value. being earlier than or equal to the date provided in the field-value.
This field accomplishes the same purpose as If-Match for cases where This field accomplishes the same purpose as If-Match for cases where
the user agent does not have an entity-tag for the representation. the user agent does not have an entity-tag for the representation.
If-Unmodified-Since = HTTP-date If-Unmodified-Since = 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
A recipient MUST ignore If-Unmodified-Since if the request contains A recipient MUST ignore If-Unmodified-Since if the request contains
an If-Match header field; the condition in If-Match is considered to an If-Match header field; the condition in If-Match is considered to
be a more accurate replacement for the condition in be a more accurate replacement for the condition in If-Unmodified-
If-Unmodified-Since, and the two are only combined for the sake of Since, and the two are only combined for the sake of interoperating
interoperating with older intermediaries that might not implement with older intermediaries that might not implement If-Match.
If-Match.
A recipient MUST ignore the If-Unmodified-Since header field if the A recipient MUST ignore the If-Unmodified-Since header field if the
received field-value is not a valid HTTP-date. received field-value is not a valid HTTP-date.
A recipient MUST interpret an If-Unmodified-Since field-value's A recipient MUST interpret an If-Unmodified-Since field-value's
timestamp in terms of the origin server's clock. timestamp in terms of the origin server's clock.
If-Unmodified-Since is most often used with state-changing methods If-Unmodified-Since is most often used with state-changing methods
(e.g., POST, PUT, DELETE) to prevent accidental overwrites when (e.g., POST, PUT, DELETE) to prevent accidental overwrites when
multiple user agents might be acting in parallel on a resource that multiple user agents might be acting in parallel on a resource that
skipping to change at page 18, line 40 skipping to change at page 17, line 35
The If-Unmodified-Since header field can be ignored by caches and The If-Unmodified-Since header field can be ignored by caches and
intermediaries because it is not applicable to a stored response. intermediaries because it is not applicable to a stored response.
3.5. If-Range 3.5. If-Range
The "If-Range" header field provides a special conditional request The "If-Range" header field provides a special conditional request
mechanism that is similar to the If-Match and If-Unmodified-Since mechanism that is similar to the If-Match and If-Unmodified-Since
header fields but that instructs the recipient to ignore the Range header fields but that instructs the recipient to ignore the Range
header field if the validator doesn't match, resulting in transfer of header field if the validator doesn't match, resulting in transfer of
the new selected representation instead of a 412 (Precondition the new selected representation instead of a 412 (Precondition
Failed) response. If-Range is defined in Section 3.2 of [RFC7233]. Failed) response. If-Range is defined in Section 3.2 of [RANGERQ].
4. Status Code Definitions 4. Status Code Definitions
4.1. 304 Not Modified 4.1. 304 Not Modified
The 304 (Not Modified) status code indicates that a conditional GET The 304 (Not Modified) status code indicates that a conditional GET
or HEAD request has been received and would have resulted in a 200 or HEAD request has been received and would have resulted in a 200
(OK) response if it were not for the fact that the condition (OK) response if it were not for the fact that the condition
evaluated to false. In other words, there is no need for the server evaluated to false. In other words, there is no need for the server
to transfer a representation of the target resource because the to transfer a representation of the target resource because the
skipping to change at page 19, line 21 skipping to change at page 18, line 18
ETag, Expires, and Vary. ETag, Expires, and Vary.
Since the goal of a 304 response is to minimize information transfer Since the goal of a 304 response is to minimize information transfer
when the recipient already has one or more cached representations, a when the recipient already has one or more cached representations, a
sender SHOULD NOT generate representation metadata other than the sender SHOULD NOT generate representation metadata other than the
above listed fields unless said metadata exists for the purpose of above listed fields unless said metadata exists for the purpose of
guiding cache updates (e.g., Last-Modified might be useful if the guiding cache updates (e.g., Last-Modified might be useful if the
response does not have an ETag field). response does not have an ETag field).
Requirements on a cache that receives a 304 response are defined in Requirements on a cache that receives a 304 response are defined in
Section 4.3.4 of [RFC7234]. If the conditional request originated Section 4.3.4 of [CACHING]. If the conditional request originated
with an outbound client, such as a user agent with its own cache with an outbound client, such as a user agent with its own cache
sending a conditional GET to a shared proxy, then the proxy SHOULD sending a conditional GET to a shared proxy, then the proxy SHOULD
forward the 304 response to that client. forward the 304 response to that client.
A 304 response cannot contain a message-body; it is always terminated A 304 response cannot contain a message-body; it is always terminated
by the first empty line after the header fields. by the first empty line after the header fields.
4.2. 412 Precondition Failed 4.2. 412 Precondition Failed
The 412 (Precondition Failed) status code indicates that one or more The 412 (Precondition Failed) status code indicates that one or more
skipping to change at page 21, line 37 skipping to change at page 20, line 30
* if true, continue to step 5 * if true, continue to step 5
* if false, respond 304 (Not Modified) * if false, respond 304 (Not Modified)
5. When the method is GET and both Range and If-Range are present, 5. When the method is GET and both Range and If-Range are present,
evaluate the If-Range precondition: evaluate the If-Range precondition:
* if the validator matches and the Range specification is * if the validator matches and the Range specification is
applicable to the selected representation, respond 206 applicable to the selected representation, respond 206
(Partial Content) [RFC7233] (Partial Content) [RANGERQ]
6. Otherwise, 6. Otherwise,
* all conditions are met, so perform the requested action and * all conditions are met, so perform the requested action and
respond according to its success or failure. respond according to its success or failure.
Any extension to HTTP/1.1 that defines additional conditional request Any extension to HTTP/1.1 that defines additional conditional request
header fields ought to define its own expectations regarding the header fields ought to define its own expectations regarding the
order for evaluating such fields in relation to those defined in this order for evaluating such fields in relation to those defined in this
document and other conditionals that might be found in practice. document and other conditionals that might be found in practice.
7. IANA Considerations 7. IANA Considerations
7.1. Status Code Registration 7.1. Status Code Registration
The "Hypertext Transfer Protocol (HTTP) Status Code Registry" located The "Hypertext Transfer Protocol (HTTP) Status Code Registry" located
at <http://www.iana.org/assignments/http-status-codes> has been at <http://www.iana.org/assignments/http-status-codes> has been
updated with the registrations below: updated with the registrations below:
+-------+---------------------+-------------+ +-------+---------------------+--------------+
| Value | Description | Reference | | Value | Description | Reference |
+-------+---------------------+-------------+ +-------+---------------------+--------------+
| 304 | Not Modified | Section 4.1 | | 304 | Not Modified | Section 4.1 |
| 412 | Precondition Failed | Section 4.2 | | 412 | Precondition Failed | Section 4.2 |
+-------+---------------------+-------------+ +-------+---------------------+--------------+
7.2. Header Field Registration 7.2. Header Field Registration
HTTP header fields are registered within the "Message Headers" HTTP header fields are registered within the "Message Headers"
registry maintained at registry maintained at <http://www.iana.org/assignments/message-
<http://www.iana.org/assignments/message-headers/>. headers/>.
This document defines the following HTTP header fields, so their This document defines the following HTTP header fields, so their
associated registry entries have been updated according to the associated registry entries have been updated according to the
permanent registrations below (see [BCP90]): permanent registrations below (see [BCP90]):
+---------------------+----------+----------+-------------+ +---------------------+----------+----------+--------------+
| Header Field Name | Protocol | Status | Reference | | Header Field Name | Protocol | Status | Reference |
+---------------------+----------+----------+-------------+ +---------------------+----------+----------+--------------+
| ETag | http | standard | Section 2.3 | | ETag | http | standard | Section 2.3 |
| If-Match | http | standard | Section 3.1 | | If-Match | http | standard | Section 3.1 |
| If-Modified-Since | http | standard | Section 3.3 | | If-Modified-Since | http | standard | Section 3.3 |
| If-None-Match | http | standard | Section 3.2 | | If-None-Match | http | standard | Section 3.2 |
| If-Unmodified-Since | http | standard | Section 3.4 | | If-Unmodified-Since | http | standard | Section 3.4 |
| Last-Modified | http | standard | Section 2.2 | | Last-Modified | http | standard | Section 2.2 |
+---------------------+----------+----------+-------------+ +---------------------+----------+----------+--------------+
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 8. Security Considerations
This section is meant to inform developers, information providers, This section is meant to inform developers, information providers,
and users of known security concerns specific to the HTTP conditional and users of known security concerns specific to the HTTP conditional
request mechanisms. More general security considerations are request mechanisms. More general security considerations are
addressed in HTTP "Message Syntax and Routing" [RFC7230] and addressed in HTTP "Message Syntax and Routing" [MESSGNG] and
"Semantics and Content" [RFC7231]. "Semantics and Content" [SEMNTCS].
The validators defined by this specification are not intended to The validators defined by this specification are not intended to
ensure the validity of a representation, guard against malicious ensure the validity of a representation, guard against malicious
changes, or detect man-in-the-middle attacks. At best, they enable changes, or detect man-in-the-middle attacks. At best, they enable
more efficient cache updates and optimistic concurrent writes when more efficient cache updates and optimistic concurrent writes when
all participants are behaving nicely. At worst, the conditions will all participants are behaving nicely. At worst, the conditions will
fail and the client will receive a response that is no more harmful fail and the client will receive a response that is no more harmful
than an HTTP exchange without conditional requests. than an HTTP exchange without conditional requests.
An entity-tag can be abused in ways that create privacy risks. For An entity-tag can be abused in ways that create privacy risks. For
skipping to change at page 23, line 25 skipping to change at page 22, line 17
entity-tag that is unique to the user or user agent, send it in a entity-tag that is unique to the user or user agent, send it in a
cacheable response with a long freshness time, and then read that cacheable response with a long freshness time, and then read that
entity-tag in later conditional requests as a means of re-identifying entity-tag in later conditional requests as a means of re-identifying
that user or user agent. Such an identifying tag would become a that user or user agent. Such an identifying tag would become a
persistent identifier for as long as the user agent retained the persistent identifier for as long as the user agent retained the
original cache entry. User agents that cache representations ought original cache entry. User agents that cache representations ought
to ensure that the cache is cleared or replaced whenever the user to ensure that the cache is cleared or replaced whenever the user
performs privacy-maintaining actions, such as clearing stored cookies performs privacy-maintaining actions, such as clearing stored cookies
or changing to a private browsing mode. or changing to a private browsing mode.
9. Acknowledgments 9. References
See Section 10 of [RFC7230]. 9.1. Normative References
10. References [CACHING] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP): Caching", draft-
ietf-httpbis-cache-00 (work in progress), April 2018.
10.1. Normative References [MESSGNG] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message
Syntax and Routing", draft-ietf-httpbis-messaging-00 (work
in progress), April 2018.
[RANGERQ] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP): Range Requests",
draft-ietf-httpbis-range-00 (work in progress), April
2018.
[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,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[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,
DOI 10.17487/RFC5234, January 2008,
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer <https://www.rfc-editor.org/info/rfc5234>.
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, June 2014.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
June 2014.
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
"Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
RFC 7233, June 2014.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [SEMNTCS] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", Ed., "Hypertext Transfer Protocol (HTTP): Semantics and
RFC 7234, June 2014. Content", draft-ietf-httpbis-semantics-00 (work in
progress), April 2018.
10.2. Informative References 9.2. Informative References
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration [BCP90] 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, <https://www.rfc-editor.org/info/bcp90>.
[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,
DOI 10.17487/RFC2616, June 1999,
<https://www.rfc-editor.org/info/rfc2616>.
[RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed
Authoring and Versioning (WebDAV)", RFC 4918, June 2007. Authoring and Versioning (WebDAV)", RFC 4918,
DOI 10.17487/RFC4918, June 2007,
Appendix A. Changes from RFC 2616 <https://www.rfc-editor.org/info/rfc4918>.
The definition of validator weakness has been expanded and clarified.
(Section 2.1)
Weak entity-tags are now allowed in all requests except range
requests. (Sections 2.1 and 3.2)
The ETag header field ABNF has been changed to not use quoted-string, [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
thus avoiding escaping issues. (Section 2.3) Protocol (HTTP/1.1): Conditional Requests", RFC 7232,
DOI 10.17487/RFC7232, June 2014,
<https://www.rfc-editor.org/info/rfc7232>.
ETag is defined to provide an entity tag for the selected Appendix A. Changes from RFC 7232
representation, thereby clarifying what it applies to in various
situations (such as a PUT response). (Section 2.3)
The precedence for evaluation of conditional requests has been None yet.
defined. (Section 6)
Appendix B. Imported ABNF Appendix B. Imported ABNF
The following core rules are included by reference, as defined in The following core rules are included by reference, as defined in
Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return),
CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double
quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any
8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII
character). character).
The rules below are defined in [RFC7230]: The rules below are defined in [MESSGNG]:
OWS = <OWS, see [RFC7230], Section 3.2.3> OWS = <OWS, see [MESSGNG], Section 3.2.3>
obs-text = <obs-text, see [RFC7230], Section 3.2.6> obs-text = <obs-text, see [MESSGNG], Section 3.2.6>
The rules below are defined in other parts: The rules below are defined in other parts:
HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1> HTTP-date = <HTTP-date, see [SEMNTCS], Section 7.1.1.1>
Appendix C. Collected ABNF Appendix C. Collected ABNF
In the collected ABNF below, list rules are expanded as per Section In the collected ABNF below, list rules are expanded as per
1.2 of [RFC7230]. Section 1.2 of [MESSGNG].
ETag = entity-tag ETag = entity-tag
HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1> HTTP-date = <HTTP-date, see [SEMNTCS], Section 7.1.1.1>
If-Match = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS If-Match = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS
entity-tag ] ) ) entity-tag ] ) )
If-Modified-Since = HTTP-date If-Modified-Since = HTTP-date
If-None-Match = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS If-None-Match = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS
entity-tag ] ) ) entity-tag ] ) )
If-Unmodified-Since = HTTP-date If-Unmodified-Since = HTTP-date
Last-Modified = HTTP-date Last-Modified = HTTP-date
OWS = <OWS, see [RFC7230], Section 3.2.3> OWS = <OWS, see [MESSGNG], Section 3.2.3>
entity-tag = [ weak ] opaque-tag entity-tag = [ weak ] opaque-tag
etagc = "!" / %x23-7E ; '#'-'~' etagc = "!" / %x23-7E ; '#'-'~'
/ obs-text / obs-text
obs-text = <obs-text, see [RFC7230], Section 3.2.6> obs-text = <obs-text, see [MESSGNG], Section 3.2.6>
opaque-tag = DQUOTE *etagc DQUOTE opaque-tag = DQUOTE *etagc DQUOTE
weak = %x57.2F ; W/ weak = %x57.2F ; W/
Appendix D. Change Log
This section is to be removed before publishing as an RFC.
D.1. Since RFC 7232
The changes in this draft are purely editorial:
o Change boilerplate and abstract to indicate the "draft" status,
and update references to ancestor specifications.
o Remove version "1.1" from document title, indicating that this
specification applies to all HTTP versions.
o Adjust historical notes.
o Update links to sibling specifications.
o Replace sections listing changes from RFC 2616 by new empty
sections referring to RFC 723x.
o Remove acknowledgements specific to RFC 723x.
o Move "Acknowledgements" to the very end and make them unnumbered.
Index Index
3 3
304 Not Modified (status code) 19 304 Not Modified (status code) 17
4 4
412 Precondition Failed (status code) 18 412 Precondition Failed (status code) 18
E E
ETag header field 9 ETag header field 8
G G
Grammar Grammar
entity-tag 9 entity-tag 9
ETag 9 ETag 9
etagc 9 etagc 9
If-Match 13 If-Match 12
If-Modified-Since 15 If-Modified-Since 15
If-None-Match 14 If-None-Match 14
If-Unmodified-Since 17 If-Unmodified-Since 16
Last-Modified 7 Last-Modified 6
opaque-tag 9 opaque-tag 9
weak 9 weak 9
I I
If-Match header field 13 If-Match header field 12
If-Modified-Since header field 16 If-Modified-Since header field 15
If-None-Match header field 14 If-None-Match header field 13
If-Unmodified-Since header field 17 If-Unmodified-Since header field 16
L L
Last-Modified header field 7 Last-Modified header field 6
M M
metadata 5 metadata 4
S S
selected representation 4 selected representation 3
V V
validator 5 validator 4
strong 5 strong 5
weak 5 weak 5
Acknowledgments
See Appendix "Acknowledgments" of [MESSGNG].
Authors' Addresses Authors' Addresses
Roy T. Fielding (editor) Roy T. Fielding (editor)
Adobe Systems Incorporated Adobe
345 Park Ave 345 Park Ave
San Jose, CA 95110 San Jose, CA 95110
USA USA
EMail: fielding@gbiv.com EMail: fielding@gbiv.com
URI: http://roy.gbiv.com/ URI: http://roy.gbiv.com/
Mark Nottingham (editor)
Fastly
EMail: mnot@mnot.net
URI: https://www.mnot.net/
Julian F. Reschke (editor) Julian F. Reschke (editor)
greenbytes GmbH greenbytes GmbH
Hafenweg 16 Hafenweg 16
Muenster, NW 48155 Muenster, NW 48155
Germany Germany
EMail: julian.reschke@greenbytes.de EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/ URI: http://greenbytes.de/tech/webdav/
 End of changes. 72 change blocks. 
180 lines changed or deleted 238 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/