< draft-ietf-httpbis-p4-conditional-20.txt   draft-ietf-httpbis-p4-conditional-21.txt >
HTTPbis Working Group R. Fielding, Ed. HTTPbis Working Group R. Fielding, Ed.
Internet-Draft Adobe Internet-Draft Adobe
Obsoletes: 2616 (if approved) Y. Lafon, Ed. Obsoletes: 2616 (if approved) J. Reschke, Ed.
Intended status: Standards Track W3C Intended status: Standards Track greenbytes
Expires: January 17, 2013 J. Reschke, Ed. Expires: April 7, 2013 October 4, 2012
greenbytes
July 16, 2012
HTTP/1.1, part 4: Conditional Requests Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
draft-ietf-httpbis-p4-conditional-20 draft-ietf-httpbis-p4-conditional-21
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. 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.
skipping to change at page 1, line 35 skipping to change at page 1, line 33
Discussion of this draft takes place on the HTTPBIS working group Discussion of this draft takes place on the HTTPBIS working group
mailing list (ietf-http-wg@w3.org), which is archived at 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 D.1. The changes in this draft are summarized in Appendix D.2.
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 April 7, 2013.
This Internet-Draft will expire on January 17, 2013.
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 3, line 11 skipping to change at page 3, line 11
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5
2. Validators . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Validators . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Weak versus Strong . . . . . . . . . . . . . . . . . . . . 6 2.1. Weak versus Strong . . . . . . . . . . . . . . . . . . . . 5
2.2. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1. Generation . . . . . . . . . . . . . . . . . . . . . . 8 2.2.1. Generation . . . . . . . . . . . . . . . . . . . . . . 7
2.2.2. Comparison . . . . . . . . . . . . . . . . . . . . . . 8 2.2.2. Comparison . . . . . . . . . . . . . . . . . . . . . . 8
2.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.1. Generation . . . . . . . . . . . . . . . . . . . . . . 10 2.3.1. Generation . . . . . . . . . . . . . . . . . . . . . . 10
2.3.2. Comparison . . . . . . . . . . . . . . . . . . . . . . 11 2.3.2. Comparison . . . . . . . . . . . . . . . . . . . . . . 10
2.3.3. Example: Entity-tags varying on Content-Negotiated 2.3.3. Example: Entity-tags varying on Content-Negotiated
Resources . . . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Dates . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3. Precondition Header Fields . . . . . . . . . . . . . . . . . . 14 3. Precondition Header Fields . . . . . . . . . . . . . . . . . . 13
3.1. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.1. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 15 3.2. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 14
3.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 16 3.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 16
3.4. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 17 3.4. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 17
3.5. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.5. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 17
4. Status Code Definitions . . . . . . . . . . . . . . . . . . . 18 4. Status Code Definitions . . . . . . . . . . . . . . . . . . . 18
4.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 18 4.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 18
4.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 19 4.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 18
5. Precedence . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5. Precedence . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
6.1. Status Code Registration . . . . . . . . . . . . . . . . . 20 6.1. Status Code Registration . . . . . . . . . . . . . . . . . 20
6.2. Header Field Registration . . . . . . . . . . . . . . . . 21 6.2. Header Field Registration . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . . 22 9.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 22 Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 22
Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 23 Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 22
Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 23 Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 23
Appendix D. Change Log (to be removed by RFC Editor before Appendix D. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 24 publication) . . . . . . . . . . . . . . . . . . . . 23
D.1. Since draft-ietf-httpbis-p4-conditional-19 . . . . . . . . 24 D.1. Since draft-ietf-httpbis-p4-conditional-19 . . . . . . . . 23
D.2. Since draft-ietf-httpbis-p4-conditional-20 . . . . . . . . 24
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
Conditional requests are HTTP requests [Part2] that include one or Conditional requests are HTTP requests [Part2] 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. Each applying the method semantics to the target resource. Each
precondition is based on metadata that is expected to change if the precondition is based on metadata that is expected to change if the
selected representation of the target resource is changed. This selected representation of the target resource is changed. This
document defines the HTTP/1.1 conditional request mechanisms in terms document defines the HTTP/1.1 conditional request mechanisms in terms
skipping to change at page 4, line 47 skipping to change at page 4, line 47
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. 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].
This specification targets conformance criteria according to the role Conformance criteria and considerations regarding error handling are
of a participant in HTTP communication. Hence, HTTP requirements are defined in Section 2.5 of [Part1].
placed on senders, recipients, clients, servers, user agents,
intermediaries, origin servers, proxies, gateways, or caches,
depending on what behavior is being constrained by the requirement.
See Section 2 of [Part1] for definitions of these terms.
The verb "generate" is used instead of "send" where a requirement
differentiates between creating a protocol element and merely
forwarding a received element downstream.
An implementation is considered conformant if it complies with all of
the requirements associated with the roles it partakes in HTTP. Note
that SHOULD-level 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 do not match
the grammar defined by the ABNF rules for those protocol elements
that are applicable to the sender's role. If a received protocol
element is processed, the recipient MUST be able to parse any value
that would match the ABNF rules for that protocol element, excluding
only those rules not applicable to the recipient's role.
Unless noted otherwise, a recipient MAY attempt to recover a usable
protocol element from an invalid construct. HTTP does not define
specific error handling mechanisms except when they have a direct
impact on security, since different applications of the protocol
require different error handling strategies. For example, a Web
browser might wish to transparently recover from a response where the
Location header field doesn't parse according to the ABNF, whereas a
systems control client might consider any form of error recovery to
be dangerous.
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 the list rule extension defined in Section notation of [RFC5234] with the list rule extension defined in Section
1.2 of [Part1]. Appendix B describes rules imported from other 1.2 of [Part1]. Appendix B describes rules imported from other
documents. Appendix C shows the collected ABNF with the list rule documents. Appendix C shows the collected ABNF with the list rule
expanded. expanded.
2. Validators 2. Validators
skipping to change at page 11, line 41 skipping to change at page 11, line 16
| 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 8 Consider a resource that is subject to content negotiation (Section
of [Part2]), and where the representations returned upon a GET 3.4 of [Part2]), and where the representations returned upon a GET
request vary based on the Accept-Encoding request header field request vary based on the Accept-Encoding request header field
(Section 9.3 of [Part2]): (Section 6.3.4 of [Part2]):
>> 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 18, line 38 skipping to change at page 18, line 20
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.10 of A 304 response MUST include a Date header field (Section 8.1.1.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
(OK) response to the same request would have included any of the (OK) response to the same request would have included any of the
header fields Cache-Control, Content-Location, ETag, Expires, or header fields Cache-Control, Content-Location, ETag, Expires, or
Vary, then those same header fields MUST be sent in a 304 response. 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
skipping to change at page 22, line 4 skipping to change at page 21, line 25
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.
8. Acknowledgments 8. Acknowledgments
See Section 9 of [Part1]. See Section 9 of [Part1].
9. References 9. References
9.1. Normative References 9.1. Normative References
[Part1] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., [Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
"HTTP/1.1, part 1: Message Routing and Syntax"", Protocol (HTTP/1.1): Message Syntax and Routing",
draft-ietf-httpbis-p1-messaging-20 (work in progress), draft-ietf-httpbis-p1-messaging-21 (work in progress),
July 2012. October 2012.
[Part2] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., [Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
"HTTP/1.1, part 2: Semantics and Payloads", Protocol (HTTP/1.1): Semantics and Content",
draft-ietf-httpbis-p2-semantics-20 (work in progress), draft-ietf-httpbis-p2-semantics-21 (work in progress),
July 2012. October 2012.
[Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., [Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
"HTTP/1.1, part 5: Range Requests", "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
draft-ietf-httpbis-p5-range-20 (work in progress), draft-ietf-httpbis-p5-range-21 (work in progress),
July 2012. October 2012.
[Part6] Fielding, R., Ed., Lafon, Y., Ed., Nottingham, M., Ed., [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
draft-ietf-httpbis-p6-cache-20 (work in progress), draft-ietf-httpbis-p6-cache-21 (work in progress),
July 2012. October 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.
9.2. Informative References 9.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 50 skipping to change at page 22, line 24
September 2004. September 2004.
[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, June 2007.
Appendix A. Changes from RFC 2616 Appendix A. Changes from RFC 2616
Allow weak entity-tags in all requests except range requests Allow weak entity-tags in all requests except range requests
(Sections 2.1 and 3.2). (Sections 2.1 and 3.2).
Change ETag header field ABNF not to use quoted-string, thus avoiding Change "ETag" header field ABNF not to use quoted-string, thus
escaping issues. (Section 2.3) avoiding escaping issues. (Section 2.3)
Change ABNF productions for header fields to only define the field
value. (Section 3)
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 [Part1]: The rules below are defined in [Part1]:
OWS = <OWS, defined in [Part1], Section 3.2.1> OWS = <OWS, defined in [Part1], Section 3.2.1>
obs-text = <obs-text, defined in [Part1], Section 3.2.4> obs-text = <obs-text, defined in [Part1], Section 3.2.4>
The rules below are defined in other parts: The rules below are defined in other parts:
HTTP-date = <HTTP-date, defined in [Part2], Section 5.1> HTTP-date = <HTTP-date, defined in [Part2], Section 8.1.1.1>
Appendix C. Collected ABNF Appendix C. Collected ABNF
ETag = entity-tag ETag = entity-tag
HTTP-date = <HTTP-date, defined in [Part2], Section 5.1> HTTP-date = <HTTP-date, defined in [Part2], Section 8.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
skipping to change at page 24, line 18 skipping to change at page 23, line 44
in <http://tools.ietf.org/html/ in <http://tools.ietf.org/html/
draft-ietf-httpbis-p4-conditional-19#appendix-C>. draft-ietf-httpbis-p4-conditional-19#appendix-C>.
D.1. Since draft-ietf-httpbis-p4-conditional-19 D.1. Since draft-ietf-httpbis-p4-conditional-19
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/241>: "Need to o <http://tools.ietf.org/wg/httpbis/trac/ticket/241>: "Need to
clarify eval order/interaction of conditional headers" clarify eval order/interaction of conditional headers"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/345>: "Required
headers on 304 and 206"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/350>: "Optionality
of Conditional Request Support"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/354>: "ETags and o <http://tools.ietf.org/wg/httpbis/trac/ticket/354>: "ETags and
Conditional Requests" Conditional Requests"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/361>: "ABNF o <http://tools.ietf.org/wg/httpbis/trac/ticket/361>: "ABNF
requirements for recipients" requirements for recipients"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/363>: "Rare cases" o <http://tools.ietf.org/wg/httpbis/trac/ticket/363>: "Rare cases"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/365>: "Conditional o <http://tools.ietf.org/wg/httpbis/trac/ticket/365>: "Conditional
Request Security Considerations" Request Security Considerations"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/371>: "If-Modified- o <http://tools.ietf.org/wg/httpbis/trac/ticket/371>: "If-Modified-
Since lacks definition for method != GET" Since lacks definition for method != GET"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/372>: "refactor o <http://tools.ietf.org/wg/httpbis/trac/ticket/372>: "refactor
conditional header field descriptions" conditional header field descriptions"
D.2. Since draft-ietf-httpbis-p4-conditional-20
o Conformance criteria and considerations regarding error handling
are now defined in Part 1.
Index Index
3 3
304 Not Modified (status code) 18 304 Not Modified (status code) 18
4 4
412 Precondition Failed (status code) 19 412 Precondition Failed (status code) 18
E E
ETag header field 9 ETag header field 9
G G
Grammar Grammar
entity-tag 10 entity-tag 9
ETag 10
etagc 10
If-Match 14
If-Modified-Since 16
If-None-Match 15
If-Unmodified-Since 17
Last-Modified 7
opaque-tag 10
weak 10
H
Header Fields
ETag 9 ETag 9
etagc 9
If-Match 14 If-Match 14
If-Modified-Since 16 If-Modified-Since 16
If-None-Match 15 If-None-Match 15
If-Unmodified-Since 17 If-Unmodified-Since 17
Last-Modified 7 Last-Modified 7
opaque-tag 9
weak 9
I I
If-Match header field 14 If-Match header field 13
If-Modified-Since header field 16 If-Modified-Since header field 16
If-None-Match header field 15 If-None-Match header field 14
If-Unmodified-Since header field 17 If-Unmodified-Since header field 17
L L
Last-Modified header field 7 Last-Modified header field 7
M M
metadata 5 metadata 5
S S
selected representation 4 selected representation 4
Status Codes
304 Not Modified 18
412 Precondition Failed 19
V V
validator 5 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/
Yves Lafon (editor)
World Wide Web Consortium
W3C / ERCIM
2004, rte des Lucioles
Sophia-Antipolis, AM 06902
France
EMail: ylafon@w3.org
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
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. 37 change blocks. 
114 lines changed or deleted 68 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/