draft-ietf-httpbis-p4-conditional-18.txt   draft-ietf-httpbis-p4-conditional-19.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) Y. Lafon, Ed.
Intended status: Standards Track Alcatel-Lucent Intended status: Standards Track W3C
Expires: July 7, 2012 J. Mogul Expires: September 13, 2012 J. Reschke, Ed.
HP
H. Frystyk
Microsoft
L. Masinter
Adobe
P. Leach
Microsoft
T. Berners-Lee
W3C/MIT
Y. Lafon, Ed.
W3C
J. Reschke, Ed.
greenbytes greenbytes
January 4, 2012 March 12, 2012
HTTP/1.1, part 4: Conditional Requests HTTP/1.1, part 4: Conditional Requests
draft-ietf-httpbis-p4-conditional-18 draft-ietf-httpbis-p4-conditional-19
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypertext information protocol for distributed, collaborative, hypertext 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. "HTTP/1.1" and, taken together, obsoletes RFC 2616.
skipping to change at page 1, line 49 skipping to change at page 1, line 37
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), which is archived at group mailing list (ietf-http-wg@w3.org), which is archived at
<http://lists.w3.org/Archives/Public/ietf-http-wg/>. <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
The current issues list is at The current issues list is at
<http://tools.ietf.org/wg/httpbis/trac/report/3> and related <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.19. The changes in this draft are summarized in Appendix C.20.
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 July 7, 2012. This Internet-Draft will expire on September 13, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 2, line 51 skipping to change at page 2, line 39
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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conformance and Error Handling . . . . . . . . . . . . . . 5 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5
2. Validators . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Validators . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Weak versus Strong . . . . . . . . . . . . . . . . . . . . 6 2.1. Weak versus Strong . . . . . . . . . . . . . . . . . . . . 5
2.2. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 8 2.2. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1. Generation . . . . . . . . . . . . . . . . . . . . . . 8 2.2.1. Generation . . . . . . . . . . . . . . . . . . . . . . 7
2.2.2. Comparison . . . . . . . . . . . . . . . . . . . . . . 9 2.2.2. Comparison . . . . . . . . . . . . . . . . . . . . . . 8
2.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.1. Generation . . . . . . . . . . . . . . . . . . . . . . 11 2.3.1. Generation . . . . . . . . . . . . . . . . . . . . . . 10
2.3.2. Comparison . . . . . . . . . . . . . . . . . . . . . . 12 2.3.2. Comparison . . . . . . . . . . . . . . . . . . . . . . 11
2.3.3. Example: Entity-tags varying on Content-Negotiated 2.3.3. Example: Entity-tags varying on Content-Negotiated
Resources . . . . . . . . . . . . . . . . . . . . . . 12 Resources . . . . . . . . . . . . . . . . . . . . . . 11
2.4. Rules for When to Use Entity-tags and Last-Modified 2.4. Rules for When to Use Entity-tags and Last-Modified
Dates . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Dates . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3. Precondition Header Fields . . . . . . . . . . . . . . . . . . 15 3. Precondition Header Fields . . . . . . . . . . . . . . . . . . 14
3.1. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.1. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 16 3.2. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 15
3.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 17 3.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 16
3.4. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 18 3.4. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 17
3.5. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.5. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 18
4. Status Code Definitions . . . . . . . . . . . . . . . . . . . 19 4. Status Code Definitions . . . . . . . . . . . . . . . . . . . 18
4.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 19 4.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 18
4.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 20 4.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
5.1. Status Code Registration . . . . . . . . . . . . . . . . . 20 5.1. Status Code Registration . . . . . . . . . . . . . . . . . 19
5.2. Header Field Registration . . . . . . . . . . . . . . . . 20 5.2. Header Field Registration . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . . 22 8.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 22 Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 21
Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 23 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) . . . . . . . . . . . . . . . . . . . . 23 publication) . . . . . . . . . . . . . . . . . . . . 22
C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 23 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 . . . . . . . . 24 C.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 23
C.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 24 C.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 23
C.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 24 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 . . . . . . . . 25 C.7. Since draft-ietf-httpbis-p4-conditional-05 . . . . . . . . 24
C.8. Since draft-ietf-httpbis-p4-conditional-06 . . . . . . . . 25 C.8. Since draft-ietf-httpbis-p4-conditional-06 . . . . . . . . 24
C.9. Since draft-ietf-httpbis-p4-conditional-07 . . . . . . . . 25 C.9. Since draft-ietf-httpbis-p4-conditional-07 . . . . . . . . 24
C.10. Since draft-ietf-httpbis-p4-conditional-08 . . . . . . . . 25 C.10. Since draft-ietf-httpbis-p4-conditional-08 . . . . . . . . 24
C.11. Since draft-ietf-httpbis-p4-conditional-09 . . . . . . . . 25 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 . . . . . . . . 26 C.13. Since draft-ietf-httpbis-p4-conditional-11 . . . . . . . . 25
C.14. Since draft-ietf-httpbis-p4-conditional-12 . . . . . . . . 26 C.14. Since draft-ietf-httpbis-p4-conditional-12 . . . . . . . . 25
C.15. Since draft-ietf-httpbis-p4-conditional-13 . . . . . . . . 26 C.15. Since draft-ietf-httpbis-p4-conditional-13 . . . . . . . . 25
C.16. Since draft-ietf-httpbis-p4-conditional-14 . . . . . . . . 26 C.16. Since draft-ietf-httpbis-p4-conditional-14 . . . . . . . . 25
C.17. Since draft-ietf-httpbis-p4-conditional-15 . . . . . . . . 26 C.17. Since draft-ietf-httpbis-p4-conditional-15 . . . . . . . . 25
C.18. Since draft-ietf-httpbis-p4-conditional-16 . . . . . . . . 26 C.18. Since draft-ietf-httpbis-p4-conditional-16 . . . . . . . . 25
C.19. Since draft-ietf-httpbis-p4-conditional-17 . . . . . . . . 27 C.19. Since draft-ietf-httpbis-p4-conditional-17 . . . . . . . . 26
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 C.20. Since draft-ietf-httpbis-p4-conditional-18 . . . . . . . . 26
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
This document defines the HTTP/1.1 conditional request mechanisms, This document defines the HTTP/1.1 conditional request mechanisms,
including both metadata for indicating/observing changes in resource including both metadata for indicating/observing changes in resource
representations and request header fields that specify preconditions representations and request header fields that specify preconditions
on that metadata be checked before performing the request method. on that metadata be checked before performing the request method.
Conditional GET requests are the most efficient mechanism for HTTP Conditional GET requests are the most efficient mechanism for HTTP
cache updates [Part6]. Conditionals can also be applied to state- cache updates [Part6]. Conditionals can also be applied to state-
changing methods, such as PUT and DELETE, to prevent the "lost changing methods, such as PUT and DELETE, to prevent the "lost
skipping to change at page 6, line 19 skipping to change at page 5, line 19
define specific error handling mechanisms, except in cases where it define specific error handling mechanisms, except in cases where it
has direct impact on security. This is because different uses of the has direct impact on security. This is because different uses of the
protocol require different error handling strategies; for example, a protocol require different error handling strategies; for example, a
Web browser may wish to transparently recover from a response where Web browser may wish to transparently recover from a response where
the Location header field doesn't parse according to the ABNF, the Location header field doesn't parse according to the ABNF,
whereby in a systems control protocol using HTTP, this type of error whereby in a systems control protocol using HTTP, this type of error
recovery could lead to dangerous consequences. recovery could lead to dangerous consequences.
1.2. Syntax Notation 1.2. Syntax Notation
This specification uses the ABNF syntax defined in Section 1.2 of This specification uses the Augmented Backus-Naur Form (ABNF)
[Part1] (which extends the syntax defined in [RFC5234] with a list notation of [RFC5234] with the list rule extension defined in Section
rule). Appendix B shows the collected ABNF, with the list rule 1.2 of [Part1]. Appendix B shows the collected ABNF with the list
expanded. rule 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), and VCHAR (any visible US-ASCII sequence of data), SP (space), and VCHAR (any visible US-ASCII
character). character).
The ABNF rules below are defined in [Part1] and [Part2]: The ABNF rules below are defined in [Part1] and [Part2]:
OWS = <OWS, defined in [Part1], Section 1.2.2> OWS = <OWS, defined in [Part1], Section 3.2.1>
obs-text = <obs-text, defined in [Part1], Section 3.2.3> obs-text = <obs-text, defined in [Part1], Section 3.2.4>
HTTP-date = <HTTP-date, defined in [Part2], Section 8> HTTP-date = <HTTP-date, defined in [Part2], Section 8>
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 and opaque entity tags. Additional metadata that modification dates and opaque entity tags. Additional metadata that
reflects resource state has been defined by various extensions of reflects resource state has been defined by various extensions of
HTTP, such as WebDAV [RFC4918], that are beyond the scope of this HTTP, such as WebDAV [RFC4918], that are beyond the scope of this
specification. A resource metadata value is referred to as a specification. A resource metadata value is referred to as a
skipping to change at page 13, line 39 skipping to change at page 12, 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, so Note: Content codings are a property of the representation, so
therefore an entity-tag of an encoded representation must be therefore an entity-tag of an encoded representation must be
distinct from an unencoded representation to prevent conflicts distinct from an unencoded representation to prevent conflicts
during cache updates and range requests. In contrast, transfer during cache updates and range requests. In contrast, transfer
codings (Section 5.1 of [Part1]) apply only during message codings (Section 4 of [Part1]) apply only during message transfer
transfer and do not require distinct entity-tags. and do not require distinct entity-tags.
2.4. Rules for When to Use Entity-tags and Last-Modified Dates 2.4. 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
skipping to change at page 16, line 6 skipping to change at page 15, line 6
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.
Examples: 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 field is
undefined by this specification. undefined by this specification.
3.2. If-None-Match 3.2. If-None-Match
The "If-None-Match" header field MAY be used to make a request method The "If-None-Match" header field MAY be used to make a request method
conditional on not matching any of the current entity-tag values for conditional on not matching any of the current entity-tag values for
representations of the target resource. If-None-Match is primarily representations of the target resource. If-None-Match is primarily
used in conditional GET requests to enable efficient updates of used in conditional GET requests to enable efficient updates of
cached information with a minimum amount of transaction overhead. A cached information with a minimum amount of transaction overhead. A
client that has one or more representations previously obtained from client that has one or more representations previously obtained from
skipping to change at page 17, line 15 skipping to change at page 16, line 15
Examples: Examples:
If-None-Match: "xyzzy" If-None-Match: "xyzzy"
If-None-Match: W/"xyzzy" If-None-Match: W/"xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz" If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
If-None-Match: * If-None-Match: *
The result of a request having both an If-None-Match header field and 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 either an If-Match or an If-Unmodified-Since header field is
undefined by this specification. undefined by this specification.
3.3. If-Modified-Since 3.3. If-Modified-Since
The "If-Modified-Since" header field MAY be used to make a request The "If-Modified-Since" header field MAY be used to make a request
method conditional by modification date: if the selected method conditional by modification date: if the selected
representation has not been modified since the time specified in this representation has not been modified since the time specified in this
field, then do not perform the request method; instead, respond as field, then do not perform the request method; instead, respond as
detailed below. detailed below.
skipping to change at page 18, line 35 skipping to change at page 17, line 35
encodings of time between the client and server, are concerns. encodings of time between the client and server, are concerns.
This includes the possibility of race conditions if the document This includes the possibility of race conditions if the document
has changed between the time it was first requested and the If- has changed between the time it was first requested and the If-
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 field is
undefined by this specification. undefined by this specification.
3.4. If-Unmodified-Since 3.4. If-Unmodified-Since
The "If-Unmodified-Since" header field MAY be used to make a request The "If-Unmodified-Since" header field MAY be used to make a request
method conditional by modification date: if the selected method conditional by modification date: if the selected
representation has been modified since the time specified in this representation has been modified since the time specified in this
field, then the server MUST NOT perform the requested operation and field, then the server MUST NOT perform the requested operation and
MUST instead respond with the 412 (Precondition Failed) status code. MUST instead respond with the 412 (Precondition Failed) status code.
If the selected representation has not been modified since the time If the selected representation has not been modified since the time
skipping to change at page 19, line 15 skipping to change at page 18, line 15
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 MUST be 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. field is undefined by this specification.
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 If-Match and If-Unmodified-Since but 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 specific to HTTP range requests. If-Range is defined in Section 5.3
of [Part5]. of [Part5].
4. Status Code Definitions 4. Status Code Definitions
skipping to change at page 19, line 39 skipping to change at page 18, line 39
received and would have resulted in a 200 (OK) response if it were 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 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 words, there is no need for the server to transfer a representation
of the target resource because the client's request indicates that it of the target resource because the client's request indicates that it
already has a valid representation, as indicated by the 304 response already has a valid representation, as indicated by the 304 response
header fields, and is therefore redirecting the client to make use of header fields, and is therefore redirecting the client to make use of
that stored representation as if it were the payload of a 200 that stored representation as if it were the payload of a 200
response. The 304 response MUST NOT contain a message-body, and thus response. The 304 response MUST NOT contain a message-body, and thus
is always terminated by the first empty line after the header fields. is always terminated by the first empty line after the header fields.
A 304 response MUST include a Date header field (Section 9.2 of A 304 response MUST include a Date header field (Section 10.2 of
[Part2]) unless the origin server does not have a clock that can [Part2]) unless the origin server does not have a clock that can
provide a reasonable approximation of the current time. If a 200 provide a reasonable approximation of the current time. If a 200
response to the same request would have included any of the header response to the same request would have included any of the header
fields Cache-Control, Content-Location, ETag, Expires, Last-Modified, fields Cache-Control, Content-Location, ETag, Expires, or Vary, then
or Vary, then those same header fields MUST be sent in a 304 those same header fields MUST be sent in a 304 response.
response.
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, when the recipient already has one or more cached representations,
the response SHOULD NOT include representation metadata other than the response SHOULD NOT include representation metadata other than
the above listed fields unless said metadata exists for the purpose the above listed fields unless said metadata exists for the purpose
of guiding cache updates (e.g., future HTTP extensions). of guiding cache updates (e.g., future HTTP extensions).
If the recipient of a 304 response does not have a cached If the recipient of a 304 response does not have a cached
representation corresponding to the entity-tag indicated by the 304 representation corresponding to the entity-tag indicated by the 304
response, then the recipient MUST NOT use the 304 to update its own response, then the recipient MUST NOT use the 304 to update its own
skipping to change at page 21, line 26 skipping to change at page 20, line 26
The change controller is: "IETF (iesg@ietf.org) - Internet The change controller is: "IETF (iesg@ietf.org) - Internet
Engineering Task Force". Engineering Task Force".
6. 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].
7. Acknowledgments 7. Acknowledgments
See Section 11 of [Part1]. See Section 9 of [Part1].
8. References 8. References
8.1. Normative References 8.1. Normative References
[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part1] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., "HTTP/1.1, part 1: URIs, Connections, and Message
and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, Parsing", draft-ietf-httpbis-p1-messaging-19 (work in
and Message Parsing", draft-ietf-httpbis-p1-messaging-18 progress), March 2012.
(work in progress), January 2012.
[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part2] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., "HTTP/1.1, part 2: Message Semantics",
and J. Reschke, Ed., "HTTP/1.1, part 2: Message draft-ietf-httpbis-p2-semantics-19 (work in progress),
Semantics", draft-ietf-httpbis-p2-semantics-18 (work in March 2012.
progress), January 2012.
[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part3] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., "HTTP/1.1, part 3: Message Payload and Content
and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload Negotiation", draft-ietf-httpbis-p3-payload-19 (work in
and Content Negotiation", draft-ietf-httpbis-p3-payload-18 progress), March 2012.
(work in progress), January 2012.
[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., "HTTP/1.1, part 5: Range Requests and Partial Responses",
and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and draft-ietf-httpbis-p5-range-19 (work in progress),
Partial Responses", draft-ietf-httpbis-p5-range-18 (work March 2012.
in progress), January 2012.
[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part6] Fielding, R., Ed., Lafon, Y., Ed., Nottingham, M., Ed.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",
Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part draft-ietf-httpbis-p6-cache-19 (work in progress),
6: Caching", draft-ietf-httpbis-p6-cache-18 (work in March 2012.
progress), January 2012.
[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.
8.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.,
skipping to change at page 23, line 20 skipping to change at page 22, line 20
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, defined in [Part1], Section 1.2.2> OWS = <OWS, defined in [Part1], Section 3.2.1>
entity-tag = [ weak ] opaque-tag entity-tag = [ weak ] opaque-tag
etagc = "!" / %x23-7E ; '#'-'~' etagc = "!" / %x23-7E ; '#'-'~'
/ obs-text / obs-text
obs-text = <obs-text, defined in [Part1], Section 3.2.3> obs-text = <obs-text, defined in [Part1], Section 3.2.4>
opaque-tag = DQUOTE *etagc DQUOTE opaque-tag = DQUOTE *etagc DQUOTE
weak = %x57.2F ; W/ weak = %x57.2F ; W/
ABNF diagnostics: ABNF diagnostics:
; ETag defined but not used ; ETag defined but not used
; If-Match defined but not used ; If-Match defined but not used
; If-Modified-Since defined but not used ; If-Modified-Since defined but not used
; If-None-Match defined but not used ; If-None-Match defined but not used
skipping to change at page 27, line 12 skipping to change at page 26, line 12
o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document
HTTP's error-handling philosophy" HTTP's error-handling philosophy"
C.19. Since draft-ietf-httpbis-p4-conditional-17 C.19. Since draft-ietf-httpbis-p4-conditional-17
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/306>: "does etag o <http://tools.ietf.org/wg/httpbis/trac/ticket/306>: "does etag
value really use quoted-string" value really use quoted-string"
C.20. Since draft-ietf-httpbis-p4-conditional-18
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/345>: "Required
headers on 304 and 206"
Index Index
3 3
304 Not Modified (status code) 19 304 Not Modified (status code) 18
4 4
412 Precondition Failed (status code) 20 412 Precondition Failed (status code) 19
E E
ETag header field 10 ETag header field 9
G G
Grammar Grammar
entity-tag 10 entity-tag 9
ETag 10 ETag 9
etagc 10 etagc 9
If-Match 15 If-Match 14
If-Modified-Since 17 If-Modified-Since 16
If-None-Match 16 If-None-Match 15
If-Unmodified-Since 18 If-Unmodified-Since 17
Last-Modified 8 Last-Modified 7
opaque-tag 10 opaque-tag 9
weak 10 weak 9
H H
Header Fields Header Fields
ETag 10 ETag 9
If-Match 15 If-Match 14
If-Modified-Since 17 If-Modified-Since 16
If-None-Match 16 If-None-Match 15
If-Unmodified-Since 18 If-Unmodified-Since 17
Last-Modified 8 Last-Modified 7
I I
If-Match header field 15 If-Match header field 14
If-Modified-Since header field 17 If-Modified-Since header field 16
If-None-Match header field 16 If-None-Match header field 15
If-Unmodified-Since header field 18 If-Unmodified-Since header field 17
L L
Last-Modified header field 8 Last-Modified header field 7
M M
metadata 6 metadata 5
S S
selected representation 5 selected representation 4
Status Codes Status Codes
304 Not Modified 19 304 Not Modified 18
412 Precondition Failed 20 412 Precondition Failed 19
V V
validator 6 validator 5
strong 6 strong 5
weak 6 weak 5
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
URI: http://roy.gbiv.com/ URI: http://roy.gbiv.com/
Jim Gettys
Alcatel-Lucent Bell Labs
21 Oak Knoll Road
Carlisle, MA 01741
USA
EMail: jg@freedesktop.org
URI: http://gettys.wordpress.com/
Jeffrey C. Mogul
Hewlett-Packard Company
HP Labs, Large Scale Systems Group
1501 Page Mill Road, MS 1177
Palo Alto, CA 94304
USA
EMail: JeffMogul@acm.org
Henrik Frystyk Nielsen
Microsoft Corporation
1 Microsoft Way
Redmond, WA 98052
USA
EMail: henrikn@microsoft.com
Larry Masinter
Adobe Systems Incorporated
345 Park Ave
San Jose, CA 95110
USA
EMail: LMM@acm.org
URI: http://larry.masinter.net/
Paul J. Leach
Microsoft Corporation
1 Microsoft Way
Redmond, WA 98052
EMail: paulle@microsoft.com
Tim Berners-Lee
World Wide Web Consortium
MIT Computer Science and Artificial Intelligence Laboratory
The Stata Center, Building 32
32 Vassar Street
Cambridge, MA 02139
USA
EMail: timbl@w3.org
URI: http://www.w3.org/People/Berners-Lee/
Yves Lafon (editor) Yves Lafon (editor)
World Wide Web Consortium World Wide Web Consortium
W3C / ERCIM W3C / ERCIM
2004, rte des Lucioles 2004, rte des Lucioles
Sophia-Antipolis, AM 06902 Sophia-Antipolis, AM 06902
France France
EMail: ylafon@w3.org EMail: ylafon@w3.org
URI: http://www.raubacapeu.net/people/yves/ URI: http://www.raubacapeu.net/people/yves/
Julian F. Reschke (editor) Julian F. Reschke (editor)
greenbytes GmbH greenbytes GmbH
Hafenweg 16 Hafenweg 16
Muenster, NW 48155 Muenster, NW 48155
Germany Germany
Phone: +49 251 2807760 Phone: +49 251 2807760
Fax: +49 251 2807761 Fax: +49 251 2807761
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. 40 change blocks. 
199 lines changed or deleted 138 lines changed or added

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