source: draft-ietf-httpbis/15/draft-ietf-httpbis-p4-conditional-15.txt @ 2082

Last change on this file since 2082 was 1328, checked in by julian.reschke@…, 8 years ago

Fix "none yet" entries in -15 change log entries, update -latest accordingly.

  • Property svn:eol-style set to native
  • Property svn:executable set to *
File size: 54.9 KB
Line 
1
2
3
4HTTPbis Working Group                                   R. Fielding, Ed.
5Internet-Draft                                                     Adobe
6Obsoletes: 2616 (if approved)                                  J. Gettys
7Intended status: Standards Track                          Alcatel-Lucent
8Expires: January 12, 2012                                       J. Mogul
9                                                                      HP
10                                                              H. Frystyk
11                                                               Microsoft
12                                                             L. Masinter
13                                                                   Adobe
14                                                                P. Leach
15                                                               Microsoft
16                                                          T. Berners-Lee
17                                                                 W3C/MIT
18                                                           Y. Lafon, Ed.
19                                                                     W3C
20                                                         J. Reschke, Ed.
21                                                              greenbytes
22                                                           July 11, 2011
23
24
25                 HTTP/1.1, part 4: Conditional Requests
26                  draft-ietf-httpbis-p4-conditional-15
27
28Abstract
29
30   The Hypertext Transfer Protocol (HTTP) is an application-level
31   protocol for distributed, collaborative, hypermedia information
32   systems.  HTTP has been in use by the World Wide Web global
33   information initiative since 1990.  This document is Part 4 of the
34   seven-part specification that defines the protocol referred to as
35   "HTTP/1.1" and, taken together, obsoletes RFC 2616.  Part 4 defines
36   request header fields for indicating conditional requests and the
37   rules for constructing responses to those requests.
38
39Editorial Note (To be removed by RFC Editor)
40
41   Discussion of this draft should take place on the HTTPBIS working
42   group mailing list (ietf-http-wg@w3.org), which is archived at
43   <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
44
45   The current issues list is at
46   <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
47   documents (including fancy diffs) can be found at
48   <http://tools.ietf.org/wg/httpbis/>.
49
50   The changes in this draft are summarized in Appendix C.16.
51
52
53
54
55Fielding, et al.        Expires January 12, 2012                [Page 1]
56
57Internet-Draft              HTTP/1.1, Part 4                   July 2011
58
59
60Status of This Memo
61
62   This Internet-Draft is submitted in full conformance with the
63   provisions of BCP 78 and BCP 79.
64
65   Internet-Drafts are working documents of the Internet Engineering
66   Task Force (IETF).  Note that other groups may also distribute
67   working documents as Internet-Drafts.  The list of current Internet-
68   Drafts is at http://datatracker.ietf.org/drafts/current/.
69
70   Internet-Drafts are draft documents valid for a maximum of six months
71   and may be updated, replaced, or obsoleted by other documents at any
72   time.  It is inappropriate to use Internet-Drafts as reference
73   material or to cite them other than as "work in progress."
74
75   This Internet-Draft will expire on January 12, 2012.
76
77Copyright Notice
78
79   Copyright (c) 2011 IETF Trust and the persons identified as the
80   document authors.  All rights reserved.
81
82   This document is subject to BCP 78 and the IETF Trust's Legal
83   Provisions Relating to IETF Documents
84   (http://trustee.ietf.org/license-info) in effect on the date of
85   publication of this document.  Please review these documents
86   carefully, as they describe your rights and restrictions with respect
87   to this document.  Code Components extracted from this document must
88   include Simplified BSD License text as described in Section 4.e of
89   the Trust Legal Provisions and are provided without warranty as
90   described in the Simplified BSD License.
91
92   This document may contain material from IETF Documents or IETF
93   Contributions published or made publicly available before November
94   10, 2008.  The person(s) controlling the copyright in some of this
95   material may not have granted the IETF Trust the right to allow
96   modifications of such material outside the IETF Standards Process.
97   Without obtaining an adequate license from the person(s) controlling
98   the copyright in such materials, this document may not be modified
99   outside the IETF Standards Process, and derivative works of it may
100   not be created outside the IETF Standards Process, except to format
101   it for publication as an RFC or to translate it into languages other
102   than English.
103
104Table of Contents
105
106   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
107     1.1.  Requirements . . . . . . . . . . . . . . . . . . . . . . .  5
108
109
110
111Fielding, et al.        Expires January 12, 2012                [Page 2]
112
113Internet-Draft              HTTP/1.1, Part 4                   July 2011
114
115
116     1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  6
117   2.  Resource State Metadata (Validators) . . . . . . . . . . . . .  6
118     2.1.  Last-Modified  . . . . . . . . . . . . . . . . . . . . . .  6
119       2.1.1.  Generation . . . . . . . . . . . . . . . . . . . . . .  6
120       2.1.2.  Comparison . . . . . . . . . . . . . . . . . . . . . .  7
121     2.2.  ETag . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
122       2.2.1.  Generation . . . . . . . . . . . . . . . . . . . . . .  9
123       2.2.2.  Weak versus Strong . . . . . . . . . . . . . . . . . .  9
124       2.2.3.  Comparison . . . . . . . . . . . . . . . . . . . . . . 11
125       2.2.4.  Rules for When to Use Entity-tags and
126               Last-Modified Dates  . . . . . . . . . . . . . . . . . 11
127       2.2.5.  Example: Entity-tags varying on Content-Negotiated
128               Resources  . . . . . . . . . . . . . . . . . . . . . . 13
129   3.  Precondition Header Fields . . . . . . . . . . . . . . . . . . 14
130     3.1.  If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 14
131     3.2.  If-None-Match  . . . . . . . . . . . . . . . . . . . . . . 15
132     3.3.  If-Modified-Since  . . . . . . . . . . . . . . . . . . . . 16
133     3.4.  If-Unmodified-Since  . . . . . . . . . . . . . . . . . . . 18
134     3.5.  If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 18
135   4.  Status Code Definitions  . . . . . . . . . . . . . . . . . . . 18
136     4.1.  304 Not Modified . . . . . . . . . . . . . . . . . . . . . 18
137     4.2.  412 Precondition Failed  . . . . . . . . . . . . . . . . . 19
138   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
139     5.1.  Status Code Registration . . . . . . . . . . . . . . . . . 19
140     5.2.  Header Field Registration  . . . . . . . . . . . . . . . . 20
141   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
142   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 20
143   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
144     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 20
145     8.2.  Informative References . . . . . . . . . . . . . . . . . . 21
146   Appendix A.  Changes from RFC 2616 . . . . . . . . . . . . . . . . 21
147   Appendix B.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 22
148   Appendix C.  Change Log (to be removed by RFC Editor before
149                publication)  . . . . . . . . . . . . . . . . . . . . 22
150     C.1.  Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 22
151     C.2.  Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 22
152     C.3.  Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 23
153     C.4.  Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 23
154     C.5.  Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 23
155     C.6.  Since draft-ietf-httpbis-p4-conditional-04 . . . . . . . . 23
156     C.7.  Since draft-ietf-httpbis-p4-conditional-05 . . . . . . . . 24
157     C.8.  Since draft-ietf-httpbis-p4-conditional-06 . . . . . . . . 24
158     C.9.  Since draft-ietf-httpbis-p4-conditional-07 . . . . . . . . 24
159     C.10. Since draft-ietf-httpbis-p4-conditional-08 . . . . . . . . 24
160     C.11. Since draft-ietf-httpbis-p4-conditional-09 . . . . . . . . 24
161     C.12. Since draft-ietf-httpbis-p4-conditional-10 . . . . . . . . 24
162     C.13. Since draft-ietf-httpbis-p4-conditional-11 . . . . . . . . 25
163     C.14. Since draft-ietf-httpbis-p4-conditional-12 . . . . . . . . 25
164
165
166
167Fielding, et al.        Expires January 12, 2012                [Page 3]
168
169Internet-Draft              HTTP/1.1, Part 4                   July 2011
170
171
172     C.15. Since draft-ietf-httpbis-p4-conditional-13 . . . . . . . . 25
173     C.16. Since draft-ietf-httpbis-p4-conditional-14 . . . . . . . . 25
174   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223Fielding, et al.        Expires January 12, 2012                [Page 4]
224
225Internet-Draft              HTTP/1.1, Part 4                   July 2011
226
227
2281.  Introduction
229
230   This document defines the HTTP/1.1 conditional request mechanisms,
231   including both response metadata that can be used to indicate or
232   observe changes to resource state and request header fields that
233   specify preconditions to be checked before performing the action
234   given by the request method.  Conditional GET requests are the most
235   efficient mechanism for HTTP cache updates [Part6].  Conditionals can
236   also be applied to state-changing methods, such as PUT and DELETE, to
237   prevent the "lost update" problem: one client accidentally
238   overwriting the work of another client that has been acting in
239   parallel.
240
241   Conditional request preconditions are based on the state of the
242   target resource as a whole (its current value set) or the state as
243   observed in a previously obtained representation (one value in that
244   set).  A resource might have multiple current representations, each
245   with its own observable state.  The conditional request mechanisms
246   assume that the mapping of requests to corresponding representations
247   will be consistent over time if the server intends to take advantage
248   of conditionals.  Regardless, if the mapping is inconsistent and the
249   server is unable to select the appropriate representation, then no
250   harm will result when the precondition evaluates to false.
251
252   We use the term "selected representation" to refer to the current
253   representation of the target resource that would have been selected
254   in a successful response if the same request had used the method GET
255   and had excluded all of the conditional request header fields.  The
256   conditional request preconditions are evaluated by comparing the
257   values provided in the request header fields to the current metadata
258   for the selected representation.
259
2601.1.  Requirements
261
262   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
263   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
264   document are to be interpreted as described in [RFC2119].
265
266   An implementation is not compliant if it fails to satisfy one or more
267   of the "MUST" or "REQUIRED" level requirements for the protocols it
268   implements.  An implementation that satisfies all the "MUST" or
269   "REQUIRED" level and all the "SHOULD" level requirements for its
270   protocols is said to be "unconditionally compliant"; one that
271   satisfies all the "MUST" level requirements but not all the "SHOULD"
272   level requirements for its protocols is said to be "conditionally
273   compliant".
274
275
276
277
278
279Fielding, et al.        Expires January 12, 2012                [Page 5]
280
281Internet-Draft              HTTP/1.1, Part 4                   July 2011
282
283
2841.2.  Syntax Notation
285
286   This specification uses the ABNF syntax defined in Section 1.2 of
287   [Part1] (which extends the syntax defined in [RFC5234] with a list
288   rule).  Appendix B shows the collected ABNF, with the list rule
289   expanded.
290
291   The following core rules are included by reference, as defined in
292   [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
293   (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
294   HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
295   sequence of data), SP (space), VCHAR (any visible USASCII character),
296   and WSP (whitespace).
297
298   The ABNF rules below are defined in other parts:
299
300     quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>
301     OWS           = <OWS, defined in [Part1], Section 1.2.2>
302     HTTP-date     = <HTTP-date, defined in [Part1], Section 6.1>
303
3042.  Resource State Metadata (Validators)
305
306   This specification defines two forms of metadata that are commonly
307   used to observe resource state and test for preconditions:
308   modification dates and opaque entity tags.  Additional metadata that
309   reflects resource state has been defined by various extensions of
310   HTTP, such as WebDAV [RFC4918], that are beyond the scope of this
311   specification.  A resource metadata value is referred to as a
312   "validator" when it is used within a precondition.
313
3142.1.  Last-Modified
315
316   The "Last-Modified" header field indicates the date and time at which
317   the origin server believes the selected representation was last
318   modified.
319
320     Last-Modified = HTTP-date
321
322   An example of its use is
323
324     Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
325
3262.1.1.  Generation
327
328   Origin servers SHOULD send Last-Modified for any selected
329   representation for which a last modification date can be reasonably
330   and consistently determined, since its use in conditional requests
331   and evaluating cache freshness ([Part6]) results in a substantial
332
333
334
335Fielding, et al.        Expires January 12, 2012                [Page 6]
336
337Internet-Draft              HTTP/1.1, Part 4                   July 2011
338
339
340   reduction of HTTP traffic on the Internet and can be a significant
341   factor in improving service scalability and reliability.
342
343   A representation is typically the sum of many parts behind the
344   resource interface.  The last-modified time would usually be the most
345   recent time that any of those parts were changed.  How that value is
346   determined for any given resource is an implementation detail beyond
347   the scope of this specification.  What matters to HTTP is how
348   recipients of the Last-Modified header field can use its value to
349   make conditional requests and test the validity of locally cached
350   responses.
351
352   An origin server SHOULD obtain the Last-Modified value of the
353   representation as close as possible to the time that it generates the
354   Date field-value for its response.  This allows a recipient to make
355   an accurate assessment of the representation's modification time,
356   especially if the representation changes near the time that the
357   response is generated.
358
359   An origin server with a clock MUST NOT send a Last-Modified date that
360   is later than the server's time of message origination (Date).  If
361   the last modification time is derived from implementation-specific
362   metadata that evaluates to some time in the future, according to the
363   origin server's clock, then the origin server MUST replace that value
364   with the message origination date.  This prevents a future
365   modification date from having an adverse impact on cache validation.
366
3672.1.2.  Comparison
368
369   A Last-Modified time, when used as a validator in a request, is
370   implicitly weak unless it is possible to deduce that it is strong,
371   using the following rules:
372
373   o  The validator is being compared by an origin server to the actual
374      current validator for the representation and,
375
376   o  That origin server reliably knows that the associated
377      representation did not change twice during the second covered by
378      the presented validator.
379
380   or
381
382   o  The validator is about to be used by a client in an If-Modified-
383      Since or If-Unmodified-Since header field, because the client has
384      a cache entry for the associated representation, and
385
386   o  That cache entry includes a Date value, which gives the time when
387      the origin server sent the original response, and
388
389
390
391Fielding, et al.        Expires January 12, 2012                [Page 7]
392
393Internet-Draft              HTTP/1.1, Part 4                   July 2011
394
395
396   o  The presented Last-Modified time is at least 60 seconds before the
397      Date value.
398
399   or
400
401   o  The validator is being compared by an intermediate cache to the
402      validator stored in its cache entry for the representation, and
403
404   o  That cache entry includes a Date value, which gives the time when
405      the origin server sent the original response, and
406
407   o  The presented Last-Modified time is at least 60 seconds before the
408      Date value.
409
410   This method relies on the fact that if two different responses were
411   sent by the origin server during the same second, but both had the
412   same Last-Modified time, then at least one of those responses would
413   have a Date value equal to its Last-Modified time.  The arbitrary 60-
414   second limit guards against the possibility that the Date and Last-
415   Modified values are generated from different clocks, or at somewhat
416   different times during the preparation of the response.  An
417   implementation MAY use a value larger than 60 seconds, if it is
418   believed that 60 seconds is too short.
419
4202.2.  ETag
421
422   The ETag header field provides the current entity-tag for the
423   selected representation.  An entity-tag is an opaque validator for
424   differentiating between multiple representations of the same
425   resource, regardless of whether those multiple representations are
426   due to resource state changes over time, content negotiation
427   resulting in multiple representations being valid at the same time,
428   or both.  An entity-tag consists of an opaque quoted string, possibly
429   prefixed by a weakness indicator.
430
431     ETag       = entity-tag
432
433     entity-tag = [ weak ] opaque-tag
434     weak       = %x57.2F ; "W/", case-sensitive
435     opaque-tag = quoted-string
436
437   An entity-tag can be more reliable for validation than a modification
438   date in situations where it is inconvenient to store modification
439   dates, where the one-second resolution of HTTP date values is not
440   sufficient, or where modification dates are not consistently
441   maintained.
442
443
444
445
446
447Fielding, et al.        Expires January 12, 2012                [Page 8]
448
449Internet-Draft              HTTP/1.1, Part 4                   July 2011
450
451
452   Examples:
453
454     ETag: "xyzzy"
455     ETag: W/"xyzzy"
456     ETag: ""
457
4582.2.1.  Generation
459
460   The principle behind entity-tags is that only the service author
461   knows the implementation of a resource well enough to select the most
462   accurate and efficient validation mechanism for that resource, and
463   that any such mechanism can be mapped to a simple sequence of octets
464   for easy comparison.  Since the value is opaque, there is no need for
465   the client to be aware of how each entity-tag is constructed.
466
467   For example, a resource that has implementation-specific versioning
468   applied to all changes might use an internal revision number, perhaps
469   combined with a variance identifier for content negotiation, to
470   accurately differentiate between representations.  Other
471   implementations might use a stored hash of representation content, a
472   combination of various filesystem attributes, or a modification
473   timestamp that has sub-second resolution.
474
475   Origin servers SHOULD send ETag for any selected representation for
476   which detection of changes can be reasonably and consistently
477   determined, since the entity-tag's use in conditional requests and
478   evaluating cache freshness ([Part6]) can result in a substantial
479   reduction of HTTP network traffic and can be a significant factor in
480   improving service scalability and reliability.
481
4822.2.2.  Weak versus Strong
483
484   Since both origin servers and caches will compare two validators to
485   decide if they indicate the same or different representations, one
486   normally would expect that if the representation (including both
487   representation header fields and representation body) changes in any
488   way, then the associated validator would change as well.  If this is
489   true, then we call that validator a "strong validator".  One example
490   of a strong validator is an integer that is incremented in stable
491   storage every time a representation is changed.
492
493   However, there might be cases when a server prefers to change the
494   validator only when it desires cached representations to be
495   invalidated.  For example, the representation of a weather report
496   that changes in content every second, based on dynamic measurements,
497   might be grouped into sets of equivalent representations (from the
498   origin server's perspective) in order to allow cached representations
499   to be valid for a reasonable period of time (perhaps adjusted
500
501
502
503Fielding, et al.        Expires January 12, 2012                [Page 9]
504
505Internet-Draft              HTTP/1.1, Part 4                   July 2011
506
507
508   dynamically based on server load or weather quality).  A validator
509   that does not always change when the representation changes is a
510   "weak validator".
511
512   One can think of a strong validator as part of an identifier for a
513   specific representation, whereas a weak validator is part of an
514   identifier for a set of equivalent representations (where this notion
515   of equivalence is entirely governed by the origin server and beyond
516   the scope of this specification).
517
518   An entity-tag is normally a strong validator, but the protocol
519   provides a mechanism to tag an entity-tag as "weak".
520
521      A representation's modification time, if defined with only one-
522      second resolution, could be a weak validator, since it is possible
523      that the representation might be modified twice during a single
524      second.
525
526      Support for weak validators is optional.  However, weak validators
527      allow for more efficient caching of equivalent objects; for
528      example, a hit counter on a site is probably good enough if it is
529      updated every few days or weeks, and any value during that period
530      is likely "good enough" to be equivalent.
531
532   A strong entity-tag MUST change whenever the associated
533   representation changes in any way.  A weak entity-tag SHOULD change
534   whenever the origin server considers prior representations to be
535   unacceptable as a substitute for the current representation.  In
536   other words, a weak entity tag SHOULD change whenever the origin
537   server wants caches to invalidate old responses.
538
539   A "strong entity-tag" MAY be shared by two representations of a
540   resource only if they are equivalent by octet equality.
541
542   A "weak entity-tag", indicated by the "W/" prefix, MAY be shared by
543   two representations of a resource.  A weak entity-tag can only be
544   used for weak comparison.
545
546   Cache entries might persist for arbitrarily long periods, regardless
547   of expiration times.  Thus, a cache might attempt to validate an
548   entry using a validator that it obtained in the distant past.  A
549   strong entity-tag MUST be unique across all versions of all
550   representations associated with a particular resource over time.
551   However, there is no implication of uniqueness across entity-tags of
552   different resources (i.e., the same entity-tag value might be in use
553   for representations of multiple resources at the same time and does
554   not imply that those representations are equivalent).
555
556
557
558
559Fielding, et al.        Expires January 12, 2012               [Page 10]
560
561Internet-Draft              HTTP/1.1, Part 4                   July 2011
562
563
5642.2.3.  Comparison
565
566   There are two entity-tag comparison functions, depending on whether
567   the comparison context allows the use of weak validators or not:
568
569   o  The strong comparison function: in order to be considered equal,
570      both opaque-tags MUST be identical character-by-character, and
571      both MUST NOT be weak.
572
573   o  The weak comparison function: in order to be considered equal,
574      both opaque-tags MUST be identical character-by-character, but
575      either or both of them MAY be tagged as "weak" without affecting
576      the result.
577
578   A "use" of a validator is either when a client generates a request
579   and includes the validator in a precondition, or when a server
580   compares two validators.
581
582   Strong validators are usable in any context.  Weak validators are
583   only usable in contexts that do not depend on exact equality of a
584   representation.  For example, either kind is usable for a normal
585   conditional GET.
586
587   The example below shows the results for a set of entity-tag pairs,
588   and both the weak and strong comparison function results:
589
590   +--------+--------+-------------------+-----------------+
591   | ETag 1 | ETag 2 | Strong Comparison | Weak Comparison |
592   +--------+--------+-------------------+-----------------+
593   | W/"1"  | W/"1"  | no match          | match           |
594   | W/"1"  | W/"2"  | no match          | no match        |
595   | W/"1"  | "1"    | no match          | match           |
596   | "1"    | "1"    | match             | match           |
597   +--------+--------+-------------------+-----------------+
598
599   An entity-tag is strong unless it is explicitly tagged as weak.
600
6012.2.4.  Rules for When to Use Entity-tags and Last-Modified Dates
602
603   We adopt a set of rules and recommendations for origin servers,
604   clients, and caches regarding when various validator types ought to
605   be used, and for what purposes.
606
607   HTTP/1.1 origin servers:
608
609   o  SHOULD send an entity-tag validator unless it is not feasible to
610      generate one.
611
612
613
614
615Fielding, et al.        Expires January 12, 2012               [Page 11]
616
617Internet-Draft              HTTP/1.1, Part 4                   July 2011
618
619
620   o  MAY send a weak entity-tag instead of a strong entity-tag, if
621      performance considerations support the use of weak entity-tags, or
622      if it is unfeasible to send a strong entity-tag.
623
624   o  SHOULD send a Last-Modified value if it is feasible to send one.
625
626   In other words, the preferred behavior for an HTTP/1.1 origin server
627   is to send both a strong entity-tag and a Last-Modified value.
628
629   HTTP/1.1 clients:
630
631   o  MUST use that entity-tag in any cache-conditional request (using
632      If-Match or If-None-Match) if an entity-tag has been provided by
633      the origin server.
634
635   o  SHOULD use the Last-Modified value in non-subrange cache-
636      conditional requests (using If-Modified-Since) if only a Last-
637      Modified value has been provided by the origin server.
638
639   o  MAY use the Last-Modified value in subrange cache-conditional
640      requests (using If-Unmodified-Since) if only a Last-Modified value
641      has been provided by an HTTP/1.0 origin server.  The user agent
642      SHOULD provide a way to disable this, in case of difficulty.
643
644   o  SHOULD use both validators in cache-conditional requests if both
645      an entity-tag and a Last-Modified value have been provided by the
646      origin server.  This allows both HTTP/1.0 and HTTP/1.1 caches to
647      respond appropriately.
648
649   An HTTP/1.1 origin server, upon receiving a conditional request that
650   includes both a Last-Modified date (e.g., in an If-Modified-Since or
651   If-Unmodified-Since header field) and one or more entity-tags (e.g.,
652   in an If-Match, If-None-Match, or If-Range header field) as cache
653   validators, MUST NOT return a response status code of 304 (Not
654   Modified) unless doing so is consistent with all of the conditional
655   header fields in the request.
656
657   An HTTP/1.1 caching proxy, upon receiving a conditional request that
658   includes both a Last-Modified date and one or more entity-tags as
659   cache validators, MUST NOT return a locally cached response to the
660   client unless that cached response is consistent with all of the
661   conditional header fields in the request.
662
663      Note: The general principle behind these rules is that HTTP/1.1
664      servers and clients ought to transmit as much non-redundant
665      information as is available in their responses and requests.
666      HTTP/1.1 systems receiving this information will make the most
667      conservative assumptions about the validators they receive.
668
669
670
671Fielding, et al.        Expires January 12, 2012               [Page 12]
672
673Internet-Draft              HTTP/1.1, Part 4                   July 2011
674
675
676      HTTP/1.0 clients and caches might ignore entity-tags.  Generally,
677      last-modified values received or used by these systems will
678      support transparent and efficient caching, and so HTTP/1.1 origin
679      servers should provide Last-Modified values.  In those rare cases
680      where the use of a Last-Modified value as a validator by an
681      HTTP/1.0 system could result in a serious problem, then HTTP/1.1
682      origin servers should not provide one.
683
6842.2.5.  Example: Entity-tags varying on Content-Negotiated Resources
685
686   Consider a resource that is subject to content negotiation (Section 5
687   of [Part3]), and where the representations returned upon a GET
688   request vary based on the Accept-Encoding request header field
689   (Section 6.3 of [Part3]):
690
691   >> Request:
692
693     GET /index HTTP/1.1
694     Host: www.example.com
695     Accept-Encoding: gzip
696
697
698   In this case, the response might or might not use the gzip content
699   coding.  If it does not, the response might look like:
700
701   >> Response:
702
703     HTTP/1.1 200 OK
704     Date: Thu, 26 Mar 2010 00:05:00 GMT
705     ETag: "123-a"
706     Content-Length: 70
707     Vary: Accept-Encoding
708     Content-Type: text/plain
709
710     Hello World!
711     Hello World!
712     Hello World!
713     Hello World!
714     Hello World!
715
716   An alternative representation that does use gzip content coding would
717   be:
718
719
720
721
722
723
724
725
726
727Fielding, et al.        Expires January 12, 2012               [Page 13]
728
729Internet-Draft              HTTP/1.1, Part 4                   July 2011
730
731
732   >> Response:
733
734     HTTP/1.1 200 OK
735     Date: Thu, 26 Mar 2010 00:05:00 GMT
736     ETag: "123-b"
737     Content-Length: 43
738     Vary: Accept-Encoding
739     Content-Type: text/plain
740     Content-Encoding: gzip
741
742     ...binary data...
743
744      Note: Content codings are a property of the representation, so
745      therefore an entity-tag of an encoded representation must be
746      distinct from an unencoded representation to prevent conflicts
747      during cache updates and range requests.  In contrast, transfer
748      codings (Section 6.2 of [Part1]) apply only during message
749      transfer and do not require distinct entity-tags.
750
7513.  Precondition Header Fields
752
753   This section defines the syntax and semantics of HTTP/1.1 header
754   fields for applying preconditions on requests.
755
7563.1.  If-Match
757
758   The "If-Match" header field MAY be used to make a request method
759   conditional on the current existence or value of an entity-tag for
760   one or more representations of the target resource.  If-Match is
761   generally useful for resource update requests, such as PUT requests,
762   as a means for protecting against accidental overwrites when multiple
763   clients are acting in parallel on the same resource (i.e., the "lost
764   update" problem).  An If-Match field-value of "*" places the
765   precondition on the existence of any current representation for the
766   target resource.
767
768     If-Match = "*" / 1#entity-tag
769
770   If any of the entity-tags listed in the If-Match field value match
771   (as per Section 2.2.3) the entity-tag of the selected representation
772   for the target resource, or if "*" is given and any current
773   representation exists for the target resource, then the server MAY
774   perform the request method as if the If-Match header field was not
775   present.
776
777   If none of the entity-tags match, or if "*" is given and no current
778   representation exists, the server MUST NOT perform the requested
779   method.  Instead, the server MUST respond with the 412 (Precondition
780
781
782
783Fielding, et al.        Expires January 12, 2012               [Page 14]
784
785Internet-Draft              HTTP/1.1, Part 4                   July 2011
786
787
788   Failed) status code.
789
790   If the request would, without the If-Match header field, result in
791   anything other than a 2xx or 412 status code, then the If-Match
792   header field MUST be ignored.
793
794   Examples:
795
796     If-Match: "xyzzy"
797     If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
798     If-Match: *
799
800   The result of a request having both an If-Match header field and
801   either an If-None-Match or an If-Modified-Since header fields is
802   undefined by this specification.
803
8043.2.  If-None-Match
805
806   The "If-None-Match" header field MAY be used to make a request method
807   conditional on not matching any of the current entity-tag values for
808   representations of the target resource.  If-None-Match is primarily
809   used in conditional GET requests to enable efficient updates of
810   cached information with a minimum amount of transaction overhead.  A
811   client that has one or more representations previously obtained from
812   the target resource can send If-None-Match with a list of the
813   associated entity-tags in the hope of receiving a 304 response if at
814   least one of those representations matches the selected
815   representation.
816
817   If-None-Match MAY also be used with a value of "*" to prevent an
818   unsafe request method (e.g., PUT) from inadvertently modifying an
819   existing representation of the target resource when the client
820   believes that the resource does not have a current representation.
821   This is a variation on the "lost update" problem that might arise if
822   more than one client attempts to create an initial representation for
823   the target resource.
824
825     If-None-Match = "*" / 1#entity-tag
826
827   If any of the entity-tags listed in the If-None-Match field-value
828   match (as per Section 2.2.3) the entity-tag of the selected
829   representation, or if "*" is given and any current representation
830   exists for that resource, then the server MUST NOT perform the
831   requested method.  Instead, if the request method was GET or HEAD,
832   the server SHOULD respond with a 304 (Not Modified) status code,
833   including the cache-related header fields (particularly ETag) of the
834   selected representation that has a matching entity-tag.  For all
835   other request methods, the server MUST respond with a 412
836
837
838
839Fielding, et al.        Expires January 12, 2012               [Page 15]
840
841Internet-Draft              HTTP/1.1, Part 4                   July 2011
842
843
844   (Precondition Failed) status code.
845
846   If none of the entity-tags match, then the server MAY perform the
847   requested method as if the If-None-Match header field did not exist,
848   but MUST also ignore any If-Modified-Since header field(s) in the
849   request.  That is, if no entity-tags match, then the server MUST NOT
850   return a 304 (Not Modified) response.
851
852   If the request would, without the If-None-Match header field, result
853   in anything other than a 2xx or 304 status code, then the If-None-
854   Match header field MUST be ignored.  (See Section 2.2.4 for a
855   discussion of server behavior when both If-Modified-Since and If-
856   None-Match appear in the same request.)
857
858   Examples:
859
860     If-None-Match: "xyzzy"
861     If-None-Match: W/"xyzzy"
862     If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
863     If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
864     If-None-Match: *
865
866   The result of a request having both an If-None-Match header field and
867   either an If-Match or an If-Unmodified-Since header fields is
868   undefined by this specification.
869
8703.3.  If-Modified-Since
871
872   The "If-Modified-Since" header field MAY be used to make a request
873   method conditional by modification date: if the selected
874   representation has not been modified since the time specified in this
875   field, then do not perform the request method; instead, respond as
876   detailed below.
877
878     If-Modified-Since = HTTP-date
879
880   An example of the field is:
881
882     If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
883
884   A GET method with an If-Modified-Since header field and no Range
885   header field requests that the selected representation be transferred
886   only if it has been modified since the date given by the If-Modified-
887   Since header field.  The algorithm for determining this includes the
888   following cases:
889
890   1.  If the request would normally result in anything other than a 200
891       (OK) status code, or if the passed If-Modified-Since date is
892
893
894
895Fielding, et al.        Expires January 12, 2012               [Page 16]
896
897Internet-Draft              HTTP/1.1, Part 4                   July 2011
898
899
900       invalid, the response is exactly the same as for a normal GET.  A
901       date which is later than the server's current time is invalid.
902
903   2.  If the selected representation has been modified since the If-
904       Modified-Since date, the response is exactly the same as for a
905       normal GET.
906
907   3.  If the selected representation has not been modified since a
908       valid If-Modified-Since date, the server SHOULD return a 304 (Not
909       Modified) response.
910
911   The purpose of this feature is to allow efficient updates of cached
912   information with a minimum amount of transaction overhead.
913
914      Note: The Range header field modifies the meaning of If-Modified-
915      Since; see Section 5.4 of [Part5] for full details.
916
917      Note: If-Modified-Since times are interpreted by the server, whose
918      clock might not be synchronized with the client.
919
920      Note: When handling an If-Modified-Since header field, some
921      servers will use an exact date comparison function, rather than a
922      less-than function, for deciding whether to send a 304 (Not
923      Modified) response.  To get best results when sending an If-
924      Modified-Since header field for cache validation, clients are
925      advised to use the exact date string received in a previous Last-
926      Modified header field whenever possible.
927
928      Note: If a client uses an arbitrary date in the If-Modified-Since
929      header field instead of a date taken from the Last-Modified header
930      field for the same request, the client needs to be aware that this
931      date is interpreted in the server's understanding of time.
932      Unsynchronized clocks and rounding problems, due to the different
933      encodings of time between the client and server, are concerns.
934      This includes the possibility of race conditions if the document
935      has changed between the time it was first requested and the If-
936      Modified-Since date of a subsequent request, and the possibility
937      of clock-skew-related problems if the If-Modified-Since date is
938      derived from the client's clock without correction to the server's
939      clock.  Corrections for different time bases between client and
940      server are at best approximate due to network latency.
941
942   The result of a request having both an If-Modified-Since header field
943   and either an If-Match or an If-Unmodified-Since header fields is
944   undefined by this specification.
945
946
947
948
949
950
951Fielding, et al.        Expires January 12, 2012               [Page 17]
952
953Internet-Draft              HTTP/1.1, Part 4                   July 2011
954
955
9563.4.  If-Unmodified-Since
957
958   The "If-Unmodified-Since" header field MAY be used to make a request
959   method conditional by modification date: if the selected
960   representation has been modified since the time specified in this
961   field, then the server MUST NOT perform the requested operation and
962   MUST instead respond with the 412 (Precondition Failed) status code.
963   If the selected representation has not been modified since the time
964   specified in this field, the server SHOULD perform the request method
965   as if the If-Unmodified-Since header field were not present.
966
967     If-Unmodified-Since = HTTP-date
968
969   An example of the field is:
970
971     If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
972
973   If the request normally (i.e., without the If-Unmodified-Since header
974   field) would result in anything other than a 2xx or 412 status code,
975   the If-Unmodified-Since header field SHOULD be ignored.
976
977   If the specified date is invalid, the header field MUST be ignored.
978
979   The result of a request having both an If-Unmodified-Since header
980   field and either an If-None-Match or an If-Modified-Since header
981   fields is undefined by this specification.
982
9833.5.  If-Range
984
985   The If-Range header field provides a special conditional request
986   mechanism that is similar to If-Match and If-Unmodified-Since but
987   specific to HTTP range requests.  If-Range is defined in Section 5.3
988   of [Part5].
989
9904.  Status Code Definitions
991
9924.1.  304 Not Modified
993
994   The 304 status code indicates that a conditional GET request has been
995   received and would have resulted in a 200 (OK) response if it were
996   not for the fact that the condition has evaluated to false.  In other
997   words, there is no need for the server to transfer a representation
998   of the target resource because the client's request indicates that it
999   already has a valid representation, as indicated by the 304 response
1000   header fields, and is therefore redirecting the client to make use of
1001   that stored representation as if it were the payload of a 200
1002   response.  The 304 response MUST NOT contain a message-body, and thus
1003   is always terminated by the first empty line after the header fields.
1004
1005
1006
1007Fielding, et al.        Expires January 12, 2012               [Page 18]
1008
1009Internet-Draft              HTTP/1.1, Part 4                   July 2011
1010
1011
1012   A 304 response MUST include a Date header field (Section 9.3 of
1013   [Part1]) unless its omission is required by Section 9.3.1 of [Part1].
1014   If a 200 response to the same request would have included any of the
1015   header fields Cache-Control, Content-Location, ETag, Expires, Last-
1016   Modified, or Vary, then those same header fields MUST be sent in a
1017   304 response.
1018
1019   Since the goal of a 304 response is to minimize information transfer
1020   when the recipient already has one or more cached representations,
1021   the response SHOULD NOT include representation metadata other than
1022   the above listed fields unless said metadata exists for the purpose
1023   of guiding cache updates (e.g., future HTTP extensions).
1024
1025   If the recipient of a 304 response does not have a cached
1026   representation corresponding to the entity-tag indicated by the 304
1027   response, then the recipient MUST NOT use the 304 to update its own
1028   cache.  If this conditional request originated with an outbound
1029   client, such as a user agent with its own cache sending a conditional
1030   GET to a shared proxy, then the 304 response MAY be forwarded to the
1031   outbound client.  Otherwise, the recipient MUST disregard the 304
1032   response and repeat the request without any preconditions.
1033
1034   If a cache uses a received 304 response to update a cache entry, the
1035   cache MUST update the entry to reflect any new field values given in
1036   the response.
1037
10384.2.  412 Precondition Failed
1039
1040   The 412 status code indicates that one or more preconditions given in
1041   the request header fields evaluated to false when tested on the
1042   server.  This response code allows the client to place preconditions
1043   on the current resource state (its current representations and
1044   metadata) and thus prevent the request method from being applied if
1045   the target resource is in an unexpected state.
1046
10475.  IANA Considerations
1048
10495.1.  Status Code Registration
1050
1051   The HTTP Status Code Registry located at
1052   <http://www.iana.org/assignments/http-status-codes> shall be updated
1053   with the registrations below:
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063Fielding, et al.        Expires January 12, 2012               [Page 19]
1064
1065Internet-Draft              HTTP/1.1, Part 4                   July 2011
1066
1067
1068   +-------+---------------------+-------------+
1069   | Value | Description         | Reference   |
1070   +-------+---------------------+-------------+
1071   | 304   | Not Modified        | Section 4.1 |
1072   | 412   | Precondition Failed | Section 4.2 |
1073   +-------+---------------------+-------------+
1074
10755.2.  Header Field Registration
1076
1077   The Message Header Field Registry located at <http://www.iana.org/
1078   assignments/message-headers/message-header-index.html> shall be
1079   updated with the permanent registrations below (see [RFC3864]):
1080
1081   +---------------------+----------+----------+-------------+
1082   | Header Field Name   | Protocol | Status   | Reference   |
1083   +---------------------+----------+----------+-------------+
1084   | ETag                | http     | standard | Section 2.2 |
1085   | If-Match            | http     | standard | Section 3.1 |
1086   | If-Modified-Since   | http     | standard | Section 3.3 |
1087   | If-None-Match       | http     | standard | Section 3.2 |
1088   | If-Unmodified-Since | http     | standard | Section 3.4 |
1089   | Last-Modified       | http     | standard | Section 2.1 |
1090   +---------------------+----------+----------+-------------+
1091
1092   The change controller is: "IETF (iesg@ietf.org) - Internet
1093   Engineering Task Force".
1094
10956.  Security Considerations
1096
1097   No additional security considerations have been identified beyond
1098   those applicable to HTTP in general [Part1].
1099
11007.  Acknowledgments
1101
11028.  References
1103
11048.1.  Normative References
1105
1106   [Part1]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
1107              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
1108              and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
1109              and Message Parsing", draft-ietf-httpbis-p1-messaging-15
1110              (work in progress), July 2011.
1111
1112   [Part3]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
1113              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
1114              and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload
1115              and Content Negotiation", draft-ietf-httpbis-p3-payload-15
1116
1117
1118
1119Fielding, et al.        Expires January 12, 2012               [Page 20]
1120
1121Internet-Draft              HTTP/1.1, Part 4                   July 2011
1122
1123
1124              (work in progress), July 2011.
1125
1126   [Part5]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
1127              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
1128              and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
1129              Partial Responses", draft-ietf-httpbis-p5-range-15 (work
1130              in progress), July 2011.
1131
1132   [Part6]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
1133              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
1134              Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part
1135              6: Caching", draft-ietf-httpbis-p6-cache-15 (work in
1136              progress), July 2011.
1137
1138   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
1139              Requirement Levels", BCP 14, RFC 2119, March 1997.
1140
1141   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
1142              Specifications: ABNF", STD 68, RFC 5234, January 2008.
1143
11448.2.  Informative References
1145
1146   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
1147              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
1148              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
1149
1150   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
1151              Procedures for Message Header Fields", BCP 90, RFC 3864,
1152              September 2004.
1153
1154   [RFC4918]  Dusseault, L., Ed., "HTTP Extensions for Web Distributed
1155              Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
1156
1157Appendix A.  Changes from RFC 2616
1158
1159   Allow weak entity-tags in all requests except range requests
1160   (Sections 2.2.2 and 3.2).
1161
1162   Change ABNF productions for header fields to only define the field
1163   value.  (Section 3)
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175Fielding, et al.        Expires January 12, 2012               [Page 21]
1176
1177Internet-Draft              HTTP/1.1, Part 4                   July 2011
1178
1179
1180Appendix B.  Collected ABNF
1181
1182   ETag = entity-tag
1183
1184   HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>
1185
1186   If-Match = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS
1187    entity-tag ] ) )
1188   If-Modified-Since = HTTP-date
1189   If-None-Match = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS
1190    entity-tag ] ) )
1191   If-Unmodified-Since = HTTP-date
1192
1193   Last-Modified = HTTP-date
1194
1195   OWS = <OWS, defined in [Part1], Section 1.2.2>
1196
1197   entity-tag = [ weak ] opaque-tag
1198
1199   opaque-tag = quoted-string
1200
1201   quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>
1202
1203   weak = %x57.2F ; W/
1204
1205   ABNF diagnostics:
1206
1207   ; ETag defined but not used
1208   ; If-Match defined but not used
1209   ; If-Modified-Since defined but not used
1210   ; If-None-Match defined but not used
1211   ; If-Unmodified-Since defined but not used
1212   ; Last-Modified defined but not used
1213
1214Appendix C.  Change Log (to be removed by RFC Editor before publication)
1215
1216C.1.  Since RFC 2616
1217
1218   Extracted relevant partitions from [RFC2616].
1219
1220C.2.  Since draft-ietf-httpbis-p4-conditional-00
1221
1222   Closed issues:
1223
1224   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
1225      Informative references"
1226
1227   Other changes:
1228
1229
1230
1231Fielding, et al.        Expires January 12, 2012               [Page 22]
1232
1233Internet-Draft              HTTP/1.1, Part 4                   July 2011
1234
1235
1236   o  Move definitions of 304 and 412 condition codes from Part2.
1237
1238C.3.  Since draft-ietf-httpbis-p4-conditional-01
1239
1240   Ongoing work on ABNF conversion
1241   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
1242
1243   o  Add explicit references to BNF syntax and rules imported from
1244      other parts of the specification.
1245
1246C.4.  Since draft-ietf-httpbis-p4-conditional-02
1247
1248   Closed issues:
1249
1250   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/116>: "Weak ETags on
1251      non-GET requests"
1252
1253   Ongoing work on IANA Message Header Field Registration
1254   (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
1255
1256   o  Reference RFC 3984, and update header field registrations for
1257      header fields defined in this document.
1258
1259C.5.  Since draft-ietf-httpbis-p4-conditional-03
1260
1261   Closed issues:
1262
1263   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/71>: "Examples for
1264      ETag matching"
1265
1266   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/124>: "'entity
1267      value' undefined"
1268
1269   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/126>: "bogus 2068
1270      Date header reference"
1271
1272C.6.  Since draft-ietf-httpbis-p4-conditional-04
1273
1274   Ongoing work on ABNF conversion
1275   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
1276
1277   o  Use "/" instead of "|" for alternatives.
1278
1279   o  Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
1280      whitespace ("OWS") and required whitespace ("RWS").
1281
1282   o  Rewrite ABNFs to spell out whitespace rules, factor out header
1283      field value format definitions.
1284
1285
1286
1287Fielding, et al.        Expires January 12, 2012               [Page 23]
1288
1289Internet-Draft              HTTP/1.1, Part 4                   July 2011
1290
1291
1292C.7.  Since draft-ietf-httpbis-p4-conditional-05
1293
1294   Final work on ABNF conversion
1295   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
1296
1297   o  Add appendix containing collected and expanded ABNF, reorganize
1298      ABNF introduction.
1299
1300C.8.  Since draft-ietf-httpbis-p4-conditional-06
1301
1302   Closed issues:
1303
1304   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/153>: "case-
1305      sensitivity of etag weakness indicator"
1306
1307C.9.  Since draft-ietf-httpbis-p4-conditional-07
1308
1309   Closed issues:
1310
1311   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/116>: "Weak ETags on
1312      non-GET requests" (If-Match still was defined to require strong
1313      matching)
1314
1315   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA
1316      registrations for optional status codes"
1317
1318C.10.  Since draft-ietf-httpbis-p4-conditional-08
1319
1320   No significant changes.
1321
1322C.11.  Since draft-ietf-httpbis-p4-conditional-09
1323
1324   No significant changes.
1325
1326C.12.  Since draft-ietf-httpbis-p4-conditional-10
1327
1328   Closed issues:
1329
1330   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/69>: "Clarify
1331      'Requested Variant'"
1332
1333   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify
1334      entity / representation / variant terminology"
1335
1336   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider
1337      removing the 'changes from 2068' sections"
1338
1339
1340
1341
1342
1343Fielding, et al.        Expires January 12, 2012               [Page 24]
1344
1345Internet-Draft              HTTP/1.1, Part 4                   July 2011
1346
1347
1348C.13.  Since draft-ietf-httpbis-p4-conditional-11
1349
1350   None.
1351
1352C.14.  Since draft-ietf-httpbis-p4-conditional-12
1353
1354   Closed issues:
1355
1356   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header
1357      Classification"
1358
1359C.15.  Since draft-ietf-httpbis-p4-conditional-13
1360
1361   Closed issues:
1362
1363   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/89>: "If-* and
1364      entities"
1365
1366   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/101>: "Definition of
1367      validator weakness"
1368
1369   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle
1370      ABNFs for header fields"
1371
1372   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/269>: "ETags and
1373      Quotes"
1374
1375C.16.  Since draft-ietf-httpbis-p4-conditional-14
1376
1377   None.
1378
1379Index
1380
1381   3
1382      304 Not Modified (status code)  18
1383
1384   4
1385      412 Precondition Failed (status code)  19
1386
1387   E
1388      ETag header field  8
1389
1390   G
1391      Grammar
1392         entity-tag  8
1393         ETag  8
1394         If-Match  14
1395         If-Modified-Since  16
1396
1397
1398
1399Fielding, et al.        Expires January 12, 2012               [Page 25]
1400
1401Internet-Draft              HTTP/1.1, Part 4                   July 2011
1402
1403
1404         If-None-Match  15
1405         If-Unmodified-Since  18
1406         Last-Modified  6
1407         opaque-tag  8
1408         weak  8
1409
1410   H
1411      Header Fields
1412         ETag  8
1413         If-Match  14
1414         If-Modified-Since  16
1415         If-None-Match  15
1416         If-Unmodified-Since  18
1417         Last-Modified  6
1418
1419   I
1420      If-Match header field  14
1421      If-Modified-Since header field  16
1422      If-None-Match header field  15
1423      If-Unmodified-Since header field  18
1424
1425   L
1426      Last-Modified header field  6
1427
1428   M
1429      metadata  6
1430
1431   S
1432      selected representation  5
1433      Status Codes
1434         304 Not Modified  18
1435         412 Precondition Failed  19
1436
1437   V
1438      validator  6
1439
1440Authors' Addresses
1441
1442   Roy T. Fielding (editor)
1443   Adobe Systems Incorporated
1444   345 Park Ave
1445   San Jose, CA  95110
1446   USA
1447
1448   EMail: fielding@gbiv.com
1449   URI:   http://roy.gbiv.com/
1450
1451
1452
1453
1454
1455Fielding, et al.        Expires January 12, 2012               [Page 26]
1456
1457Internet-Draft              HTTP/1.1, Part 4                   July 2011
1458
1459
1460   Jim Gettys
1461   Alcatel-Lucent Bell Labs
1462   21 Oak Knoll Road
1463   Carlisle, MA  01741
1464   USA
1465
1466   EMail: jg@freedesktop.org
1467   URI:   http://gettys.wordpress.com/
1468
1469
1470   Jeffrey C. Mogul
1471   Hewlett-Packard Company
1472   HP Labs, Large Scale Systems Group
1473   1501 Page Mill Road, MS 1177
1474   Palo Alto, CA  94304
1475   USA
1476
1477   EMail: JeffMogul@acm.org
1478
1479
1480   Henrik Frystyk Nielsen
1481   Microsoft Corporation
1482   1 Microsoft Way
1483   Redmond, WA  98052
1484   USA
1485
1486   EMail: henrikn@microsoft.com
1487
1488
1489   Larry Masinter
1490   Adobe Systems Incorporated
1491   345 Park Ave
1492   San Jose, CA  95110
1493   USA
1494
1495   EMail: LMM@acm.org
1496   URI:   http://larry.masinter.net/
1497
1498
1499   Paul J. Leach
1500   Microsoft Corporation
1501   1 Microsoft Way
1502   Redmond, WA  98052
1503
1504   EMail: paulle@microsoft.com
1505
1506
1507
1508
1509
1510
1511Fielding, et al.        Expires January 12, 2012               [Page 27]
1512
1513Internet-Draft              HTTP/1.1, Part 4                   July 2011
1514
1515
1516   Tim Berners-Lee
1517   World Wide Web Consortium
1518   MIT Computer Science and Artificial Intelligence Laboratory
1519   The Stata Center, Building 32
1520   32 Vassar Street
1521   Cambridge, MA  02139
1522   USA
1523
1524   EMail: timbl@w3.org
1525   URI:   http://www.w3.org/People/Berners-Lee/
1526
1527
1528   Yves Lafon (editor)
1529   World Wide Web Consortium
1530   W3C / ERCIM
1531   2004, rte des Lucioles
1532   Sophia-Antipolis, AM  06902
1533   France
1534
1535   EMail: ylafon@w3.org
1536   URI:   http://www.raubacapeu.net/people/yves/
1537
1538
1539   Julian F. Reschke (editor)
1540   greenbytes GmbH
1541   Hafenweg 16
1542   Muenster, NW  48155
1543   Germany
1544
1545   Phone: +49 251 2807760
1546   Fax:   +49 251 2807761
1547   EMail: julian.reschke@greenbytes.de
1548   URI:   http://greenbytes.de/tech/webdav/
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567Fielding, et al.        Expires January 12, 2012               [Page 28]
1568
Note: See TracBrowser for help on using the repository browser.