draft-ietf-httpbis-p4-conditional-16.txt   draft-ietf-httpbis-p4-conditional-17.txt 
HTTPbis Working Group R. Fielding, Ed. HTTPbis Working Group R. Fielding, Ed.
Internet-Draft Adobe Internet-Draft Adobe
Obsoletes: 2616 (if approved) J. Gettys Obsoletes: 2616 (if approved) J. Gettys
Intended status: Standards Track Alcatel-Lucent Intended status: Standards Track Alcatel-Lucent
Expires: February 25, 2012 J. Mogul Expires: May 3, 2012 J. Mogul
HP HP
H. Frystyk H. Frystyk
Microsoft Microsoft
L. Masinter L. Masinter
Adobe Adobe
P. Leach P. Leach
Microsoft Microsoft
T. Berners-Lee T. Berners-Lee
W3C/MIT W3C/MIT
Y. Lafon, Ed. Y. Lafon, Ed.
W3C W3C
J. Reschke, Ed. J. Reschke, Ed.
greenbytes greenbytes
August 24, 2011 October 31, 2011
HTTP/1.1, part 4: Conditional Requests HTTP/1.1, part 4: Conditional Requests
draft-ietf-httpbis-p4-conditional-16 draft-ietf-httpbis-p4-conditional-17
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 49
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.17. The changes in this draft are summarized in Appendix C.18.
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 February 25, 2012. This Internet-Draft will expire on May 3, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 52 skipping to change at page 2, line 52
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 . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 5
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6
2. Validators . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Validators . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Weak versus Strong . . . . . . . . . . . . . . . . . . . . 6 2.1. Weak versus Strong . . . . . . . . . . . . . . . . . . . . 6
2.2. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 8 2.2. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1. Generation . . . . . . . . . . . . . . . . . . . . . . 8 2.2.1. Generation . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2. Comparison . . . . . . . . . . . . . . . . . . . . . . 9 2.2.2. Comparison . . . . . . . . . . . . . . . . . . . . . . 9
2.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.1. Generation . . . . . . . . . . . . . . . . . . . . . . 11 2.3.1. Generation . . . . . . . . . . . . . . . . . . . . . . 11
2.3.2. Comparison . . . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3. Precondition Header Fields . . . . . . . . . . . . . . . . . . 14 3. Precondition Header Fields . . . . . . . . . . . . . . . . . . 14
3.1. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.1. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 15 3.2. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 15
3.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 17 3.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 17
3.4. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 18 3.4. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 18
3.5. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.5. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 19
4. Status Code Definitions . . . . . . . . . . . . . . . . . . . 19 4. Status Code Definitions . . . . . . . . . . . . . . . . . . . 19
4.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 19 4.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 19
4.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 20 4.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 20
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
5.1. Status Code Registration . . . . . . . . . . . . . . . . . 20 5.1. Status Code Registration . . . . . . . . . . . . . . . . . 20
5.2. Header Field Registration . . . . . . . . . . . . . . . . 20 5.2. Header Field Registration . . . . . . . . . . . . . . . . 20
skipping to change at page 3, line 42 skipping to change at page 3, line 42
8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . . 21 8.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 22 Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 22
Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 22 Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 22
Appendix C. Change Log (to be removed by RFC Editor before Appendix C. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 23 publication) . . . . . . . . . . . . . . . . . . . . 23
C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 23 C.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 23
C.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 23 C.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 23
C.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 23 C.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 23
C.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 23 C.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 23
C.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 23 C.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 24
C.6. Since draft-ietf-httpbis-p4-conditional-04 . . . . . . . . 24 C.6. Since draft-ietf-httpbis-p4-conditional-04 . . . . . . . . 24
C.7. Since draft-ietf-httpbis-p4-conditional-05 . . . . . . . . 24 C.7. Since draft-ietf-httpbis-p4-conditional-05 . . . . . . . . 24
C.8. Since draft-ietf-httpbis-p4-conditional-06 . . . . . . . . 24 C.8. Since draft-ietf-httpbis-p4-conditional-06 . . . . . . . . 24
C.9. Since draft-ietf-httpbis-p4-conditional-07 . . . . . . . . 24 C.9. Since draft-ietf-httpbis-p4-conditional-07 . . . . . . . . 24
C.10. Since draft-ietf-httpbis-p4-conditional-08 . . . . . . . . 24 C.10. Since draft-ietf-httpbis-p4-conditional-08 . . . . . . . . 25
C.11. Since draft-ietf-httpbis-p4-conditional-09 . . . . . . . . 25 C.11. Since draft-ietf-httpbis-p4-conditional-09 . . . . . . . . 25
C.12. Since draft-ietf-httpbis-p4-conditional-10 . . . . . . . . 25 C.12. Since draft-ietf-httpbis-p4-conditional-10 . . . . . . . . 25
C.13. Since draft-ietf-httpbis-p4-conditional-11 . . . . . . . . 25 C.13. Since draft-ietf-httpbis-p4-conditional-11 . . . . . . . . 25
C.14. Since draft-ietf-httpbis-p4-conditional-12 . . . . . . . . 25 C.14. Since draft-ietf-httpbis-p4-conditional-12 . . . . . . . . 25
C.15. Since draft-ietf-httpbis-p4-conditional-13 . . . . . . . . 25 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 . . . . . . . . 26
C.17. Since draft-ietf-httpbis-p4-conditional-15 . . . . . . . . 26 C.17. Since draft-ietf-httpbis-p4-conditional-15 . . . . . . . . 26
C.18. Since draft-ietf-httpbis-p4-conditional-16 . . . . . . . . 26
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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-
skipping to change at page 5, line 36 skipping to change at page 5, line 36
harm will result when the precondition evaluates to false. harm will result when the precondition evaluates to false.
We use the term "selected representation" to refer to the current We use the term "selected representation" to refer to the current
representation of the target resource that would have been selected representation of the target resource that would have been selected
in a successful response if the same request had used the method GET in a successful response if the same request had used the method GET
and had excluded all of the conditional request header fields. The and had excluded all of the conditional request header fields. The
conditional request preconditions are evaluated by comparing the conditional request preconditions are evaluated by comparing the
values provided in the request header fields to the current metadata values provided in the request header fields to the current metadata
for the selected representation. for the selected representation.
1.1. Requirements 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].
An implementation is not compliant if it fails to satisfy one or more This document defines conformance criteria for several roles in HTTP
of the "MUST" or "REQUIRED" level requirements for the protocols it communication, including Senders, Recipients, Clients, Servers, User-
implements. An implementation that satisfies all the "MUST" or Agents, Origin Servers, Intermediaries, Proxies and Gateways. See
"REQUIRED" level and all the "SHOULD" level requirements for its Section 2 of [Part1] for definitions of these terms.
protocols is said to be "unconditionally compliant"; one that
satisfies all the "MUST" level requirements but not all the "SHOULD" An implementation is considered conformant if it complies with all of
level requirements for its protocols is said to be "conditionally the requirements associated with its role(s). Note that SHOULD-level
compliant". requirements are relevant here, unless one of the documented
exceptions is applicable.
This document also uses ABNF to define valid protocol elements
(Section 1.2). In addition to the prose requirements placed upon
them, Senders MUST NOT generate protocol elements that are invalid.
Unless noted otherwise, Recipients MAY take steps to recover a usable
protocol element from an invalid construct. However, HTTP does not
define specific error handling mechanisms, except in cases where it
has direct impact on security. This is because different uses of the
protocol require different error handling strategies; for example, a
Web browser may wish to transparently recover from a response where
the Location header field doesn't parse according to the ABNF,
whereby in a systems control protocol using HTTP, this type of error
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 ABNF syntax defined in Section 1.2 of
[Part1] (which extends the syntax defined in [RFC5234] with a list [Part1] (which extends the syntax defined in [RFC5234] with a list
rule). Appendix B shows the collected ABNF, with the list rule rule). Appendix B shows the collected ABNF, with the list rule
expanded. expanded.
The following core rules are included by reference, as defined in The following core rules are included by reference, as defined in
[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
sequence of data), SP (space), VCHAR (any visible USASCII character), sequence of data), SP (space), and VCHAR (any visible US-ASCII
and WSP (whitespace). character).
The ABNF rules below are defined in [Part1]: 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 1.2.2>
quoted-string = <quoted-string, defined in [Part1], Section 3.2.3> quoted-string = <quoted-string, defined in [Part1], Section 3.2.3>
HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> 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
"validator" when it is used within a precondition. "validator" when it is used within a precondition.
skipping to change at page 9, line 15 skipping to change at page 9, line 29
response is generated. response is generated.
An origin server with a clock MUST NOT send a Last-Modified date that An origin server with a clock MUST NOT send a Last-Modified date that
is later than the server's time of message origination (Date). If is later than the server's time of message origination (Date). If
the last modification time is derived from implementation-specific the last modification time is derived from implementation-specific
metadata that evaluates to some time in the future, according to the metadata that evaluates to some time in the future, according to the
origin server's clock, then the origin server MUST replace that value origin server's clock, then the origin server MUST replace that value
with the message origination date. This prevents a future with the message origination date. This prevents a future
modification date from having an adverse impact on cache validation. modification date from having an adverse impact on cache validation.
An origin server without a clock MUST NOT assign Last-Modified values
to a response unless these values were associated with the resource
by some other system or user with a reliable clock.
2.2.2. Comparison 2.2.2. Comparison
A Last-Modified time, when used as a validator in a request, is A Last-Modified time, when used as a validator in a request, is
implicitly weak unless it is possible to deduce that it is strong, implicitly weak unless it is possible to deduce that it is strong,
using the following rules: using the following rules:
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
skipping to change at page 13, line 21 skipping to change at page 13, line 24
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 6.2 of [Part1]) apply only during message codings (Section 5.1 of [Part1]) apply only during message
transfer and do not require distinct entity-tags. transfer 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:
skipping to change at page 19, line 27 skipping to change at page 19, line 27
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.3 of A 304 response MUST include a Date header field (Section 9.2 of
[Part1]) unless its omission is required by Section 9.3.1 of [Part1]. [Part2]) unless the origin server does not have a clock that can
If a 200 response to the same request would have included any of the provide a reasonable approximation of the current time. If a 200
header fields Cache-Control, Content-Location, ETag, Expires, Last- response to the same request would have included any of the header
Modified, or Vary, then those same header fields MUST be sent in a fields Cache-Control, Content-Location, ETag, Expires, Last-Modified,
304 response. or Vary, then those same header fields MUST be sent in a 304
response.
Since the goal of a 304 response is to minimize information transfer 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 7 skipping to change at page 21, line 7
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 12 of [Part1]. See Section 11 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., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
and Message Parsing", draft-ietf-httpbis-p1-messaging-16 and Message Parsing", draft-ietf-httpbis-p1-messaging-17
(work in progress), August 2011. (work in progress), October 2011.
[Part2] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 2: Message
Semantics", draft-ietf-httpbis-p2-semantics-17 (work in
progress), October 2011.
[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload
and Content Negotiation", draft-ietf-httpbis-p3-payload-16 and Content Negotiation", draft-ietf-httpbis-p3-payload-17
(work in progress), August 2011. (work in progress), October 2011.
[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
Partial Responses", draft-ietf-httpbis-p5-range-16 (work Partial Responses", draft-ietf-httpbis-p5-range-17 (work
in progress), August 2011. in progress), October 2011.
[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part
6: Caching", draft-ietf-httpbis-p6-cache-16 (work in 6: Caching", draft-ietf-httpbis-p6-cache-17 (work in
progress), August 2011. progress), October 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
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 22, line 20 skipping to change at page 22, line 25
Allow weak entity-tags in all requests except range requests Allow weak entity-tags in all requests except range requests
(Sections 2.1 and 3.2). (Sections 2.1 and 3.2).
Change ABNF productions for header fields to only define the field Change ABNF productions for header fields to only define the field
value. (Section 3) value. (Section 3)
Appendix B. Collected ABNF Appendix B. Collected ABNF
ETag = entity-tag ETag = entity-tag
HTTP-date = <HTTP-date, defined in [Part1], Section 6.1> HTTP-date = <HTTP-date, defined in [Part2], Section 8>
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
skipping to change at page 26, line 17 skipping to change at page 26, line 20
None. None.
C.17. Since draft-ietf-httpbis-p4-conditional-15 C.17. Since draft-ietf-httpbis-p4-conditional-15
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/304>: "If-Range o <http://tools.ietf.org/wg/httpbis/trac/ticket/304>: "If-Range
should be listed when dicussing contexts where L-M can be should be listed when dicussing contexts where L-M can be
considered strong" considered strong"
C.18. Since draft-ietf-httpbis-p4-conditional-16
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document
HTTP's error-handling philosophy"
Index Index
3 3
304 Not Modified (status code) 19 304 Not Modified (status code) 19
4 4
412 Precondition Failed (status code) 20 412 Precondition Failed (status code) 20
E E
ETag header field 10 ETag header field 10
skipping to change at page 26, line 43 skipping to change at page 27, line 4
If-Modified-Since 17 If-Modified-Since 17
If-None-Match 16 If-None-Match 16
If-Unmodified-Since 18 If-Unmodified-Since 18
Last-Modified 8 Last-Modified 8
opaque-tag 10 opaque-tag 10
weak 10 weak 10
H H
Header Fields Header Fields
ETag 10 ETag 10
If-Match 14 If-Match 15
If-Modified-Since 17 If-Modified-Since 17
If-None-Match 15 If-None-Match 15
If-Unmodified-Since 18 If-Unmodified-Since 18
Last-Modified 8 Last-Modified 8
I I
If-Match header field 14 If-Match header field 15
If-Modified-Since header field 17 If-Modified-Since header field 17
If-None-Match header field 15 If-None-Match header field 15
If-Unmodified-Since header field 18 If-Unmodified-Since header field 18
L L
Last-Modified header field 8 Last-Modified header field 8
M M
metadata 6 metadata 6
 End of changes. 27 change blocks. 
41 lines changed or deleted 75 lines changed or added

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