aboutsummaryrefslogtreecommitdiffstats
path: root/vendor/sabre/dav/docs/draft-ietf-httpbis-p4-conditional-11.txt
diff options
context:
space:
mode:
authorfriendica <info@friendica.com>2013-10-21 15:46:31 -0700
committerfriendica <info@friendica.com>2013-10-21 15:46:31 -0700
commitb35122f7a6ad42756c35bb60ba1f06c3dcd45c77 (patch)
treeccdf373ce6475d264778523259cc32899b732fe7 /vendor/sabre/dav/docs/draft-ietf-httpbis-p4-conditional-11.txt
parente3504df514d306cfe6b83e44a11f550664564af4 (diff)
downloadvolse-hubzilla-b35122f7a6ad42756c35bb60ba1f06c3dcd45c77.tar.gz
volse-hubzilla-b35122f7a6ad42756c35bb60ba1f06c3dcd45c77.tar.bz2
volse-hubzilla-b35122f7a6ad42756c35bb60ba1f06c3dcd45c77.zip
add sabre (1.8.x) via composer in the !@#$ place it wants to be
Diffstat (limited to 'vendor/sabre/dav/docs/draft-ietf-httpbis-p4-conditional-11.txt')
-rw-r--r--vendor/sabre/dav/docs/draft-ietf-httpbis-p4-conditional-11.txt1512
1 files changed, 1512 insertions, 0 deletions
diff --git a/vendor/sabre/dav/docs/draft-ietf-httpbis-p4-conditional-11.txt b/vendor/sabre/dav/docs/draft-ietf-httpbis-p4-conditional-11.txt
new file mode 100644
index 000000000..2dd1b7fc2
--- /dev/null
+++ b/vendor/sabre/dav/docs/draft-ietf-httpbis-p4-conditional-11.txt
@@ -0,0 +1,1512 @@
+
+
+
+HTTPbis Working Group R. Fielding, Ed.
+Internet-Draft Day Software
+Obsoletes: 2616 (if approved) J. Gettys
+Intended status: Standards Track Alcatel-Lucent
+Expires: February 5, 2011 J. Mogul
+ HP
+ H. Frystyk
+ Microsoft
+ L. Masinter
+ Adobe Systems
+ P. Leach
+ Microsoft
+ T. Berners-Lee
+ W3C/MIT
+ Y. Lafon, Ed.
+ W3C
+ J. Reschke, Ed.
+ greenbytes
+ August 4, 2010
+
+
+ HTTP/1.1, part 4: Conditional Requests
+ draft-ietf-httpbis-p4-conditional-11
+
+Abstract
+
+ The Hypertext Transfer Protocol (HTTP) is an application-level
+ protocol for distributed, collaborative, hypermedia information
+ systems. HTTP has been in use by the World Wide Web global
+ information initiative since 1990. This document is Part 4 of the
+ seven-part specification that defines the protocol referred to as
+ "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines
+ request header fields for indicating conditional requests and the
+ rules for constructing responses to those requests.
+
+Editorial Note (To be removed by RFC Editor)
+
+ Discussion of this draft should take place on the HTTPBIS working
+ group mailing list (ietf-http-wg@w3.org). 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/>.
+
+ The changes in this draft are summarized in Appendix C.12.
+
+Status of This Memo
+
+ This Internet-Draft is submitted in full conformance with the
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 1]
+
+Internet-Draft HTTP/1.1, Part 4 August 2010
+
+
+ provisions of BCP 78 and BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF). Note that other groups may also distribute
+ working documents as Internet-Drafts. The list of current Internet-
+ Drafts is at http://datatracker.ietf.org/drafts/current/.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ This Internet-Draft will expire on February 5, 2011.
+
+Copyright Notice
+
+ Copyright (c) 2010 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+ the copyright in such materials, this document may not be modified
+ outside the IETF Standards Process, and derivative works of it may
+ not be created outside the IETF Standards Process, except to format
+ it for publication as an RFC or to translate it into languages other
+ than English.
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 2]
+
+Internet-Draft HTTP/1.1, Part 4 August 2010
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4
+ 1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 5
+ 1.2.2. ABNF Rules defined in other Parts of the
+ Specification . . . . . . . . . . . . . . . . . . . . 5
+ 2. Entity-Tags . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 2.1. Example: Entity-tags varying on Content-Negotiated
+ Resources . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 7
+ 3.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 7
+ 3.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 7
+ 4. Weak and Strong Validators . . . . . . . . . . . . . . . . . . 8
+ 5. Rules for When to Use Entity-tags and Last-Modified Dates . . 10
+ 6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 12
+ 6.1. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 6.2. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 6.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 14
+ 6.4. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 16
+ 6.5. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 17
+ 6.6. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 18
+ 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
+ 7.1. Status Code Registration . . . . . . . . . . . . . . . . . 19
+ 7.2. Header Field Registration . . . . . . . . . . . . . . . . 19
+ 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
+ 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
+ 10.2. Informative References . . . . . . . . . . . . . . . . . . 20
+ Appendix A. Changes from RFC 2616 . . . . . . . . . . . . . . . . 20
+ Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 21
+ Appendix C. Change Log (to be removed by RFC Editor before
+ publication) . . . . . . . . . . . . . . . . . . . . 21
+ C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 21
+ C.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 22
+ C.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 22
+ C.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 22
+ C.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 22
+ C.6. Since draft-ietf-httpbis-p4-conditional-04 . . . . . . . . 23
+ C.7. Since draft-ietf-httpbis-p4-conditional-05 . . . . . . . . 23
+ C.8. Since draft-ietf-httpbis-p4-conditional-06 . . . . . . . . 23
+ C.9. Since draft-ietf-httpbis-p4-conditional-07 . . . . . . . . 23
+ C.10. Since draft-ietf-httpbis-p4-conditional-08 . . . . . . . . 23
+ C.11. Since draft-ietf-httpbis-p4-conditional-09 . . . . . . . . 23
+ C.12. Since draft-ietf-httpbis-p4-conditional-10 . . . . . . . . 24
+ Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 3]
+
+Internet-Draft HTTP/1.1, Part 4 August 2010
+
+
+1. Introduction
+
+ This document defines HTTP/1.1 response metadata for indicating
+ potential changes to payload content, including modification time
+ stamps and opaque entity-tags, and the HTTP conditional request
+ mechanisms that allow preconditions to be placed on a request method.
+ Conditional GET requests allow for efficient cache updates. Other
+ conditional request methods are used to protect against overwriting
+ or misunderstanding the state of a resource that has been changed
+ unbeknownst to the requesting client.
+
+ This document is currently disorganized in order to minimize the
+ changes between drafts and enable reviewers to see the smaller errata
+ changes. The next draft will reorganize the sections to better
+ reflect the content. In particular, the sections on resource
+ metadata will be discussed first and then followed by each
+ conditional request-header, concluding with a definition of
+ precedence and the expectation of ordering strong validator checks
+ before weak validator checks. It is likely that more content from
+ [Part6] will migrate to this part, where appropriate. The current
+ mess reflects how widely dispersed these topics and associated
+ requirements had become in [RFC2616].
+
+1.1. Requirements
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+ An implementation is not compliant if it fails to satisfy one or more
+ of the "MUST" or "REQUIRED" level requirements for the protocols it
+ implements. An implementation that satisfies all the "MUST" or
+ "REQUIRED" level and all the "SHOULD" level requirements for its
+ protocols is said to be "unconditionally compliant"; one that
+ satisfies all the "MUST" level requirements but not all the "SHOULD"
+ level requirements for its protocols is said to be "conditionally
+ compliant".
+
+1.2. Syntax Notation
+
+ This specification uses the ABNF syntax defined in Section 1.2 of
+ [Part1] (which extends the syntax defined in [RFC5234] with a list
+ rule). Appendix B shows the collected ABNF, with the list rule
+ expanded.
+
+ The following core rules are included by reference, as defined in
+ [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
+ (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 4]
+
+Internet-Draft HTTP/1.1, Part 4 August 2010
+
+
+ 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),
+ and WSP (whitespace).
+
+1.2.1. Core Rules
+
+ The core rules below are defined in Section 1.2.2 of [Part1]:
+
+ quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>
+ OWS = <OWS, defined in [Part1], Section 1.2.2>
+
+1.2.2. ABNF Rules defined in other Parts of the Specification
+
+ The ABNF rules below are defined in other parts:
+
+ HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>
+
+2. Entity-Tags
+
+ Entity-tags are used for comparing two or more representations of the
+ same resource. HTTP/1.1 uses entity-tags in the ETag (Section 6.1),
+ If-Match (Section 6.2), If-None-Match (Section 6.4), and If-Range
+ (Section 5.3 of [Part5]) header fields. The definition of how they
+ are used and compared as cache validators is in Section 4. An
+ entity-tag consists of an opaque quoted string, possibly prefixed by
+ a weakness indicator.
+
+ entity-tag = [ weak ] opaque-tag
+ weak = %x57.2F ; "W/", case-sensitive
+ opaque-tag = quoted-string
+
+ A "strong entity-tag" MAY be shared by two representations of a
+ resource only if they are equivalent by octet equality.
+
+ A "weak entity-tag", indicated by the "W/" prefix, MAY be shared by
+ two representations of a resource only if the representations are
+ equivalent and could be substituted for each other with no
+ significant change in semantics. A weak entity-tag can only be used
+ for weak comparison.
+
+ An entity-tag MUST be unique across all versions of all
+ representations associated with a particular resource. A given
+ entity-tag value MAY be used for representations obtained by requests
+ on different URIs. The use of the same entity-tag value in
+ conjunction with representations obtained by requests on different
+ URIs does not imply the equivalence of those representations.
+
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 5]
+
+Internet-Draft HTTP/1.1, Part 4 August 2010
+
+
+2.1. Example: Entity-tags varying on Content-Negotiated Resources
+
+ Consider a resource that is subject to content negotiation (Section 5
+ of [Part3]), and where the representations returned upon a GET
+ request vary based on the Accept-Encoding request header field
+ (Section 6.3 of [Part3]):
+
+ >> Request:
+
+ GET /index HTTP/1.1
+ Host: www.example.com
+ Accept-Encoding: gzip
+
+
+ In this case, the response might or might not use the gzip content
+ coding. If it does not, the response might look like:
+
+ >> Response:
+
+ HTTP/1.1 200 OK
+ Date: Thu, 26 Mar 2010 00:05:00 GMT
+ ETag: "123-a"
+ Content-Length: 70
+ Vary: Accept-Encoding
+ Content-Type: text/plain
+
+ Hello World!
+ Hello World!
+ Hello World!
+ Hello World!
+ Hello World!
+
+ An alternative representation that does use gzip content coding would
+ be:
+
+ >> Response:
+
+ HTTP/1.1 200 OK
+ Date: Thu, 26 Mar 2010 00:05:00 GMT
+ ETag: "123-b"
+ Content-Length: 43
+ Vary: Accept-Encoding
+ Content-Type: text/plain
+ Content-Encoding: gzip
+
+ ...binary data...
+
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 6]
+
+Internet-Draft HTTP/1.1, Part 4 August 2010
+
+
+ Note: Content codings are a property of the representation, so
+ therefore an entity-tag of an encoded representation must be
+ distinct from an unencoded representation to prevent conflicts
+ during cache updates and range requests. In contrast, transfer
+ codings (Section 6.2 of [Part1]) apply only during message
+ transfer and do not require distinct entity-tags.
+
+3. Status Code Definitions
+
+3.1. 304 Not Modified
+
+ If the client has performed a conditional GET request and access is
+ allowed, but the document has not been modified, the server SHOULD
+ respond with this status code. The 304 response MUST NOT contain a
+ message-body, and thus 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
+ [Part1]) unless its omission is required by Section 9.3.1 of [Part1].
+ If a 200 response to the same request would have included any of the
+ header fields Cache-Control, Content-Location, ETag, Expires, Last-
+ Modified, 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
+ when the recipient already has one or more cached representations,
+ the response SHOULD NOT include representation metadata other than
+ the above listed fields unless said metadata exists for the purpose
+ of guiding cache updates (e.g., future HTTP extensions).
+
+ If a 304 response includes an entity-tag that indicates a
+ representation not currently cached, then the recipient MUST NOT use
+ the 304 to update its own cache. If that conditional request
+ originated with an outbound client, such as a user agent with its own
+ cache sending a conditional GET to a shared proxy, then the 304
+ response MAY be forwarded to the outbound client. Otherwise,
+ disregard the response and repeat the request without the
+ conditional.
+
+ If a cache uses a received 304 response to update a cache entry, the
+ cache MUST update the entry to reflect any new field values given in
+ the response.
+
+3.2. 412 Precondition Failed
+
+ The precondition given in one or more of the request-header fields
+ evaluated to false when it was tested on the server. This response
+ code allows the client to place preconditions on the current resource
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 7]
+
+Internet-Draft HTTP/1.1, Part 4 August 2010
+
+
+ metadata (header field data) and thus prevent the requested method
+ from being applied to a resource other than the one intended.
+
+4. Weak and Strong Validators
+
+ Since both origin servers and caches will compare two validators to
+ decide if they represent the same or different representations, one
+ normally would expect that if the representation (including both
+ representation header fields and representation body) changes in any
+ way, then the associated validator would change as well. If this is
+ true, then we call this validator a "strong validator".
+
+ However, there might be cases when a server prefers to change the
+ validator only on semantically significant changes, and not when
+ insignificant aspects of the representation change. A validator that
+ does not always change when the representation changes is a "weak
+ validator".
+
+ An entity-tag is normally a strong validator, but the protocol
+ provides a mechanism to tag an entity-tag as "weak". One can think
+ of a strong validator as one that changes whenever the sequence of
+ bits in a representation changes, while a weak value changes whenever
+ the meaning of a representation changes. Alternatively, one can
+ think of a strong validator as part of an identifier for a specific
+ representation, whereas a weak validator is part of an identifier for
+ a set of semantically equivalent representations.
+
+ Note: One example of a strong validator is an integer that is
+ incremented in stable storage every time a representation is
+ changed.
+
+ A representation's modification time, if defined with only one-
+ second resolution, could be a weak validator, since it is possible
+ that the representation might be modified twice during a single
+ second.
+
+ Support for weak validators is optional. However, weak validators
+ allow for more efficient caching of equivalent objects; for
+ example, a hit counter on a site is probably good enough if it is
+ updated every few days or weeks, and any value during that period
+ is likely "good enough" to be equivalent.
+
+ A "use" of a validator is either when a client generates a request
+ and includes the validator in a validating header field, or when a
+ server compares two validators.
+
+ Strong validators are usable in any context. Weak validators are
+ only usable in contexts that do not depend on exact equality of a
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 8]
+
+Internet-Draft HTTP/1.1, Part 4 August 2010
+
+
+ representation. For example, either kind is usable for a normal
+ conditional GET. However, only a strong validator is usable for a
+ sub-range retrieval, since otherwise the client might end up with an
+ internally inconsistent representation.
+
+ Clients MUST NOT use weak validators in range requests ([Part5]).
+
+ The only function that HTTP/1.1 defines on validators is comparison.
+ There are two validator comparison functions, depending on whether
+ the comparison context allows the use of weak validators or not:
+
+ o The strong comparison function: in order to be considered equal,
+ both opaque-tags MUST be identical character-by-character, and
+ both MUST NOT be weak.
+
+ o The weak comparison function: in order to be considered equal,
+ both opaque-tags MUST be identical character-by-character, but
+ either or both of them MAY be tagged as "weak" without affecting
+ the result.
+
+ The example below shows the results for a set of entity-tag pairs,
+ and both the weak and strong comparison function results:
+
+ +--------+--------+-------------------+-----------------+
+ | ETag 1 | ETag 2 | Strong Comparison | Weak Comparison |
+ +--------+--------+-------------------+-----------------+
+ | W/"1" | W/"1" | no match | match |
+ | W/"1" | W/"2" | no match | no match |
+ | W/"1" | "1" | no match | match |
+ | "1" | "1" | match | match |
+ +--------+--------+-------------------+-----------------+
+
+ An entity-tag is strong unless it is explicitly tagged as weak.
+ Section 2 gives the syntax for entity-tags.
+
+ 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,
+ using the following rules:
+
+ o The validator is being compared by an origin server to the actual
+ current validator for the representation and,
+
+ o That origin server reliably knows that the associated
+ representation did not change twice during the second covered by
+ the presented validator.
+
+ or
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 9]
+
+Internet-Draft HTTP/1.1, Part 4 August 2010
+
+
+ o The validator is about to be used by a client in an If-Modified-
+ Since or If-Unmodified-Since header, 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
+ the origin server sent the original response, and
+
+ o The presented Last-Modified time is at least 60 seconds before the
+ Date value.
+
+ or
+
+ o The validator is being compared by an intermediate cache to the
+ validator stored in its cache entry for the representation, and
+
+ o That cache entry includes a Date value, which gives the time when
+ the origin server sent the original response, and
+
+ o The presented Last-Modified time is at least 60 seconds before the
+ Date value.
+
+ 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
+ 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-
+ second limit guards against the possibility that the Date and Last-
+ Modified values are generated from different clocks, or at somewhat
+ different times during the preparation of the response. An
+ implementation MAY use a value larger than 60 seconds, if it is
+ believed that 60 seconds is too short.
+
+ If a client wishes to perform a sub-range retrieval on a value for
+ which it has only a Last-Modified time and no opaque validator, it
+ MAY do this only if the Last-Modified time is strong in the sense
+ described here.
+
+ A cache or origin server receiving a conditional range request
+ ([Part5]) MUST use the strong comparison function to evaluate the
+ condition.
+
+ These rules allow HTTP/1.1 caches and clients to safely perform sub-
+ range retrievals on values that have been obtained from HTTP/1.0
+ servers.
+
+5. Rules for When to Use Entity-tags and Last-Modified Dates
+
+ We adopt a set of rules and recommendations for origin servers,
+ clients, and caches regarding when various validator types ought to
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 10]
+
+Internet-Draft HTTP/1.1, Part 4 August 2010
+
+
+ be used, and for what purposes.
+
+ HTTP/1.1 origin servers:
+
+ o SHOULD send an entity-tag validator unless it is not feasible to
+ generate one.
+
+ o MAY send a weak entity-tag instead of a strong entity-tag, if
+ performance considerations support the use of weak entity-tags, or
+ if it is unfeasible to send a strong entity-tag.
+
+ o SHOULD send a Last-Modified value if it is feasible to send one,
+ unless the risk of a breakdown in semantic transparency that could
+ result from using this date in an If-Modified-Since header would
+ lead to serious problems.
+
+ In other words, the preferred behavior for an HTTP/1.1 origin server
+ is to send both a strong entity-tag and a Last-Modified value.
+
+ In order to be legal, a strong entity-tag MUST change whenever the
+ associated representation changes in any way. A weak entity-tag
+ SHOULD change whenever the associated representation changes in a
+ semantically significant way.
+
+ Note: In order to provide semantically transparent caching, an
+ origin server must avoid reusing a specific strong entity-tag
+ value for two different representations, or reusing a specific
+ weak entity-tag value for two semantically different
+ representations. Cache entries might persist for arbitrarily long
+ periods, regardless of expiration times, so it might be
+ inappropriate to expect that a cache will never again attempt to
+ validate an entry using a validator that it obtained at some point
+ in the past.
+
+ HTTP/1.1 clients:
+
+ o MUST use that entity-tag in any cache-conditional request (using
+ If-Match or If-None-Match) if an entity-tag has been provided by
+ the origin server.
+
+ o SHOULD use the Last-Modified value in non-subrange cache-
+ conditional requests (using If-Modified-Since) if only a Last-
+ Modified value has been provided by the origin server.
+
+ o MAY use the Last-Modified value in subrange cache-conditional
+ requests (using If-Unmodified-Since) if only a Last-Modified value
+ has been provided by an HTTP/1.0 origin server. The user agent
+ SHOULD provide a way to disable this, in case of difficulty.
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 11]
+
+Internet-Draft HTTP/1.1, Part 4 August 2010
+
+
+ o SHOULD use both validators in cache-conditional requests if both
+ 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
+ respond appropriately.
+
+ An HTTP/1.1 origin server, upon receiving a conditional request that
+ includes both a Last-Modified date (e.g., in an If-Modified-Since or
+ If-Unmodified-Since header field) and one or more entity-tags (e.g.,
+ in an If-Match, If-None-Match, or If-Range header field) as cache
+ validators, MUST NOT return a response status code of 304 (Not
+ Modified) unless doing so is consistent with all of the conditional
+ header fields in the request.
+
+ An HTTP/1.1 caching proxy, upon receiving a conditional request that
+ includes both a Last-Modified date and one or more entity-tags as
+ cache validators, MUST NOT return a locally cached response to the
+ client unless that cached response is consistent with all of the
+ conditional header fields in the request.
+
+ Note: The general principle behind these rules is that HTTP/1.1
+ servers and clients ought to transmit as much non-redundant
+ information as is available in their responses and requests.
+ HTTP/1.1 systems receiving this information will make the most
+ conservative assumptions about the validators they receive.
+
+ HTTP/1.0 clients and caches will ignore entity-tags. Generally,
+ last-modified values received or used by these systems will
+ support transparent and efficient caching, and so HTTP/1.1 origin
+ servers should provide Last-Modified values. In those rare cases
+ where the use of a Last-Modified value as a validator by an
+ HTTP/1.0 system could result in a serious problem, then HTTP/1.1
+ origin servers should not provide one.
+
+6. Header Field Definitions
+
+ This section defines the syntax and semantics of HTTP/1.1 header
+ fields related to conditional requests.
+
+6.1. ETag
+
+ The "ETag" response-header field provides the current value of the
+ entity-tag (see Section 2) for one representation of the target
+ resource. An entity-tag is intended for use as a resource-local
+ identifier for differentiating between representations of the same
+ resource that vary over time or via content negotiation (see
+ Section 4).
+
+ ETag = "ETag" ":" OWS ETag-v
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 12]
+
+Internet-Draft HTTP/1.1, Part 4 August 2010
+
+
+ ETag-v = entity-tag
+
+ Examples:
+
+ ETag: "xyzzy"
+ ETag: W/"xyzzy"
+ ETag: ""
+
+ An entity-tag provides an "opaque" cache validator that allows for
+ more reliable validation than modification dates in situations where
+ it is inconvenient to store modification dates, where the one-second
+ resolution of HTTP date values is not sufficient, or where the origin
+ server wishes to avoid certain paradoxes that might arise from the
+ use of modification dates.
+
+ The principle behind entity-tags is that only the service author
+ knows the semantics of a resource well enough to select an
+ appropriate cache validation mechanism, and the specification of any
+ validator comparison function more complex than byte-equality would
+ open up a can of worms. Thus, comparisons of any other headers
+ (except Last-Modified, for compatibility with HTTP/1.0) are never
+ used for purposes of validating a cache entry.
+
+6.2. If-Match
+
+ The "If-Match" request-header field is used to make a request method
+ conditional. A client that has one or more representations
+ previously obtained from the resource can verify that one of those
+ representations is current by including a list of their associated
+ entity-tags in the If-Match header field.
+
+ This allows efficient updates of cached information with a minimum
+ amount of transaction overhead. It is also used when updating
+ resources, to prevent inadvertent modification of the wrong version
+ of a resource. As a special case, the value "*" matches any current
+ representation of the resource.
+
+ If-Match = "If-Match" ":" OWS If-Match-v
+ If-Match-v = "*" / 1#entity-tag
+
+ If any of the entity-tags match the entity-tag of the representation
+ that would have been returned in the response to a similar GET
+ request (without the If-Match header) on that resource, or if "*" is
+ given and any current representation exists for that resource, then
+ the server MAY perform the requested method as if the If-Match header
+ field did not exist.
+
+ If none of the entity-tags match, or if "*" is given and no current
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 13]
+
+Internet-Draft HTTP/1.1, Part 4 August 2010
+
+
+ representation exists, the server MUST NOT perform the requested
+ method, and MUST return a 412 (Precondition Failed) response. This
+ behavior is most useful when the client wants to prevent an updating
+ method, such as PUT, from modifying a resource that has changed since
+ the client last retrieved it.
+
+ If the request would, without the If-Match header field, result in
+ anything other than a 2xx or 412 status code, then the If-Match
+ header MUST be ignored.
+
+ The meaning of "If-Match: *" is that the method SHOULD be performed
+ if the representation selected by the origin server (or by a cache,
+ possibly using the Vary mechanism, see Section 3.5 of [Part6])
+ exists, and MUST NOT be performed if the representation does not
+ exist.
+
+ A request intended to update a resource (e.g., a PUT) MAY include an
+ If-Match header field to signal that the request method MUST NOT be
+ applied if the representation corresponding to the If-Match value (a
+ single entity-tag) is no longer a representation of that resource.
+ This allows the user to indicate that they do not wish the request to
+ be successful if the resource has been changed without their
+ knowledge. Examples:
+
+ If-Match: "xyzzy"
+ If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
+ If-Match: *
+
+ The result of a request having both an If-Match header field and
+ either an If-None-Match or an If-Modified-Since header fields is
+ undefined by this specification.
+
+6.3. If-Modified-Since
+
+ The "If-Modified-Since" request-header field is used to make a
+ request method conditional by date: if the representation that would
+ have been transferred in a 200 response to a GET request has not been
+ modified since the time specified in this field, then do not perform
+ the method; instead, respond as detailed below.
+
+ If-Modified-Since = "If-Modified-Since" ":" OWS
+ If-Modified-Since-v
+ If-Modified-Since-v = HTTP-date
+
+ An example of the field is:
+
+ If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 14]
+
+Internet-Draft HTTP/1.1, Part 4 August 2010
+
+
+ A GET method with an If-Modified-Since header and no Range header
+ requests that the representation be transferred only if it has been
+ modified since the date given by the If-Modified-Since header. The
+ algorithm for determining this includes the following cases:
+
+ 1. If the request would normally result in anything other than a 200
+ (OK) status code, or if the passed If-Modified-Since date is
+ invalid, the response is exactly the same as for a normal GET. A
+ date which is later than the server's current time is invalid.
+
+ 2. If the representation has been modified since the If-Modified-
+ Since date, the response is exactly the same as for a normal GET.
+
+ 3. If the representation has not been modified since a valid If-
+ Modified-Since date, the server SHOULD return a 304 (Not
+ Modified) response.
+
+ The purpose of this feature is to allow efficient updates of cached
+ information with a minimum amount of transaction overhead.
+
+ Note: The Range request-header field modifies the meaning of If-
+ Modified-Since; see Section 5.4 of [Part5] for full details.
+
+ Note: If-Modified-Since times are interpreted by the server, whose
+ clock might not be synchronized with the client.
+
+ Note: When handling an If-Modified-Since header field, some
+ servers will use an exact date comparison function, rather than a
+ less-than function, for deciding whether to send a 304 (Not
+ Modified) response. To get best results when sending an If-
+ Modified-Since header field for cache validation, clients are
+ advised to use the exact date string received in a previous Last-
+ Modified header field whenever possible.
+
+ Note: If a client uses an arbitrary date in the If-Modified-Since
+ header instead of a date taken from the Last-Modified header for
+ the same request, the client needs to be aware that this date is
+ interpreted in the server's understanding of time. Unsynchronized
+ clocks and rounding problems, due to the different encodings of
+ time between the client and server, are concerns. This includes
+ the possibility of race conditions if the document has changed
+ between the time it was first requested and the If-Modified-Since
+ date of a subsequent request, and the possibility of clock-skew-
+ related problems if the If-Modified-Since date is derived from the
+ client's clock without correction to the server's clock.
+ Corrections for different time bases between client and server are
+ at best approximate due to network latency.
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 15]
+
+Internet-Draft HTTP/1.1, Part 4 August 2010
+
+
+ The result of a request having both an If-Modified-Since header field
+ and either an If-Match or an If-Unmodified-Since header fields is
+ undefined by this specification.
+
+6.4. If-None-Match
+
+ The "If-None-Match" request-header field is used to make a request
+ method conditional. A client that has one or more representations
+ previously obtained from the resource can verify that none of those
+ representations is current by including a list of their associated
+ entity-tags in the If-None-Match header field.
+
+ This allows efficient updates of cached information with a minimum
+ amount of transaction overhead. It is also used to prevent a method
+ (e.g., PUT) from inadvertently modifying an existing resource when
+ the client believes that the resource does not exist.
+
+ As a special case, the value "*" matches any current representation
+ of the resource.
+
+ If-None-Match = "If-None-Match" ":" OWS If-None-Match-v
+ If-None-Match-v = "*" / 1#entity-tag
+
+ If any of the entity-tags match the entity-tag of the representation
+ that would have been returned in the response to a similar GET
+ request (without the If-None-Match header) on that resource, or if
+ "*" is given and any current representation exists for that resource,
+ then the server MUST NOT perform the requested method, unless
+ required to do so because the resource's modification date fails to
+ match that supplied in an If-Modified-Since header field in the
+ request. Instead, if the request method was GET or HEAD, the server
+ SHOULD respond with a 304 (Not Modified) response, including the
+ cache-related header fields (particularly ETag) of one of the
+ representations that matched. For all other request methods, the
+ server MUST respond with a 412 (Precondition Failed) status code.
+
+ If none of the entity-tags match, then the server MAY perform the
+ requested method as if the If-None-Match header field did not exist,
+ but MUST also ignore any If-Modified-Since header field(s) in the
+ request. That is, if no entity-tags match, then the server MUST NOT
+ return a 304 (Not Modified) response.
+
+ If the request would, without the If-None-Match header field, result
+ in anything other than a 2xx or 304 status code, then the If-None-
+ Match header MUST be ignored. (See Section 5 for a discussion of
+ server behavior when both If-Modified-Since and If-None-Match appear
+ in the same request.)
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 16]
+
+Internet-Draft HTTP/1.1, Part 4 August 2010
+
+
+ The meaning of "If-None-Match: *" is that the method MUST NOT be
+ performed if the representation selected by the origin server (or by
+ a cache, possibly using the Vary mechanism, see Section 3.5 of
+ [Part6]) exists, and SHOULD be performed if the representation does
+ not exist. This feature is intended to be useful in preventing races
+ between PUT operations.
+
+ Examples:
+
+ If-None-Match: "xyzzy"
+ If-None-Match: W/"xyzzy"
+ If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
+ If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
+ If-None-Match: *
+
+ The result of a request having both an If-None-Match header field and
+ either an If-Match or an If-Unmodified-Since header fields is
+ undefined by this specification.
+
+6.5. If-Unmodified-Since
+
+ The "If-Unmodified-Since" request-header field is used to make a
+ request method conditional. If the representation that would have
+ been transferred in a 200 response to a GET request on the same
+ resource has not been modified since the time specified in this
+ field, the server SHOULD perform the requested operation as if the
+ If-Unmodified-Since header were not present.
+
+ If the representation has been modified since the specified time, the
+ server MUST NOT perform the requested operation, and MUST return a
+ 412 (Precondition Failed).
+
+ If-Unmodified-Since = "If-Unmodified-Since" ":" OWS
+ If-Unmodified-Since-v
+ If-Unmodified-Since-v = HTTP-date
+
+ An example of the field is:
+
+ If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
+
+ If the request normally (i.e., without the If-Unmodified-Since
+ header) would result in anything other than a 2xx or 412 status code,
+ the If-Unmodified-Since header SHOULD be ignored.
+
+ If the specified date is invalid, the header is ignored.
+
+ The result of a request having both an If-Unmodified-Since header
+ field and either an If-None-Match or an If-Modified-Since header
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 17]
+
+Internet-Draft HTTP/1.1, Part 4 August 2010
+
+
+ fields is undefined by this specification.
+
+6.6. Last-Modified
+
+ The "Last-Modified" header field indicates the date and time at which
+ the origin server believes the representation was last modified.
+
+ Last-Modified = "Last-Modified" ":" OWS Last-Modified-v
+ Last-Modified-v = HTTP-date
+
+ An example of its use is
+
+ Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
+
+ The exact meaning of this header field depends on the implementation
+ of the origin server and the nature of the original resource. For
+ files, it might be just the file system last-modified time. For
+ representations with dynamically included parts, it might be the most
+ recent of the set of last-modify times for its component parts. For
+ database gateways, it might be the last-update time stamp of the
+ record. For virtual objects, it might be the last time the internal
+ state changed.
+
+ An origin server MUST NOT send a Last-Modified date which is later
+ than the server's time of message origination. In such cases, where
+ the resource's last modification would indicate some time in the
+ future, the server MUST replace that date with the message
+ origination date.
+
+ An origin server SHOULD obtain the Last-Modified value of the
+ representation as close as possible to the time that it generates the
+ Date value of its response. This allows a recipient to make an
+ accurate assessment of the representation's modification time,
+ especially if the representation changes near the time that the
+ response is generated.
+
+ HTTP/1.1 servers SHOULD send Last-Modified whenever feasible.
+
+ The Last-Modified header field value is often used as a cache
+ validator. In simple terms, a cache entry is considered to be valid
+ if the representation has not been modified since the Last-Modified
+ value.
+
+7. IANA Considerations
+
+
+
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 18]
+
+Internet-Draft HTTP/1.1, Part 4 August 2010
+
+
+7.1. Status Code Registration
+
+ The HTTP Status Code Registry located at
+ <http://www.iana.org/assignments/http-status-codes> shall be updated
+ with the registrations below:
+
+ +-------+---------------------+-------------+
+ | Value | Description | Reference |
+ +-------+---------------------+-------------+
+ | 304 | Not Modified | Section 3.1 |
+ | 412 | Precondition Failed | Section 3.2 |
+ +-------+---------------------+-------------+
+
+7.2. Header Field Registration
+
+ The Message Header Field Registry located at <http://www.iana.org/
+ assignments/message-headers/message-header-index.html> shall be
+ updated with the permanent registrations below (see [RFC3864]):
+
+ +---------------------+----------+----------+-------------+
+ | Header Field Name | Protocol | Status | Reference |
+ +---------------------+----------+----------+-------------+
+ | ETag | http | standard | Section 6.1 |
+ | If-Match | http | standard | Section 6.2 |
+ | If-Modified-Since | http | standard | Section 6.3 |
+ | If-None-Match | http | standard | Section 6.4 |
+ | If-Unmodified-Since | http | standard | Section 6.5 |
+ | Last-Modified | http | standard | Section 6.6 |
+ +---------------------+----------+----------+-------------+
+
+ The change controller is: "IETF (iesg@ietf.org) - Internet
+ Engineering Task Force".
+
+8. Security Considerations
+
+ No additional security considerations have been identified beyond
+ those applicable to HTTP in general [Part1].
+
+9. Acknowledgments
+
+10. References
+
+10.1. Normative References
+
+ [Part1] 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 1: URIs, Connections,
+ and Message Parsing", draft-ietf-httpbis-p1-messaging-11
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 19]
+
+Internet-Draft HTTP/1.1, Part 4 August 2010
+
+
+ (work in progress), August 2010.
+
+ [Part3] 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 3: Message Payload
+ and Content Negotiation", draft-ietf-httpbis-p3-payload-11
+ (work in progress), August 2010.
+
+ [Part5] 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 5: Range Requests and
+ Partial Responses", draft-ietf-httpbis-p5-range-11 (work
+ in progress), August 2010.
+
+ [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
+ Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
+ Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part
+ 6: Caching", draft-ietf-httpbis-p6-cache-11 (work in
+ progress), August 2010.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", STD 68, RFC 5234, January 2008.
+
+10.2. Informative References
+
+ [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+ Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
+ Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
+
+ [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
+ Procedures for Message Header Fields", BCP 90, RFC 3864,
+ September 2004.
+
+Appendix A. Changes from RFC 2616
+
+ Allow weak entity-tags in all requests except range requests
+ (Sections 4 and 6.4).
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 20]
+
+Internet-Draft HTTP/1.1, Part 4 August 2010
+
+
+Appendix B. Collected ABNF
+
+ ETag = "ETag:" OWS ETag-v
+ ETag-v = entity-tag
+
+ HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>
+
+ If-Match = "If-Match:" OWS If-Match-v
+ If-Match-v = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS
+ entity-tag ] ) )
+ If-Modified-Since = "If-Modified-Since:" OWS If-Modified-Since-v
+ If-Modified-Since-v = HTTP-date
+ If-None-Match = "If-None-Match:" OWS If-None-Match-v
+ If-None-Match-v = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS
+ entity-tag ] ) )
+ If-Unmodified-Since = "If-Unmodified-Since:" OWS
+ If-Unmodified-Since-v
+ If-Unmodified-Since-v = HTTP-date
+
+ Last-Modified = "Last-Modified:" OWS Last-Modified-v
+ Last-Modified-v = HTTP-date
+
+ OWS = <OWS, defined in [Part1], Section 1.2.2>
+
+ entity-tag = [ weak ] opaque-tag
+
+ opaque-tag = quoted-string
+
+ quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>
+
+ weak = %x57.2F ; W/
+
+ ABNF diagnostics:
+
+ ; ETag defined but not used
+ ; If-Match defined but not used
+ ; If-Modified-Since defined but not used
+ ; If-None-Match defined but not used
+ ; If-Unmodified-Since defined but not used
+ ; Last-Modified defined but not used
+
+Appendix C. Change Log (to be removed by RFC Editor before publication)
+
+C.1. Since RFC2616
+
+ Extracted relevant partitions from [RFC2616].
+
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 21]
+
+Internet-Draft HTTP/1.1, Part 4 August 2010
+
+
+C.2. Since draft-ietf-httpbis-p4-conditional-00
+
+ Closed issues:
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
+ Informative references"
+
+ Other changes:
+
+ o Move definitions of 304 and 412 condition codes from Part2.
+
+C.3. Since draft-ietf-httpbis-p4-conditional-01
+
+ Ongoing work on ABNF conversion
+ (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
+
+ o Add explicit references to BNF syntax and rules imported from
+ other parts of the specification.
+
+C.4. Since draft-ietf-httpbis-p4-conditional-02
+
+ Closed issues:
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/116>: "Weak ETags on
+ non-GET requests"
+
+ Ongoing work on IANA Message Header Registration
+ (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
+
+ o Reference RFC 3984, and update header registrations for headers
+ defined in this document.
+
+C.5. Since draft-ietf-httpbis-p4-conditional-03
+
+ Closed issues:
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/71>: "Examples for
+ ETag matching"
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/124>: "'entity
+ value' undefined"
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/126>: "bogus 2068
+ Date header reference"
+
+
+
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 22]
+
+Internet-Draft HTTP/1.1, Part 4 August 2010
+
+
+C.6. Since draft-ietf-httpbis-p4-conditional-04
+
+ Ongoing work on ABNF conversion
+ (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
+
+ o Use "/" instead of "|" for alternatives.
+
+ o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
+ whitespace ("OWS") and required whitespace ("RWS").
+
+ o Rewrite ABNFs to spell out whitespace rules, factor out header
+ value format definitions.
+
+C.7. Since draft-ietf-httpbis-p4-conditional-05
+
+ Final work on ABNF conversion
+ (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
+
+ o Add appendix containing collected and expanded ABNF, reorganize
+ ABNF introduction.
+
+C.8. Since draft-ietf-httpbis-p4-conditional-06
+
+ Closed issues:
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/153>: "case-
+ sensitivity of etag weakness indicator"
+
+C.9. Since draft-ietf-httpbis-p4-conditional-07
+
+ Closed issues:
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/116>: "Weak ETags on
+ non-GET requests" (If-Match still was defined to require strong
+ matching)
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA
+ registrations for optional status codes"
+
+C.10. Since draft-ietf-httpbis-p4-conditional-08
+
+ No significant changes.
+
+C.11. Since draft-ietf-httpbis-p4-conditional-09
+
+ No significant changes.
+
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 23]
+
+Internet-Draft HTTP/1.1, Part 4 August 2010
+
+
+C.12. Since draft-ietf-httpbis-p4-conditional-10
+
+ Closed issues:
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/69>: "Clarify
+ 'Requested Variant'"
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify
+ entity / representation / variant terminology"
+
+ o <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider
+ removing the 'changes from 2068' sections"
+
+Index
+
+ 3
+ 304 Not Modified (status code) 7
+
+ 4
+ 412 Precondition Failed (status code) 7
+
+ E
+ ETag header 12
+
+ G
+ Grammar
+ entity-tag 5
+ ETag 12
+ ETag-v 12
+ If-Match 13
+ If-Match-v 13
+ If-Modified-Since 14
+ If-Modified-Since-v 14
+ If-None-Match 16
+ If-None-Match-v 16
+ If-Unmodified-Since 17
+ If-Unmodified-Since-v 17
+ Last-Modified 18
+ Last-Modified-v 18
+ opaque-tag 5
+ weak 5
+
+ H
+ Headers
+ ETag 12
+ If-Match 13
+ If-Modified-Since 14
+ If-None-Match 16
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 24]
+
+Internet-Draft HTTP/1.1, Part 4 August 2010
+
+
+ If-Unmodified-Since 17
+ Last-Modified 18
+
+ I
+ If-Match header 13
+ If-Modified-Since header 14
+ If-None-Match header 16
+ If-Unmodified-Since header 17
+
+ L
+ Last-Modified header 18
+
+ S
+ Status Codes
+ 304 Not Modified 7
+ 412 Precondition Failed 7
+
+Authors' Addresses
+
+ Roy T. Fielding (editor)
+ Day Software
+ 23 Corporate Plaza DR, Suite 280
+ Newport Beach, CA 92660
+ USA
+
+ Phone: +1-949-706-5300
+ Fax: +1-949-706-5305
+ EMail: fielding@gbiv.com
+ URI: http://roy.gbiv.com/
+
+
+ Jim Gettys
+ Alcatel-Lucent Bell Labs
+ 21 Oak Knoll Road
+ Carlisle, MA 01741
+ USA
+
+ EMail: jg@freedesktop.org
+ URI: http://gettys.wordpress.com/
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 25]
+
+Internet-Draft HTTP/1.1, Part 4 August 2010
+
+
+ Jeffrey C. Mogul
+ Hewlett-Packard Company
+ HP Labs, Large Scale Systems Group
+ 1501 Page Mill Road, MS 1177
+ Palo Alto, CA 94304
+ USA
+
+ EMail: JeffMogul@acm.org
+
+
+ Henrik Frystyk Nielsen
+ Microsoft Corporation
+ 1 Microsoft Way
+ Redmond, WA 98052
+ USA
+
+ EMail: henrikn@microsoft.com
+
+
+ Larry Masinter
+ Adobe Systems, Incorporated
+ 345 Park Ave
+ San Jose, CA 95110
+ USA
+
+ EMail: LMM@acm.org
+ URI: http://larry.masinter.net/
+
+
+ Paul J. Leach
+ Microsoft Corporation
+ 1 Microsoft Way
+ Redmond, WA 98052
+
+ EMail: paulle@microsoft.com
+
+
+ Tim Berners-Lee
+ World Wide Web Consortium
+ MIT Computer Science and Artificial Intelligence Laboratory
+ The Stata Center, Building 32
+ 32 Vassar Street
+ Cambridge, MA 02139
+ USA
+
+ EMail: timbl@w3.org
+ URI: http://www.w3.org/People/Berners-Lee/
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 26]
+
+Internet-Draft HTTP/1.1, Part 4 August 2010
+
+
+ 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)
+ greenbytes GmbH
+ Hafenweg 16
+ Muenster, NW 48155
+ Germany
+
+ Phone: +49 251 2807760
+ Fax: +49 251 2807761
+ EMail: julian.reschke@greenbytes.de
+ URI: http://greenbytes.de/tech/webdav/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et al. Expires February 5, 2011 [Page 27]
+