p4-conditional.unpg.txt   rfc7232.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: December 8, 2014 June 6, 2014 ISSN: 2070-1721 June 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 December 8, 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 3, line 7 skipping to change at page 3, line 7
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................4
1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4 1.1. Conformance and Error Handling .............................4
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4 1.2. Syntax Notation ............................................4
2. Validators . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Validators ......................................................5
2.1. Weak versus Strong . . . . . . . . . . . . . . . . . . . . 5 2.1. Weak versus Strong .........................................5
2.2. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Last-Modified ..............................................7
2.2.1. Generation . . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . . 10 2.3.2. Comparison .........................................10
2.3.3. Example: Entity-Tags Varying on Content-Negotiated 2.3.3. Example: Entity-Tags Varying on
Resources . . . . . . . . . . . . . . . . . . . . . . 11 Content-Negotiated Resources .......................11
2.4. When to Use Entity-Tags and Last-Modified Dates . . . . . 12 2.4. When to Use Entity-Tags and Last-Modified Dates ...........12
3. Precondition Header Fields . . . . . . . . . . . . . . . . . . 13 3. Precondition Header Fields .....................................13
3.1. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.1. If-Match ..................................................13
3.2. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 14 3.2. If-None-Match .............................................14
3.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 15 3.3. If-Modified-Since .........................................16
3.4. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 16 3.4. If-Unmodified-Since .......................................17
3.5. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.5. If-Range ..................................................18
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 . . . . . . . . . . . . . . . . . 18 4.2. 412 Precondition Failed ...................................19
5. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5. Evaluation .....................................................19
6. Precedence . . . . . . . . . . . . . . . . . . . . . . . . . . 19 6. Precedence .....................................................20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations ............................................22
7.1. Status Code Registration . . . . . . . . . . . . . . . . . 21 7.1. Status Code Registration ..................................22
7.2. Header Field Registration . . . . . . . . . . . . . . . . 21 7.2. Header Field Registration .................................22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 8. Security Considerations ........................................22
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 9. Acknowledgments ................................................23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. References ....................................................24
10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 10.1. Normative References .....................................24
10.2. Informative References . . . . . . . . . . . . . . . . . . 23 10.2. Informative References ...................................24
Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 23 Appendix A. Changes from RFC 2616 .................................25
Appendix B. Imported ABNF . . . . . . . . . . . . . . . . . . . . 24 Appendix B. Imported ABNF .........................................25
Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 24 Appendix C. Collected ABNF ........................................26
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Index .............................................................27
1. Introduction 1. Introduction
Conditional requests are HTTP requests [RFC7231] that include one or Conditional requests are HTTP requests [RFC7231] that include one or
more header fields indicating a precondition to be tested before more header fields indicating a precondition to be tested before
applying the method semantics to the target resource. This document applying the method semantics to the target resource. This document
defines the HTTP/1.1 conditional request mechanisms in terms of the defines the HTTP/1.1 conditional request mechanisms in terms of the
architecture, syntax notation, and conformance criteria defined in architecture, syntax notation, and conformance criteria defined in
[RFC7230]. [RFC7230].
Conditional GET requests are the most efficient mechanism for HTTP Conditional GET requests are the most efficient mechanism for HTTP
cache updates [RFC7234]. Conditionals can also be applied to state- cache updates [RFC7234]. Conditionals can also be applied to
changing methods, such as PUT and DELETE, to prevent the "lost state-changing methods, such as PUT and DELETE, to prevent the "lost
update" problem: one client accidentally overwriting the work of update" problem: one client accidentally overwriting the work of
another client that has been acting in parallel. another client that has been acting in parallel.
Conditional request preconditions are based on the state of the Conditional request preconditions are based on the state of the
target resource as a whole (its current value set) or the state as target resource as a whole (its current value set) or the state as
observed in a previously obtained representation (one value in that observed in a previously obtained representation (one value in that
set). A resource might have multiple current representations, each set). A resource might have multiple current representations, each
with its own observable state. The conditional request mechanisms with its own observable state. The conditional request mechanisms
assume that the mapping of requests to a "selected representation" assume that the mapping of requests to a "selected representation"
(Section 3 of [RFC7231]) will be consistent over time if the server (Section 3 of [RFC7231]) will be consistent over time if the server
skipping to change at page 8, line 24 skipping to change at page 8, line 28
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
Since, If-Unmodified-Since, or If-Range header field, because the If-Modified-Since, If-Unmodified-Since, or If-Range header field,
client has a cache entry for the associated representation, and because the client has a cache entry 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 8, line 48 skipping to change at page 9, line 8
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.
This method relies on the fact that if two different responses were This method relies on the fact that if two different responses were
sent by the origin server during the same second, but both had the sent by the origin server during the same second, but both had the
same Last-Modified time, then at least one of those responses would same Last-Modified time, then at least one of those responses would
have a Date value equal to its Last-Modified time. The arbitrary 60- have a Date value equal to its Last-Modified time. The arbitrary
second limit guards against the possibility that the Date and Last- 60-second limit guards against the possibility that the Date and
Modified values are generated from different clocks or at somewhat Last-Modified values are generated from different clocks or at
different times during the preparation of the response. An somewhat different times during the preparation of the response. An
implementation MAY use a value larger than 60 seconds, if it is implementation MAY use a value larger than 60 seconds, if it is
believed that 60 seconds is too short. believed that 60 seconds is too short.
2.3. ETag 2.3. ETag
The "ETag" header field in a response provides the current entity-tag The "ETag" header field in a response provides the current entity-tag
for the selected representation, as determined at the conclusion of for the selected representation, as determined at the conclusion of
handling the request. An entity-tag is an opaque validator for handling the request. An entity-tag is an opaque validator for
differentiating between multiple representations of the same differentiating between multiple representations of the same
resource, regardless of whether those multiple representations are resource, regardless of whether those multiple representations are
skipping to change at page 10, line 37 skipping to change at page 10, line 44
improving service scalability and reliability. improving service scalability and reliability.
2.3.2. Comparison 2.3.2. Comparison
There are two entity-tag comparison functions, depending on whether There are two entity-tag comparison functions, depending on whether
or not the comparison context allows the use of weak validators: or not the comparison context allows the use of weak validators:
o Strong comparison: two entity-tags are equivalent if both are not o Strong comparison: two entity-tags are equivalent if both are not
weak and their opaque-tags match character-by-character. weak and their opaque-tags match character-by-character.
o Weak comparison: two entity-tags are equivalent if their opaque- o Weak comparison: two entity-tags are equivalent if their
tags match character-by-character, regardless of either or both opaque-tags match character-by-character, regardless of either or
being tagged as "weak". both being tagged as "weak".
The example below shows the results for a set of entity-tag pairs and The example below shows the results for a set of entity-tag pairs and
both the weak and strong comparison function results: both the weak and strong comparison function results:
+--------+--------+-------------------+-----------------+ +--------+--------+-------------------+-----------------+
| ETag 1 | ETag 2 | Strong Comparison | Weak Comparison | | ETag 1 | ETag 2 | Strong Comparison | Weak Comparison |
+--------+--------+-------------------+-----------------+ +--------+--------+-------------------+-----------------+
| W/"1" | W/"1" | no match | match | | W/"1" | W/"1" | no match | match |
| W/"1" | W/"2" | no match | no match | | W/"1" | W/"2" | no match | no match |
| W/"1" | "1" | no match | match | | W/"1" | "1" | no match | match |
skipping to change at page 12, line 37 skipping to change at page 13, line 6
send both a strong entity-tag and a Last-Modified value in successful send both a strong entity-tag and a Last-Modified value in successful
responses to a retrieval request. responses to a retrieval request.
A client: A client:
o MUST send that entity-tag in any cache validation request (using o MUST send that entity-tag in any cache validation request (using
If-Match or If-None-Match) if an entity-tag has been provided by If-Match or If-None-Match) if an entity-tag has been provided by
the origin server. the origin server.
o SHOULD send the Last-Modified value in non-subrange cache o SHOULD send the Last-Modified value in non-subrange cache
validation requests (using If-Modified-Since) if only a Last- validation requests (using If-Modified-Since) if only a
Modified value has been provided by the origin server. Last-Modified value has been provided by the origin server.
o MAY send the Last-Modified value in subrange cache validation o MAY send the Last-Modified value in subrange cache validation
requests (using If-Unmodified-Since) if only a Last-Modified value requests (using If-Unmodified-Since) if only a Last-Modified value
has been provided by an HTTP/1.0 origin server. The user agent has been provided by an HTTP/1.0 origin server. The user agent
SHOULD provide a way to disable this, in case of difficulty. SHOULD provide a way to disable this, in case of difficulty.
o SHOULD send both validators in cache validation requests if both o SHOULD send both validators in cache validation requests if both
an entity-tag and a Last-Modified value have been provided by the an entity-tag and a Last-Modified value have been provided by the
origin server. This allows both HTTP/1.0 and HTTP/1.1 caches to origin server. This allows both HTTP/1.0 and HTTP/1.1 caches to
respond appropriately. respond appropriately.
skipping to change at page 15, line 42 skipping to change at page 16, line 21
data has not changed. data has not changed.
If-Modified-Since = HTTP-date If-Modified-Since = HTTP-date
An example of the field is: An example of the field is:
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
A recipient MUST ignore If-Modified-Since if the request contains an A recipient MUST ignore If-Modified-Since if the request contains an
If-None-Match header field; the condition in If-None-Match is If-None-Match header field; the condition in If-None-Match is
considered to be a more accurate replacement for the condition in If- considered to be a more accurate replacement for the condition in
Modified-Since, and the two are only combined for the sake of If-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
None-Match. If-None-Match.
A recipient MUST ignore the If-Modified-Since header field if the A recipient MUST ignore the If-Modified-Since header field if the
received field-value is not a valid HTTP-date, or if the request received field-value is not a valid HTTP-date, or if the request
method is neither GET nor HEAD. method is neither GET nor HEAD.
A recipient MUST interpret an If-Modified-Since field-value's A recipient MUST interpret an If-Modified-Since field-value's
timestamp in terms of the origin server's clock. timestamp in terms of the origin server's clock.
If-Modified-Since is typically used for two distinct purposes: 1) to If-Modified-Since is typically used for two distinct purposes: 1) to
allow efficient updates of a cached representation that does not have allow efficient updates of a cached representation that does not have
an entity-tag and 2) to limit the scope of a web traversal to an entity-tag and 2) to limit the scope of a web traversal to
resources that have recently changed. resources that have recently changed.
When used for cache updates, a cache will typically use the value of When used for cache updates, a cache will typically use the value of
the cached message's Last-Modified field to generate the field value the cached message's Last-Modified field to generate the field value
of If-Modified-Since. This behavior is most interoperable for cases of If-Modified-Since. This behavior is most interoperable for cases
where clocks are poorly synchronized or when the server has chosen to where clocks are poorly synchronized or when the server has chosen to
only honor exact timestamp matches (due to a problem with Last- only honor exact timestamp matches (due to a problem with
Modified dates that appear to go "back in time" when the origin Last-Modified dates that appear to go "back in time" when the origin
server's clock is corrected or a representation is restored from an server's clock is corrected or a representation is restored from an
archived backup). However, caches occasionally generate the field archived backup). However, caches occasionally generate the field
value based on other data, such as the Date header field of the value based on other data, such as the Date header field of the
cached message or the local clock time that the message was received, cached message or the local clock time that the message was received,
particularly when the cached message does not contain a Last-Modified particularly when the cached message does not contain a Last-Modified
field. field.
When used for limiting the scope of retrieval to a recent time When used for limiting the scope of retrieval to a recent time
window, a user agent will generate an If-Modified-Since field value window, a user agent will generate an If-Modified-Since field value
based on either its own local clock or a Date header field received based on either its own local clock or a Date header field received
from the server in a prior response. Origin servers that choose an from the server in a prior response. Origin servers that choose an
exact timestamp match based on the selected representation's Last- exact timestamp match based on the selected representation's
Modified field will not be able to help the user agent limit its data Last-Modified field will not be able to help the user agent limit its
transfers to only those changed during the specified window. data transfers to only those changed during the specified window.
An origin server that receives an If-Modified-Since header field An origin server that receives an If-Modified-Since header field
SHOULD evaluate the condition prior to performing the method SHOULD evaluate the condition prior to performing the method
(Section 5). The origin server SHOULD NOT perform the requested (Section 5). The origin server SHOULD NOT perform the requested
method if the selected representation's last modification date is method if the selected representation's last modification date is
earlier than or equal to the date provided in the field-value; earlier than or equal to the date provided in the field-value;
instead, the origin server SHOULD generate a 304 (Not Modified) instead, the origin server SHOULD generate a 304 (Not Modified)
response, including only those metadata that are useful for response, including only those metadata that are useful for
identifying or updating a previously cached response. identifying or updating a previously cached response.
skipping to change at page 17, line 13 skipping to change at page 17, line 41
the user agent does not have an entity-tag for the representation. the user agent does not have an entity-tag for the representation.
If-Unmodified-Since = HTTP-date If-Unmodified-Since = HTTP-date
An example of the field is: An example of the field is:
If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
A recipient MUST ignore If-Unmodified-Since if the request contains A recipient MUST ignore If-Unmodified-Since if the request contains
an If-Match header field; the condition in If-Match is considered to an If-Match header field; the condition in If-Match is considered to
be a more accurate replacement for the condition in If-Unmodified- be a more accurate replacement for the condition in
Since, and the two are only combined for the sake of interoperating If-Unmodified-Since, and the two are only combined for the sake of
with older intermediaries that might not implement If-Match. interoperating with older intermediaries that might not implement
If-Match.
A recipient MUST ignore the If-Unmodified-Since header field if the A recipient MUST ignore the If-Unmodified-Since header field if the
received field-value is not a valid HTTP-date. received field-value is not a valid HTTP-date.
A recipient MUST interpret an If-Unmodified-Since field-value's A recipient MUST interpret an If-Unmodified-Since field-value's
timestamp in terms of the origin server's clock. timestamp in terms of the origin server's clock.
If-Unmodified-Since is most often used with state-changing methods If-Unmodified-Since is most often used with state-changing methods
(e.g., POST, PUT, DELETE) to prevent accidental overwrites when (e.g., POST, PUT, DELETE) to prevent accidental overwrites when
multiple user agents might be acting in parallel on a resource that multiple user agents might be acting in parallel on a resource that
skipping to change at page 23, line 14 skipping to change at page 24, line 17
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, June 2014.
June 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),
June 2014. June 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, June 2014.
June 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, June 2014.
June 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.
skipping to change at page 25, line 32 skipping to change at page 27, line 8
/ obs-text / obs-text
obs-text = <obs-text, see [RFC7230], Section 3.2.6> obs-text = <obs-text, see [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) 19
4 4
412 Precondition Failed (status code) 18 412 Precondition Failed (status code) 18
E E
ETag header field 9 ETag header field 9
G G
Grammar Grammar
entity-tag 9 entity-tag 9
ETag 9 ETag 9
etagc 9 etagc 9
If-Match 13 If-Match 13
If-Modified-Since 15 If-Modified-Since 15
If-None-Match 14 If-None-Match 14
If-Unmodified-Since 16 If-Unmodified-Since 17
Last-Modified 7 Last-Modified 7
opaque-tag 9 opaque-tag 9
weak 9 weak 9
I I
If-Match header field 13 If-Match header field 13
If-Modified-Since header field 15 If-Modified-Since header field 16
If-None-Match header field 14 If-None-Match header field 14
If-Unmodified-Since header field 16 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
 End of changes. 24 change blocks. 
106 lines changed or deleted 87 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/