p4-conditional.unpg.txt   rfc7232-to-be.unpg.txt 
HTTPbis Working Group R. Fielding, Ed. Internet Engineering Task Force (IETF) R. Fielding, Ed.
Internet-Draft Adobe Request for Comments: 7232 Adobe
Obsoletes: 2616 (if approved) J. Reschke, Ed. Obsoletes: 2616 J. Reschke, Ed.
Intended status: Standards Track greenbytes Category: Standards Track greenbytes
Expires: November 20, 2014 May 19, 2014 ISSN: 2070-1721 May 2014
Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
draft-ietf-httpbis-p4-conditional-latest
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is a stateless application- The Hypertext Transfer Protocol (HTTP) is a stateless application-
level protocol for distributed, collaborative, hypertext information level protocol for distributed, collaborative, hypertext information
systems. This document defines HTTP/1.1 conditional requests, systems. This document defines HTTP/1.1 conditional requests,
including metadata header fields for indicating state changes, including metadata header fields for indicating state changes,
request header fields for making preconditions on such state, and request header fields for making preconditions on such state, and
rules for constructing the responses to a conditional request when rules for constructing the responses to a conditional request when
one or more preconditions evaluate to false. one or more preconditions evaluate to false.
Editorial Note (To be removed by RFC Editor)
Discussion of this draft takes place on the HTTPBIS working group
mailing list (ietf-http-wg@w3.org), which is archived at
<http://lists.w3.org/Archives/Public/ietf-http-wg/>.
The current issues list is at
<http://tools.ietf.org/wg/httpbis/trac/report/3> and related
documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>.
_This is a temporary document for the purpose of tracking the
editorial changes made during the AUTH48 (RFC publication) phase._
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is a product of the Internet Engineering Task Force
Task Force (IETF). Note that other groups may also distribute (IETF). It represents the consensus of the IETF community. It has
working documents as Internet-Drafts. The list of current Internet- received public review and has been approved for publication by the
Drafts is at http://datatracker.ietf.org/drafts/current/. Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference http://www.rfc-editor.org/info/rfc7232.
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 20, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 5, line 13 skipping to change at page 5, line 13
documents. Appendix C shows the collected grammar with all list documents. Appendix C shows the collected grammar with all list
operators expanded to standard ABNF notation. operators expanded to standard ABNF notation.
2. Validators 2. Validators
This specification defines two forms of metadata that are commonly This specification defines two forms of metadata that are commonly
used to observe resource state and test for preconditions: used to observe resource state and test for preconditions:
modification dates (Section 2.2) and opaque entity tags modification dates (Section 2.2) and opaque entity tags
(Section 2.3). Additional metadata that reflects resource state has (Section 2.3). Additional metadata that reflects resource state has
been defined by various extensions of HTTP, such as Web Distributed been defined by various extensions of HTTP, such as Web Distributed
Authoring and Versioning (WebDAV, [RFC4918]), that are beyond the Authoring and Versioning (WebDAV) [RFC4918], that are beyond the
scope of this specification. A resource metadata value is referred scope of this specification. A resource metadata value is referred
to as a "validator" when it is used within a precondition. to as a "validator" when it is used within a precondition.
2.1. Weak versus Strong 2.1. Weak versus Strong
Validators come in two flavors: strong or weak. Weak validators are Validators come in two flavors: strong or weak. Weak validators are
easy to generate but are far less useful for comparisons. Strong easy to generate but are far less useful for comparisons. Strong
validators are ideal for comparisons but can be very difficult (and validators are ideal for comparisons but can be very difficult (and
occasionally impossible) to generate efficiently. Rather than impose occasionally impossible) to generate efficiently. Rather than impose
that all forms of resource adhere to the same strength of validator, that all forms of resource adhere to the same strength of validator,
HTTP exposes the type of validator in use and imposes restrictions on HTTP exposes the type of validator in use and imposes restrictions on
when weak validators can be used as preconditions. when weak validators can be used as preconditions.
A "strong validator" is representation metadata that changes value A "strong validator" is representation metadata that changes value
whenever a change occurs to the representation data that would be whenever a change occurs to the representation data that would be
observable in the payload body of a 200 (OK) response to GET. observable in the payload body of a 200 (OK) response to GET.
A strong validator might change for reasons other than a change to A strong validator might change for reasons other than a change to
the representation data, such as when a semantically significant part the representation data, such as when a semantically significant part
of the representation metadata is changed (e.g., Content-Type), but of the representation metadata is changed (e.g., Content-Type), but
it is in the best interests of the origin server to only change the it is in the best interests of the origin server to change only the
value when it is necessary to invalidate the stored responses held by value when it is necessary to invalidate the stored responses held by
remote caches and authoring tools. remote caches and authoring tools.
Cache entries might persist for arbitrarily long periods, regardless Cache entries might persist for arbitrarily long periods, regardless
of expiration times. Thus, a cache might attempt to validate an of expiration times. Thus, a cache might attempt to validate an
entry using a validator that it obtained in the distant past. A entry using a validator that it obtained in the distant past. A
strong validator is unique across all versions of all representations strong validator is unique across all versions of all representations
associated with a particular resource over time. However, there is associated with a particular resource over time. However, there is
no implication of uniqueness across representations of different no implication of uniqueness across representations of different
resources (i.e., the same strong validator might be in use for resources (i.e., the same strong validator might be in use for
skipping to change at page 8, line 25 skipping to change at page 8, line 25
o The validator is being compared by an origin server to the actual o The validator is being compared by an origin server to the actual
current validator for the representation and, current validator for the representation and,
o That origin server reliably knows that the associated o That origin server reliably knows that the associated
representation did not change twice during the second covered by representation did not change twice during the second covered by
the presented validator. the presented validator.
or or
o The validator is about to be used by a client in an If-Modified- o The validator is about to be used by a client in an If-Modified-
Since, If-Unmodified-Since, or If-Range header field, because the Since or If-Unmodified-Since header field, because the client has
client has a cache entry for the associated representation, and a cache entry, or If-Range for the associated representation, and
o That cache entry includes a Date value, which gives the time when o That cache entry includes a Date value, which gives the time when
the origin server sent the original response, and the origin server sent the original response, and
o The presented Last-Modified time is at least 60 seconds before the o The presented Last-Modified time is at least 60 seconds before the
Date value. Date value.
or or
o The validator is being compared by an intermediate cache to the o The validator is being compared by an intermediate cache to the
skipping to change at page 13, line 51 skipping to change at page 13, line 51
An origin server that receives an If-Match header field MUST evaluate An origin server that receives an If-Match header field MUST evaluate
the condition prior to performing the method (Section 5). If the the condition prior to performing the method (Section 5). If the
field-value is "*", the condition is false if the origin server does field-value is "*", the condition is false if the origin server does
not have a current representation for the target resource. If the not have a current representation for the target resource. If the
field-value is a list of entity-tags, the condition is false if none field-value is a list of entity-tags, the condition is false if none
of the listed tags match the entity-tag of the selected of the listed tags match the entity-tag of the selected
representation. representation.
An origin server MUST NOT perform the requested method if a received An origin server MUST NOT perform the requested method if a received
If-Match condition evaluates to false; instead, the origin server If-Match condition evaluates to false; instead, the origin server
MUST respond with either a) the 412 (Precondition Failed) status code MUST respond with either: a) the 412 (Precondition Failed) status
or b) one of the 2xx (Successful) status codes if the origin server code or b) one of the 2xx (Successful) status codes if the origin
has verified that a state change is being requested and the final server has verified that a state change is being requested and the
state is already reflected in the current state of the target final state is already reflected in the current state of the target
resource (i.e., the change requested by the user agent has already resource (i.e., the change requested by the user agent has already
succeeded, but the user agent might not be aware of it, perhaps succeeded, but the user agent might not be aware of it, perhaps
because the prior response was lost or a compatible change was made because the prior response was lost or a compatible change was made
by some other user agent). In the latter case, the origin server by some other user agent). In the latter case, the origin server
MUST NOT send a validator header field in the response unless it can MUST NOT send a validator header field in the response unless it can
verify that the request is a duplicate of an immediately prior change verify that the request is a duplicate of an immediately prior change
made by the same user agent. made by the same user agent.
The If-Match header field can be ignored by caches and intermediaries The If-Match header field can be ignored by caches and intermediaries
because it is not applicable to a stored response. because it is not applicable to a stored response.
skipping to change at page 15, line 43 skipping to change at page 15, line 43
If-Modified-Since = HTTP-date If-Modified-Since = HTTP-date
An example of the field is: An example of the field is:
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
A recipient MUST ignore If-Modified-Since if the request contains an A recipient MUST ignore If-Modified-Since if the request contains an
If-None-Match header field; the condition in If-None-Match is If-None-Match header field; the condition in If-None-Match is
considered to be a more accurate replacement for the condition in If- considered to be a more accurate replacement for the condition in If-
Modified-Since, and the two are only combined for the sake of Modified-Since and the two are only combined for the sake of
interoperating with older intermediaries that might not implement If- interoperating with older intermediaries that might not implement If-
None-Match. None-Match.
A recipient MUST ignore the If-Modified-Since header field if the A recipient MUST ignore the If-Modified-Since header field if the
received field-value is not a valid HTTP-date, or if the request received field-value is not a valid HTTP-date, or if the request
method is neither GET nor HEAD. method is neither GET nor HEAD.
A recipient MUST interpret an If-Modified-Since field-value's A recipient MUST interpret an If-Modified-Since field-value's
timestamp in terms of the origin server's clock. timestamp in terms of the origin server's clock.
skipping to change at page 18, line 28 skipping to change at page 18, line 28
The 304 (Not Modified) status code indicates that a conditional GET The 304 (Not Modified) status code indicates that a conditional GET
or HEAD request has been received and would have resulted in a 200 or HEAD request has been received and would have resulted in a 200
(OK) response if it were not for the fact that the condition (OK) response if it were not for the fact that the condition
evaluated to false. In other words, there is no need for the server evaluated to false. In other words, there is no need for the server
to transfer a representation of the target resource because the to transfer a representation of the target resource because the
request indicates that the client, which made the request request indicates that the client, which made the request
conditional, already has a valid representation; the server is conditional, already has a valid representation; the server is
therefore redirecting the client to make use of that stored therefore redirecting the client to make use of that stored
representation as if it were the payload of a 200 (OK) response. representation as if it were the payload of a 200 (OK) response.
The server generating a 304 response MUST generate any of the The server generating a 304 (Not Modified) response MUST generate any
following header fields that would have been sent in a 200 (OK) of the following header fields that would have been sent in a 200
response to the same request: Cache-Control, Content-Location, Date, (OK) response to the same request: Cache-Control, Content-Location,
ETag, Expires, and Vary. Date, ETag, Expires, and Vary.
Since the goal of a 304 response is to minimize information transfer Since the goal of a 304 (Not Modified) response is to minimize
when the recipient already has one or more cached representations, a information transfer when the recipient already has one or more
sender SHOULD NOT generate representation metadata other than the cached representations, a sender SHOULD NOT generate representation
above listed fields unless said metadata exists for the purpose of metadata other than the above listed fields unless said metadata
guiding cache updates (e.g., Last-Modified might be useful if the exists for the purpose of guiding cache updates (e.g., Last-Modified
response does not have an ETag field). might be useful if the response does not have an ETag field).
Requirements on a cache that receives a 304 response are defined in Requirements on a cache that receives a 304 (Not Modified) response
Section 4.3.4 of [RFC7234]. If the conditional request originated are defined in Section 4.3.4 of [RFC7234]. If the conditional
with an outbound client, such as a user agent with its own cache request originated with an outbound client, such as a user agent with
sending a conditional GET to a shared proxy, then the proxy SHOULD its own cache sending a conditional GET to a shared proxy, then the
forward the 304 response to that client. proxy SHOULD forward the 304 (Not Modified) response to that client.
A 304 response cannot contain a message-body; it is always terminated A 304 (Not Modified) response cannot contain a message-body; it is
by the first empty line after the header fields. always terminated by the first empty line after the header fields.
4.2. 412 Precondition Failed 4.2. 412 Precondition Failed
The 412 (Precondition Failed) status code indicates that one or more The 412 (Precondition Failed) status code indicates that one or more
conditions given in the request header fields evaluated to false when conditions given in the request header fields evaluated to false when
tested on the server. This response code allows the client to place tested on the server. This response code allows the client to place
preconditions on the current resource state (its current preconditions on the current resource state (its current
representations and metadata) and, thus, prevent the request method representations and metadata) and, thus, prevent the request method
from being applied if the target resource is in an unexpected state. from being applied if the target resource is in an unexpected state.
skipping to change at page 21, line 23 skipping to change at page 21, line 23
Any extension to HTTP/1.1 that defines additional conditional request Any extension to HTTP/1.1 that defines additional conditional request
header fields ought to define its own expectations regarding the header fields ought to define its own expectations regarding the
order for evaluating such fields in relation to those defined in this order for evaluating such fields in relation to those defined in this
document and other conditionals that might be found in practice. document and other conditionals that might be found in practice.
7. IANA Considerations 7. IANA Considerations
7.1. Status Code Registration 7.1. Status Code Registration
The "Hypertext Transfer Protocol (HTTP) Status Code Registry" located The "HTTP Status Codes" registry located at
at <http://www.iana.org/assignments/http-status-codes> has been <http://www.iana.org/assignments/http-status-codes> has been updated
updated with the registrations below: with the registrations below:
+-------+---------------------+-------------+ +-------+---------------------+-------------+
| Value | Description | Reference | | Value | Description | Reference |
+-------+---------------------+-------------+ +-------+---------------------+-------------+
| 304 | Not Modified | Section 4.1 | | 304 | Not Modified | Section 4.1 |
| 412 | Precondition Failed | Section 4.2 | | 412 | Precondition Failed | Section 4.2 |
+-------+---------------------+-------------+ +-------+---------------------+-------------+
7.2. Header Field Registration 7.2. Header Field Registration
HTTP header fields are registered within the "Message Headers" HTTP header fields are registered within the Message Header Field
registry maintained at Registry maintained at
<http://www.iana.org/assignments/message-headers/>. <http://www.iana.org/assignments/message-headers/>.
This document defines the following HTTP header fields, so their This document defines the following HTTP header fields, so their
associated registry entries have been updated according to the associated registry entries have been updated according to the
permanent registrations below (see [BCP90]): permanent registrations below (see [BCP90]):
+---------------------+----------+----------+-------------+ +---------------------+----------+----------+-------------+
| Header Field Name | Protocol | Status | Reference | | Header Field Name | Protocol | Status | Reference |
+---------------------+----------+----------+-------------+ +---------------------+----------+----------+-------------+
| ETag | http | standard | Section 2.3 | | ETag | http | standard | Section 2.3 |
skipping to change at page 22, line 24 skipping to change at page 22, line 24
+---------------------+----------+----------+-------------+ +---------------------+----------+----------+-------------+
The change controller is: "IETF (iesg@ietf.org) - Internet The change controller is: "IETF (iesg@ietf.org) - Internet
Engineering Task Force". Engineering Task Force".
8. Security Considerations 8. Security Considerations
This section is meant to inform developers, information providers, This section is meant to inform developers, information providers,
and users of known security concerns specific to the HTTP conditional and users of known security concerns specific to the HTTP conditional
request mechanisms. More general security considerations are request mechanisms. More general security considerations are
addressed in HTTP "Message Syntax and Routing" [RFC7230] and addressed in the HTTP messaging [RFC7230] and semantics [RFC7231]
"Semantics and Content" [RFC7231]. documents.
The validators defined by this specification are not intended to The validators defined by this specification are not intended to
ensure the validity of a representation, guard against malicious ensure the validity of a representation, guard against malicious
changes, or detect man-in-the-middle attacks. At best, they enable changes, or detect man-in-the-middle attacks. At best, they enable
more efficient cache updates and optimistic concurrent writes when more efficient cache updates and optimistic concurrent writes when
all participants are behaving nicely. At worst, the conditions will all participants are behaving nicely. At worst, the conditions will
fail and the client will receive a response that is no more harmful fail and the client will receive a response that is no more harmful
than an HTTP exchange without conditional requests. than an HTTP exchange without conditional requests.
An entity-tag can be abused in ways that create privacy risks. For An entity-tag can be abused in ways that create privacy risks. For
skipping to change at page 23, line 14 skipping to change at page 23, line 14
10.1. Normative References 10.1. Normative References
[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.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
draft-ietf-httpbis-p1-messaging-latest (work in progress), RFC 7230, May 2014.
May 2014.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
draft-ietf-httpbis-p2-semantics-latest (work in progress),
May 2014. May 2014.
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
"Hypertext Transfer Protocol (HTTP/1.1): Range Requests", "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
draft-ietf-httpbis-p5-range-latest (work in progress), RFC 7233, May 2014.
May 2014.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
draft-ietf-httpbis-p6-cache-latest (work in progress), RFC 7234, May 2014.
May 2014.
10.2. Informative References 10.2. Informative References
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004. September 2004.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[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
The definition of validator weakness has been expanded and clarified. The definition of validator weakness has been expanded and clarified
(Section 2.1) (Section 2.1).
Weak entity-tags are now allowed in all requests except range Weak entity-tags are now allowed in all requests except range
requests. (Sections 2.1 and 3.2) requests. (Sections 2.1 and 3.2.)
The ETag header field ABNF has been changed to not use quoted-string, The ETag header field ABNF has been changed to not use quoted-string,
thus avoiding escaping issues. (Section 2.3) thus avoiding escaping issues (Section 2.3).
ETag is defined to provide an entity tag for the selected ETag is defined to provide an entity tag for the selected
representation, thereby clarifying what it applies to in various representation, thereby clarifying what it applies to in various
situations (such as a PUT response). (Section 2.3) situations (such as a PUT response) (Section 2.3).
The precedence for evaluation of conditional requests has been The precedence for evaluation of conditional requests has been
defined. (Section 6) defined (Section 6).
Appendix B. Imported ABNF Appendix B. Imported ABNF
The following core rules are included by reference, as defined in The following core rules are included by reference, as defined in
Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return),
CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double
quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any
8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII
character). character).
The rules below are defined in [RFC7230]: The rules below are defined in [RFC7230]:
OWS = <OWS, see [RFC7230], Section 3.2.3> OWS = <OWS, defined in [RFC7230], Section 3.2.3>
obs-text = <obs-text, see [RFC7230], Section 3.2.6> obs-text = <obs-text, defined in [RFC7230], Section 3.2.6>
The rules below are defined in other parts: The rule below is defined in [RFC7231]:
HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1> HTTP-date = <HTTP-date, defined in [RFC7231], Section 7.1.1.1>
Appendix C. Collected ABNF Appendix C. Collected ABNF
In the collected ABNF below, list rules are expanded as per Section In the collected ABNF below, list rules are expanded as per Section
1.2 of [RFC7230]. 1.2 of [RFC7230].
ETag = entity-tag ETag = entity-tag
HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1> HTTP-date = <HTTP-date, defined in [RFC7231], Section 7.1.1.1>
If-Match = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS If-Match = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS
entity-tag ] ) ) entity-tag ] ) )
If-Modified-Since = HTTP-date If-Modified-Since = HTTP-date
If-None-Match = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS If-None-Match = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS
entity-tag ] ) ) entity-tag ] ) )
If-Unmodified-Since = HTTP-date If-Unmodified-Since = HTTP-date
Last-Modified = HTTP-date Last-Modified = HTTP-date
OWS = <OWS, see [RFC7230], Section 3.2.3> OWS = <OWS, defined in [RFC7230], Section 3.2.3>
entity-tag = [ weak ] opaque-tag entity-tag = [ weak ] opaque-tag
etagc = "!" / %x23-7E ; '#'-'~' etagc = "!" / %x23-7E ; '#'-'~'
/ obs-text / obs-text
obs-text = <obs-text, see [RFC7230], Section 3.2.6> obs-text = <obs-text, defined in [RFC7230], Section 3.2.6>
opaque-tag = DQUOTE *etagc DQUOTE opaque-tag = DQUOTE *etagc DQUOTE
weak = %x57.2F ; W/ weak = %x57.2F ; W/
Index Index
3 3
304 Not Modified (status code) 18 304 Not Modified (status code) 18
4 4
 End of changes. 33 change blocks. 
85 lines changed or deleted 65 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/