source: draft-ietf-httpbis/22/draft-ietf-httpbis-p4-conditional-22.txt @ 2561

Last change on this file since 2561 was 2190, checked in by julian.reschke@…, 7 years ago

prepare -22 for release

  • Property svn:eol-style set to native
  • Property svn:executable set to *
File size: 54.8 KB
Line 
1
2
3
4HTTPbis Working Group                                   R. Fielding, Ed.
5Internet-Draft                                                     Adobe
6Obsoletes: 2616 (if approved)                            J. Reschke, Ed.
7Intended status: Standards Track                              greenbytes
8Expires: August 27, 2013                               February 23, 2013
9
10
11      Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
12                  draft-ietf-httpbis-p4-conditional-22
13
14Abstract
15
16   The Hypertext Transfer Protocol (HTTP) is an application-level
17   protocol for distributed, collaborative, hypertext information
18   systems.  This document defines HTTP/1.1 conditional requests,
19   including metadata header fields for indicating state changes,
20   request header fields for making preconditions on such state, and
21   rules for constructing the responses to a conditional request when
22   one or more preconditions evaluate to false.
23
24Editorial Note (To be removed by RFC Editor)
25
26   Discussion of this draft takes place on the HTTPBIS working group
27   mailing list (ietf-http-wg@w3.org), which is archived at
28   <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
29
30   The current issues list is at
31   <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
32   documents (including fancy diffs) can be found at
33   <http://tools.ietf.org/wg/httpbis/>.
34
35   The changes in this draft are summarized in Appendix D.3.
36
37Status of This Memo
38
39   This Internet-Draft is submitted in full conformance with the
40   provisions of BCP 78 and BCP 79.
41
42   Internet-Drafts are working documents of the Internet Engineering
43   Task Force (IETF).  Note that other groups may also distribute
44   working documents as Internet-Drafts.  The list of current Internet-
45   Drafts is at http://datatracker.ietf.org/drafts/current/.
46
47   Internet-Drafts are draft documents valid for a maximum of six months
48   and may be updated, replaced, or obsoleted by other documents at any
49   time.  It is inappropriate to use Internet-Drafts as reference
50   material or to cite them other than as "work in progress."
51
52
53
54
55Fielding & Reschke       Expires August 27, 2013                [Page 1]
56
57Internet-Draft        HTTP/1.1 Conditional Requests        February 2013
58
59
60   This Internet-Draft will expire on August 27, 2013.
61
62Copyright Notice
63
64   Copyright (c) 2013 IETF Trust and the persons identified as the
65   document authors.  All rights reserved.
66
67   This document is subject to BCP 78 and the IETF Trust's Legal
68   Provisions Relating to IETF Documents
69   (http://trustee.ietf.org/license-info) in effect on the date of
70   publication of this document.  Please review these documents
71   carefully, as they describe your rights and restrictions with respect
72   to this document.  Code Components extracted from this document must
73   include Simplified BSD License text as described in Section 4.e of
74   the Trust Legal Provisions and are provided without warranty as
75   described in the Simplified BSD License.
76
77   This document may contain material from IETF Documents or IETF
78   Contributions published or made publicly available before November
79   10, 2008.  The person(s) controlling the copyright in some of this
80   material may not have granted the IETF Trust the right to allow
81   modifications of such material outside the IETF Standards Process.
82   Without obtaining an adequate license from the person(s) controlling
83   the copyright in such materials, this document may not be modified
84   outside the IETF Standards Process, and derivative works of it may
85   not be created outside the IETF Standards Process, except to format
86   it for publication as an RFC or to translate it into languages other
87   than English.
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111Fielding & Reschke       Expires August 27, 2013                [Page 2]
112
113Internet-Draft        HTTP/1.1 Conditional Requests        February 2013
114
115
116Table of Contents
117
118   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
119     1.1.  Conformance and Error Handling . . . . . . . . . . . . . .  4
120     1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  4
121   2.  Validators . . . . . . . . . . . . . . . . . . . . . . . . . .  5
122     2.1.  Weak versus Strong . . . . . . . . . . . . . . . . . . . .  5
123     2.2.  Last-Modified  . . . . . . . . . . . . . . . . . . . . . .  7
124       2.2.1.  Generation . . . . . . . . . . . . . . . . . . . . . .  7
125       2.2.2.  Comparison . . . . . . . . . . . . . . . . . . . . . .  8
126     2.3.  ETag . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
127       2.3.1.  Generation . . . . . . . . . . . . . . . . . . . . . . 10
128       2.3.2.  Comparison . . . . . . . . . . . . . . . . . . . . . . 10
129       2.3.3.  Example: Entity-tags Varying on Content-Negotiated
130               Resources  . . . . . . . . . . . . . . . . . . . . . . 11
131     2.4.  When to Use Entity-tags and Last-Modified Dates  . . . . . 12
132   3.  Precondition Header Fields . . . . . . . . . . . . . . . . . . 13
133     3.1.  If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 13
134     3.2.  If-None-Match  . . . . . . . . . . . . . . . . . . . . . . 14
135     3.3.  If-Modified-Since  . . . . . . . . . . . . . . . . . . . . 15
136     3.4.  If-Unmodified-Since  . . . . . . . . . . . . . . . . . . . 16
137     3.5.  If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 16
138   4.  Status Code Definitions  . . . . . . . . . . . . . . . . . . . 17
139     4.1.  304 Not Modified . . . . . . . . . . . . . . . . . . . . . 17
140     4.2.  412 Precondition Failed  . . . . . . . . . . . . . . . . . 17
141   5.  Evaluation and Precedence  . . . . . . . . . . . . . . . . . . 17
142   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
143     6.1.  Status Code Registration . . . . . . . . . . . . . . . . . 20
144     6.2.  Header Field Registration  . . . . . . . . . . . . . . . . 20
145   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
146   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 21
147   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
148     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 21
149     9.2.  Informative References . . . . . . . . . . . . . . . . . . 22
150   Appendix A.  Changes from RFC 2616 . . . . . . . . . . . . . . . . 22
151   Appendix B.  Imported ABNF . . . . . . . . . . . . . . . . . . . . 22
152   Appendix C.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 23
153   Appendix D.  Change Log (to be removed by RFC Editor before
154                publication)  . . . . . . . . . . . . . . . . . . . . 23
155     D.1.  Since draft-ietf-httpbis-p4-conditional-19 . . . . . . . . 23
156     D.2.  Since draft-ietf-httpbis-p4-conditional-20 . . . . . . . . 24
157     D.3.  Since draft-ietf-httpbis-p4-conditional-21 . . . . . . . . 24
158   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
159
160
161
162
163
164
165
166
167Fielding & Reschke       Expires August 27, 2013                [Page 3]
168
169Internet-Draft        HTTP/1.1 Conditional Requests        February 2013
170
171
1721.  Introduction
173
174   Conditional requests are HTTP requests [Part2] that include one or
175   more header fields indicating a precondition to be tested before
176   applying the method semantics to the target resource.  This document
177   defines the HTTP/1.1 conditional request mechanisms in terms of the
178   architecture, syntax notation, and conformance criteria defined in
179   [Part1].
180
181   Conditional GET requests are the most efficient mechanism for HTTP
182   cache updates [Part6].  Conditionals can also be applied to state-
183   changing methods, such as PUT and DELETE, to prevent the "lost
184   update" problem: one client accidentally overwriting the work of
185   another client that has been acting in parallel.
186
187   Conditional request preconditions are based on the state of the
188   target resource as a whole (its current value set) or the state as
189   observed in a previously obtained representation (one value in that
190   set).  A resource might have multiple current representations, each
191   with its own observable state.  The conditional request mechanisms
192   assume that the mapping of requests to a "selected representation"
193   (Section 3 of [Part2]) will be consistent over time if the server
194   intends to take advantage of conditionals.  Regardless, if the
195   mapping is inconsistent and the server is unable to select the
196   appropriate representation, then no harm will result when the
197   precondition evaluates to false.
198
199   The conditional request preconditions defined by this specification
200   are evaluated by comparing the validators provided in the conditional
201   request header fields to the current validators for the selected
202   representation in the order defined by Section 5.
203
2041.1.  Conformance and Error Handling
205
206   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
207   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
208   document are to be interpreted as described in [RFC2119].
209
210   Conformance criteria and considerations regarding error handling are
211   defined in Section 2.5 of [Part1].
212
2131.2.  Syntax Notation
214
215   This specification uses the Augmented Backus-Naur Form (ABNF)
216   notation of [RFC5234] with the list rule extension defined in Section
217   1.2 of [Part1].  Appendix B describes rules imported from other
218   documents.  Appendix C shows the collected ABNF with the list rule
219   expanded.
220
221
222
223Fielding & Reschke       Expires August 27, 2013                [Page 4]
224
225Internet-Draft        HTTP/1.1 Conditional Requests        February 2013
226
227
2282.  Validators
229
230   This specification defines two forms of metadata that are commonly
231   used to observe resource state and test for preconditions:
232   modification dates (Section 2.2) and opaque entity tags
233   (Section 2.3).  Additional metadata that reflects resource state has
234   been defined by various extensions of HTTP, such as WebDAV [RFC4918],
235   that are beyond the scope of this specification.  A resource metadata
236   value is referred to as a "validator" when it is used within a
237   precondition.
238
2392.1.  Weak versus Strong
240
241   Validators come in two flavors: strong or weak.  Weak validators are
242   easy to generate but are far less useful for comparisons.  Strong
243   validators are ideal for comparisons but can be very difficult (and
244   occasionally impossible) to generate efficiently.  Rather than impose
245   that all forms of resource adhere to the same strength of validator,
246   HTTP exposes the type of validator in use and imposes restrictions on
247   when weak validators can be used as preconditions.
248
249   A "strong validator" is representation metadata that changes value
250   whenever a change occurs to the representation data that would be
251   observable in the payload body of a 200 (OK) response to GET.
252
253   A strong validator might change for other reasons, such as when a
254   semantically significant part of the representation metadata is
255   changed (e.g., Content-Type), but it is in the best interests of the
256   origin server to only change the value when it is necessary to
257   invalidate the stored responses held by remote caches and authoring
258   tools.  A strong validator is unique across all representations of a
259   given resource, such that no two representations of that resource can
260   share the same validator unless their representation data is
261   identical.
262
263   Cache entries might persist for arbitrarily long periods, regardless
264   of expiration times.  Thus, a cache might attempt to validate an
265   entry using a validator that it obtained in the distant past.  A
266   strong validator is unique across all versions of all representations
267   associated with a particular resource over time.  However, there is
268   no implication of uniqueness across representations of different
269   resources (i.e., the same strong validator might be in use for
270   representations of multiple resources at the same time and does not
271   imply that those representations are equivalent).
272
273   There are a variety of strong validators used in practice.  The best
274   are based on strict revision control, wherein each change to a
275   representation always results in a unique node name and revision
276
277
278
279Fielding & Reschke       Expires August 27, 2013                [Page 5]
280
281Internet-Draft        HTTP/1.1 Conditional Requests        February 2013
282
283
284   identifier being assigned before the representation is made
285   accessible to GET.  A collision-resistant hash function applied to
286   the representation data is also sufficient if the data is available
287   prior to the response header fields being sent and the digest does
288   not need to be recalculated every time a validation request is
289   received.  However, if a resource has distinct representations that
290   differ only in their metadata, such as might occur with content
291   negotiation over media types that happen to share the same data
292   format, then the origin server SHOULD incorporate additional
293   information in the validator to distinguish those representations and
294   avoid confusing cache behavior.
295
296   In contrast, a "weak validator" is representation metadata that might
297   not change for every change to the representation data.  This
298   weakness might be due to limitations in how the value is calculated,
299   such as clock resolution or an inability to ensure uniqueness for all
300   possible representations of the resource, or due to a desire by the
301   resource owner to group representations by some self-determined set
302   of equivalency rather than unique sequences of data.  An origin
303   server SHOULD change a weak entity-tag whenever it considers prior
304   representations to be unacceptable as a substitute for the current
305   representation.  In other words, a weak entity-tag ought to change
306   whenever the origin server wants caches to invalidate old responses.
307
308   For example, the representation of a weather report that changes in
309   content every second, based on dynamic measurements, might be grouped
310   into sets of equivalent representations (from the origin server's
311   perspective) with the same weak validator in order to allow cached
312   representations to be valid for a reasonable period of time (perhaps
313   adjusted dynamically based on server load or weather quality).
314   Likewise, a representation's modification time, if defined with only
315   one-second resolution, might be a weak validator if it is possible
316   for the representation to be modified twice during a single second
317   and retrieved between those modifications.
318
319   Likewise, a validator is weak if it is shared by two or more
320   representations of a given resource at the same time, unless those
321   representations have identical representation data.  For example, if
322   the origin server sends the same validator for a representation with
323   a gzip content coding applied as it does for a representation with no
324   content coding, then that validator is weak.  However, two
325   simultaneous representations might share the same strong validator if
326   they differ only in the representation metadata, such as when two
327   different media types are available for the same representation data.
328
329   A "use" of a validator occurs when either a client generates a
330   request and includes the validator in a precondition or when a server
331   compares two validators.  Weak validators are only usable in contexts
332
333
334
335Fielding & Reschke       Expires August 27, 2013                [Page 6]
336
337Internet-Draft        HTTP/1.1 Conditional Requests        February 2013
338
339
340   that do not depend on exact equality of the representation data.
341   Strong validators are usable and preferred for all conditional
342   requests, including cache validation, partial content ranges, and
343   "lost update" avoidance.
344
3452.2.  Last-Modified
346
347   The "Last-Modified" header field in a response provides a timestamp
348   indicating the date and time at which the origin server believes the
349   selected representation was last modified, as determined at the
350   conclusion of handling the request.
351
352     Last-Modified = HTTP-date
353
354   An example of its use is
355
356     Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
357
3582.2.1.  Generation
359
360   Origin servers SHOULD send Last-Modified for any selected
361   representation for which a last modification date can be reasonably
362   and consistently determined, since its use in conditional requests
363   and evaluating cache freshness ([Part6]) results in a substantial
364   reduction of HTTP traffic on the Internet and can be a significant
365   factor in improving service scalability and reliability.
366
367   A representation is typically the sum of many parts behind the
368   resource interface.  The last-modified time would usually be the most
369   recent time that any of those parts were changed.  How that value is
370   determined for any given resource is an implementation detail beyond
371   the scope of this specification.  What matters to HTTP is how
372   recipients of the Last-Modified header field can use its value to
373   make conditional requests and test the validity of locally cached
374   responses.
375
376   An origin server SHOULD obtain the Last-Modified value of the
377   representation as close as possible to the time that it generates the
378   Date field value for its response.  This allows a recipient to make
379   an accurate assessment of the representation's modification time,
380   especially if the representation changes near the time that the
381   response is generated.
382
383   An origin server with a clock MUST NOT send a Last-Modified date that
384   is later than the server's time of message origination (Date).  If
385   the last modification time is derived from implementation-specific
386   metadata that evaluates to some time in the future, according to the
387   origin server's clock, then the origin server MUST replace that value
388
389
390
391Fielding & Reschke       Expires August 27, 2013                [Page 7]
392
393Internet-Draft        HTTP/1.1 Conditional Requests        February 2013
394
395
396   with the message origination date.  This prevents a future
397   modification date from having an adverse impact on cache validation.
398
399   An origin server without a clock MUST NOT assign Last-Modified values
400   to a response unless these values were associated with the resource
401   by some other system or user with a reliable clock.
402
4032.2.2.  Comparison
404
405   A Last-Modified time, when used as a validator in a request, is
406   implicitly weak unless it is possible to deduce that it is strong,
407   using the following rules:
408
409   o  The validator is being compared by an origin server to the actual
410      current validator for the representation and,
411
412   o  That origin server reliably knows that the associated
413      representation did not change twice during the second covered by
414      the presented validator.
415
416   or
417
418   o  The validator is about to be used by a client in an If-Modified-
419      Since, If-Unmodified-Since header field, because the client has a
420      cache entry, or If-Range for the associated representation, and
421
422   o  That cache entry includes a Date value, which gives the time when
423      the origin server sent the original response, and
424
425   o  The presented Last-Modified time is at least 60 seconds before the
426      Date value.
427
428   or
429
430   o  The validator is being compared by an intermediate cache to the
431      validator stored in its cache entry for the representation, and
432
433   o  That cache entry includes a Date value, which gives the time when
434      the origin server sent the original response, and
435
436   o  The presented Last-Modified time is at least 60 seconds before the
437      Date value.
438
439   This method relies on the fact that if two different responses were
440   sent by the origin server during the same second, but both had the
441   same Last-Modified time, then at least one of those responses would
442   have a Date value equal to its Last-Modified time.  The arbitrary 60-
443   second limit guards against the possibility that the Date and Last-
444
445
446
447Fielding & Reschke       Expires August 27, 2013                [Page 8]
448
449Internet-Draft        HTTP/1.1 Conditional Requests        February 2013
450
451
452   Modified values are generated from different clocks, or at somewhat
453   different times during the preparation of the response.  An
454   implementation MAY use a value larger than 60 seconds, if it is
455   believed that 60 seconds is too short.
456
4572.3.  ETag
458
459   The "ETag" header field in a response provides the current entity-tag
460   for the selected representation, as determined at the conclusion of
461   handling the request.  An entity-tag is an opaque validator for
462   differentiating between multiple representations of the same
463   resource, regardless of whether those multiple representations are
464   due to resource state changes over time, content negotiation
465   resulting in multiple representations being valid at the same time,
466   or both.  An entity-tag consists of an opaque quoted string, possibly
467   prefixed by a weakness indicator.
468
469     ETag       = entity-tag
470
471     entity-tag = [ weak ] opaque-tag
472     weak       = %x57.2F ; "W/", case-sensitive
473     opaque-tag = DQUOTE *etagc DQUOTE
474     etagc      = %x21 / %x23-7E / obs-text
475                ; VCHAR except double quotes, plus obs-text
476
477      Note: Previously, opaque-tag was defined to be a quoted-string
478      ([RFC2616], Section 3.11), thus some recipients might perform
479      backslash unescaping.  Servers therefore ought to avoid backslash
480      characters in entity tags.
481
482   An entity-tag can be more reliable for validation than a modification
483   date in situations where it is inconvenient to store modification
484   dates, where the one-second resolution of HTTP date values is not
485   sufficient, or where modification dates are not consistently
486   maintained.
487
488   Examples:
489
490     ETag: "xyzzy"
491     ETag: W/"xyzzy"
492     ETag: ""
493
494   An entity-tag can be either a weak or strong validator, with strong
495   being the default.  If an origin server provides an entity-tag for a
496   representation and the generation of that entity-tag does not satisfy
497   all of the characteristics of a strong validator (Section 2.1), then
498   the origin server MUST mark the entity-tag as weak by prefixing its
499   opaque value with "W/" (case-sensitive).
500
501
502
503Fielding & Reschke       Expires August 27, 2013                [Page 9]
504
505Internet-Draft        HTTP/1.1 Conditional Requests        February 2013
506
507
5082.3.1.  Generation
509
510   The principle behind entity-tags is that only the service author
511   knows the implementation of a resource well enough to select the most
512   accurate and efficient validation mechanism for that resource, and
513   that any such mechanism can be mapped to a simple sequence of octets
514   for easy comparison.  Since the value is opaque, there is no need for
515   the client to be aware of how each entity-tag is constructed.
516
517   For example, a resource that has implementation-specific versioning
518   applied to all changes might use an internal revision number, perhaps
519   combined with a variance identifier for content negotiation, to
520   accurately differentiate between representations.  Other
521   implementations might use a collision-resistant hash of
522   representation content, a combination of various filesystem
523   attributes, or a modification timestamp that has sub-second
524   resolution.
525
526   Origin servers SHOULD send ETag for any selected representation for
527   which detection of changes can be reasonably and consistently
528   determined, since the entity-tag's use in conditional requests and
529   evaluating cache freshness ([Part6]) can result in a substantial
530   reduction of HTTP network traffic and can be a significant factor in
531   improving service scalability and reliability.
532
5332.3.2.  Comparison
534
535   There are two entity-tag comparison functions, depending on whether
536   the comparison context allows the use of weak validators or not:
537
538   o  Strong comparison: two entity-tags are equivalent if both are not
539      weak and their opaque-tags match character-by-character.
540
541   o  Weak comparison: two entity-tags are equivalent if their opaque-
542      tags match character-by-character, regardless of either or both
543      being tagged as "weak".
544
545   The example below shows the results for a set of entity-tag pairs,
546   and both the weak and strong comparison function results:
547
548   +--------+--------+-------------------+-----------------+
549   | ETag 1 | ETag 2 | Strong Comparison | Weak Comparison |
550   +--------+--------+-------------------+-----------------+
551   | W/"1"  | W/"1"  | no match          | match           |
552   | W/"1"  | W/"2"  | no match          | no match        |
553   | W/"1"  | "1"    | no match          | match           |
554   | "1"    | "1"    | match             | match           |
555   +--------+--------+-------------------+-----------------+
556
557
558
559Fielding & Reschke       Expires August 27, 2013               [Page 10]
560
561Internet-Draft        HTTP/1.1 Conditional Requests        February 2013
562
563
5642.3.3.  Example: Entity-tags Varying on Content-Negotiated Resources
565
566   Consider a resource that is subject to content negotiation (Section
567   3.4 of [Part2]), and where the representations sent in response to a
568   GET request vary based on the Accept-Encoding request header field
569   (Section 5.3.4 of [Part2]):
570
571   >> Request:
572
573     GET /index HTTP/1.1
574     Host: www.example.com
575     Accept-Encoding: gzip
576
577
578   In this case, the response might or might not use the gzip content
579   coding.  If it does not, the response might look like:
580
581   >> Response:
582
583     HTTP/1.1 200 OK
584     Date: Thu, 26 Mar 2010 00:05:00 GMT
585     ETag: "123-a"
586     Content-Length: 70
587     Vary: Accept-Encoding
588     Content-Type: text/plain
589
590     Hello World!
591     Hello World!
592     Hello World!
593     Hello World!
594     Hello World!
595
596   An alternative representation that does use gzip content coding would
597   be:
598
599   >> Response:
600
601     HTTP/1.1 200 OK
602     Date: Thu, 26 Mar 2010 00:05:00 GMT
603     ETag: "123-b"
604     Content-Length: 43
605     Vary: Accept-Encoding
606     Content-Type: text/plain
607     Content-Encoding: gzip
608
609     ...binary data...
610
611
612
613
614
615Fielding & Reschke       Expires August 27, 2013               [Page 11]
616
617Internet-Draft        HTTP/1.1 Conditional Requests        February 2013
618
619
620      Note: Content codings are a property of the representation, so
621      therefore an entity-tag of an encoded representation has to be
622      distinct from an unencoded representation to prevent conflicts
623      during cache updates and range requests.  In contrast, transfer
624      codings (Section 4 of [Part1]) apply only during message transfer
625      and do not require distinct entity-tags.
626
6272.4.  When to Use Entity-tags and Last-Modified Dates
628
629   We adopt a set of rules and recommendations for origin servers,
630   clients, and caches regarding when various validator types ought to
631   be used, and for what purposes.
632
633   In 200 (OK) responses to GET or HEAD, an origin server:
634
635   o  SHOULD send an entity-tag validator unless it is not feasible to
636      generate one.
637
638   o  MAY send a weak entity-tag instead of a strong entity-tag, if
639      performance considerations support the use of weak entity-tags, or
640      if it is unfeasible to send a strong entity-tag.
641
642   o  SHOULD send a Last-Modified value if it is feasible to send one.
643
644   In other words, the preferred behavior for an origin server is to
645   send both a strong entity-tag and a Last-Modified value in successful
646   responses to a retrieval request.
647
648   A client:
649
650   o  MUST use that entity-tag in any cache-conditional request (using
651      If-Match or If-None-Match) if an entity-tag has been provided by
652      the origin server.
653
654   o  SHOULD use the Last-Modified value in non-subrange cache-
655      conditional requests (using If-Modified-Since) if only a Last-
656      Modified value has been provided by the origin server.
657
658   o  MAY use the Last-Modified value in subrange cache-conditional
659      requests (using If-Unmodified-Since) if only a Last-Modified value
660      has been provided by an HTTP/1.0 origin server.  The user agent
661      SHOULD provide a way to disable this, in case of difficulty.
662
663   o  SHOULD use both validators in cache-conditional requests if both
664      an entity-tag and a Last-Modified value have been provided by the
665      origin server.  This allows both HTTP/1.0 and HTTP/1.1 caches to
666      respond appropriately.
667
668
669
670
671Fielding & Reschke       Expires August 27, 2013               [Page 12]
672
673Internet-Draft        HTTP/1.1 Conditional Requests        February 2013
674
675
6763.  Precondition Header Fields
677
678   This section defines the syntax and semantics of HTTP/1.1 header
679   fields for applying preconditions on requests.  Section 5 defines
680   when the preconditions are applied and the order of evaluation when
681   more than one precondition is present.
682
6833.1.  If-Match
684
685   The "If-Match" header field can be used to make a request method
686   conditional on the current existence or value of an entity-tag for
687   one or more representations of the target resource.
688
689   If-Match is generally useful for resource update requests, such as
690   PUT requests, as a means for protecting against accidental overwrites
691   when multiple clients are acting in parallel on the same resource
692   (i.e., the "lost update" problem).  An If-Match field-value of "*"
693   places the precondition on the existence of any current
694   representation for the target resource.
695
696     If-Match = "*" / 1#entity-tag
697
698   The If-Match condition is met if and only if any of the entity-tags
699   listed in the If-Match field value match the entity-tag of the
700   selected representation using the weak comparison function (as per
701   Section 2.3.2), or if "*" is given and any current representation
702   exists for the target resource.
703
704   If the condition is met, the server MAY perform the request method.
705
706   Origin servers MUST NOT perform the requested method if the condition
707   is not met; instead they MUST respond with the 412 (Precondition
708   Failed) status code.
709
710   Proxy servers using a cached response as the selected representation
711   MUST NOT perform the requested method if the condition is not met;
712   instead, they MUST forward the request towards the origin server.
713
714   Examples:
715
716     If-Match: "xyzzy"
717     If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
718     If-Match: *
719
720
721
722
723
724
725
726
727Fielding & Reschke       Expires August 27, 2013               [Page 13]
728
729Internet-Draft        HTTP/1.1 Conditional Requests        February 2013
730
731
7323.2.  If-None-Match
733
734   The "If-None-Match" header field can be used to make a request method
735   conditional on not matching any of the current entity-tag values for
736   representations of the target resource.
737
738   If-None-Match is primarily used in conditional GET requests to enable
739   efficient updates of cached information with a minimum amount of
740   transaction overhead.  A client that has one or more representations
741   previously obtained from the target resource can send If-None-Match
742   with a list of the associated entity-tags in the hope of receiving a
743   304 (Not Modified) response if at least one of those representations
744   matches the selected representation.
745
746   If-None-Match can also be used with a value of "*" to prevent an
747   unsafe request method (e.g., PUT) from inadvertently modifying an
748   existing representation of the target resource when the client
749   believes that the resource does not have a current representation.
750   This is a variation on the "lost update" problem that might arise if
751   more than one client attempts to create an initial representation for
752   the target resource.
753
754     If-None-Match = "*" / 1#entity-tag
755
756   The If-None-Match condition is met if and only if none of the entity-
757   tags listed in the If-None-Match field value match the entity-tag of
758   the selected representation using the weak comparison function (as
759   per Section 2.3.2), or if "*" is given and no current representation
760   exists for that resource.
761
762   If the condition is not met, the server MUST NOT perform the
763   requested method.  Instead, if the request method was GET or HEAD,
764   the server SHOULD respond with a 304 (Not Modified) status code,
765   including the cache-related header fields (particularly ETag) of the
766   selected representation that has a matching entity-tag.  For all
767   other request methods, the server MUST respond with a 412
768   (Precondition Failed) status code when the condition is not met.
769
770   If the condition is met, the server MAY perform the requested method
771   and MUST ignore any If-Modified-Since header field(s) in the request.
772   That is, if no entity-tags match, then the server MUST NOT send a 304
773   (Not Modified) response.
774
775   Examples:
776
777
778
779
780
781
782
783Fielding & Reschke       Expires August 27, 2013               [Page 14]
784
785Internet-Draft        HTTP/1.1 Conditional Requests        February 2013
786
787
788     If-None-Match: "xyzzy"
789     If-None-Match: W/"xyzzy"
790     If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
791     If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
792     If-None-Match: *
793
7943.3.  If-Modified-Since
795
796   The "If-Modified-Since" header field can be used with GET or HEAD to
797   make the method conditional by modification date: if the selected
798   representation has not been modified since the time specified in this
799   field, then do not perform the request method; instead, respond as
800   detailed below.
801
802     If-Modified-Since = HTTP-date
803
804   An example of the field is:
805
806     If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
807
808   A GET method with an If-Modified-Since header field and no Range
809   header field requests that the selected representation be transferred
810   only if it has been modified since the date given by the If-Modified-
811   Since header field.  The algorithm for determining this includes the
812   following cases:
813
814   1.  If the request would normally result in anything other than a 200
815       (OK) status code, or if the passed If-Modified-Since date is
816       invalid, the response is exactly the same as for a normal GET.  A
817       date that is later than the server's current time is invalid.
818
819   2.  If the selected representation has been modified since the If-
820       Modified-Since date, the response is exactly the same as for a
821       normal GET.
822
823   3.  If the selected representation has not been modified since a
824       valid If-Modified-Since date, the server SHOULD send a 304 (Not
825       Modified) response.
826
827   The two purposes of this feature are to allow efficient updates of
828   cached information, with a minimum amount of transaction overhead,
829   and to limit the scope of a web traversal to resources that have
830   recently changed.
831
832   When used for cache updates, a cache will typically use the value of
833   the cached message's Last-Modified field to generate the field value
834   of If-Modified-Since.  This behavior is most interoperable for cases
835   where clocks are poorly synchronized or when the server has chosen to
836
837
838
839Fielding & Reschke       Expires August 27, 2013               [Page 15]
840
841Internet-Draft        HTTP/1.1 Conditional Requests        February 2013
842
843
844   only honor exact timestamp matches (due to a problem with Last-
845   Modified dates that appear to go "back in time" when the origin
846   server's clock is corrected or a representation is restored from an
847   archived backup).  However, caches occasionally generate the field
848   value based on other data, such as the Date header field of the
849   cached message or the local clock time that the message was received,
850   particularly when the cached message does not contain a Last-Modified
851   field.
852
853   When used for limiting the scope of retrieval to a recent time
854   window, a user agent will generate an If-Modified-Since field value
855   based on either its own local clock or a Date header field received
856   from the server during a past run.  Origin servers that choose an
857   exact timestamp match based on the selected representation's Last-
858   Modified field will not be able to help the user agent limit its data
859   transfers to only those changed during the specified window.
860
861      Note: If a client uses an arbitrary date in the If-Modified-Since
862      header field instead of a date taken from a Last-Modified or Date
863      header field from the origin server, the client ought to be aware
864      that its date will be interpreted according to the server's
865      understanding of time.
866
8673.4.  If-Unmodified-Since
868
869   The "If-Unmodified-Since" header field can be used to make a request
870   method conditional by modification date: if the selected
871   representation has been modified since the time specified in this
872   field, then the server MUST NOT perform the requested operation and
873   MUST instead respond with the 412 (Precondition Failed) status code.
874   If the selected representation has not been modified since the time
875   specified in this field, the server MAY perform the request.
876
877     If-Unmodified-Since = HTTP-date
878
879   An example of the field is:
880
881     If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
882
883   A server MUST ignore the If-Unmodified-Since header field if the
884   received value is not a valid HTTP-date.
885
8863.5.  If-Range
887
888   The "If-Range" header field provides a special conditional request
889   mechanism that is similar to If-Match and If-Unmodified-Since but
890   specific to range requests.  If-Range is defined in Section 3.2 of
891   [Part5].
892
893
894
895Fielding & Reschke       Expires August 27, 2013               [Page 16]
896
897Internet-Draft        HTTP/1.1 Conditional Requests        February 2013
898
899
9004.  Status Code Definitions
901
9024.1.  304 Not Modified
903
904   The 304 (Not Modified) status code indicates that a conditional GET
905   request has been received and would have resulted in a 200 (OK)
906   response if it were not for the fact that the condition has evaluated
907   to false.  In other words, there is no need for the server to
908   transfer a representation of the target resource because the request
909   indicates that the client, which made the request conditional,
910   already has a valid representation; the server is therefore
911   redirecting the client to make use of that stored representation as
912   if it were the payload of a 200 (OK) response.
913
914   The server generating a 304 response MUST generate any of the
915   following header fields that would have been sent in a 200 (OK)
916   response to the same request: Cache-Control, Content-Location, ETag,
917   Expires, and Vary.
918
919   Since the goal of a 304 response is to minimize information transfer
920   when the recipient already has one or more cached representations, a
921   sender SHOULD NOT generate representation metadata other than the
922   above listed fields unless said metadata exists for the purpose of
923   guiding cache updates (e.g., Last-Modified might be useful if the
924   response does not have an ETag field).
925
926   Requirements on a cache that receives a 304 response are defined in
927   Section 4.2.1 of [Part6].  If the conditional request originated with
928   an outbound client, such as a user agent with its own cache sending a
929   conditional GET to a shared proxy, then the proxy SHOULD forward the
930   304 response to that client.
931
932   A 304 response cannot contain a message-body; it is always terminated
933   by the first empty line after the header fields.
934
9354.2.  412 Precondition Failed
936
937   The 412 (Precondition Failed) status code indicates that one or more
938   preconditions given in the request header fields evaluated to false
939   when tested on the server.  This response code allows the client to
940   place preconditions on the current resource state (its current
941   representations and metadata) and thus prevent the request method
942   from being applied if the target resource is in an unexpected state.
943
9445.  Evaluation and Precedence
945
946   For each conditional request, a server MUST evaluate the request
947   preconditions after it has successfully performed its normal request
948
949
950
951Fielding & Reschke       Expires August 27, 2013               [Page 17]
952
953Internet-Draft        HTTP/1.1 Conditional Requests        February 2013
954
955
956   checks (i.e., just before it would perform the action associated with
957   the request method).  Preconditions are ignored if the server
958   determines that an error or redirect response applies before they are
959   evaluated.  Otherwise, the evaluation depends on both the method
960   semantics and the choice of conditional.
961
962   A conditional request header field that is designed specifically for
963   cache validation, which includes If-None-Match and If-Modified-Since
964   when used in a GET or HEAD request, allows cached representations to
965   be refreshed without repeatedly transferring data already held by the
966   client.  Evaluating to false is thus an indication that the client
967   can continue to use its local copy of the selected representation, as
968   indicated by the server generating a 304 (Not Modified) response that
969   includes only those header fields useful for refreshing the cached
970   representation.
971
972   All other conditionals are intended to signal failure when the
973   precondition evaluates to false.  For example, an If-Match
974   conditional sent with a state-changing method (e.g., POST, PUT,
975   DELETE) is intended to prevent the request from taking effect on the
976   target resource if the resource state does not match the expected
977   state.  In other words, evaluating the condition to false means that
978   the resource has been changed by some other client, perhaps by
979   another user attempting to edit the same resource, and thus
980   preventing the request from being applied saves the client from
981   overwriting some other client's work.  This result is indicated by
982   the server generating a 412 (Precondition Failed) response.
983
984   The conditional request header fields defined by this specification
985   are ignored for request methods that never involve the selection or
986   modification of a selected representation (e.g., CONNECT, OPTIONS,
987   and TRACE).  Other conditional request header fields, defined by
988   extensions to HTTP, might place conditions on the state of the target
989   resource in general, or on a group of resources.  For instance, the
990   If header field in WebDAV can make a request conditional on various
991   aspects (such as locks) of multiple resources ([RFC4918], Section
992   10.4).
993
994   When more than one conditional request header field is present in a
995   request, the order in which the fields are evaluated becomes
996   important.  In practice, the fields defined in this document are
997   consistently implemented in a single, logical order, due to the fact
998   that entity tags are presumed to be more accurate than date
999   validators.  For example, the only reason to send both If-Modified-
1000   Since and If-None-Match in the same GET request is to support
1001   intermediary caches that might not have implemented If-None-Match, so
1002   it makes sense to ignore the If-Modified-Since when entity tags are
1003   understood and available for the selected representation.
1004
1005
1006
1007Fielding & Reschke       Expires August 27, 2013               [Page 18]
1008
1009Internet-Draft        HTTP/1.1 Conditional Requests        February 2013
1010
1011
1012   The general rule of conditional precedence is that exact match
1013   conditions are evaluated before cache-validating conditions and,
1014   within that order, last-modified conditions are only evaluated if the
1015   corresponding entity tag condition is not present (or not applicable
1016   because the selected representation does not have an entity tag).
1017
1018   Specifically, the fields defined by this specification are evaluated
1019   as follows:
1020
1021   1.  When If-Match is present, evaluate it:
1022
1023       *  if true, continue to step 3
1024
1025       *  if false, respond 412 (Precondition Failed)
1026
1027   2.  When If-Match is not present and If-Unmodified-Since is present,
1028       evaluate it:
1029
1030       *  if true, continue to step 3
1031
1032       *  if false, respond 412 (Precondition Failed)
1033
1034   3.  When If-None-Match is present, evaluate it:
1035
1036       *  if true, continue to step 5
1037
1038       *  if false for GET/HEAD, respond 304 (Not Modified)
1039
1040       *  if false for other methods, respond 412 (Precondition Failed)
1041
1042   4.  When the method is GET or HEAD, If-None-Match is not present, and
1043       If-Modified-Since is present, evaluate it:
1044
1045       *  if true, continue to step 5
1046
1047       *  if false, respond 304 (Not Modified)
1048
1049   5.  When the method is GET and both Range and If-Range are present,
1050       evaluate If-Range:
1051
1052       *  if the validator matches and the Range specification is
1053          applicable to the selected representation, respond 206
1054          (Partial Content) [Part5]
1055
1056   6.  Otherwise,
1057
1058       *  all conditions are met, so perform the requested action and
1059          respond according to its success or failure.
1060
1061
1062
1063Fielding & Reschke       Expires August 27, 2013               [Page 19]
1064
1065Internet-Draft        HTTP/1.1 Conditional Requests        February 2013
1066
1067
1068   Any extension to HTTP/1.1 that defines additional conditional request
1069   header fields ought to define its own expectations regarding the
1070   order for evaluating such fields in relation to those defined in this
1071   document and other conditionals that might be found in practice.
1072
10736.  IANA Considerations
1074
10756.1.  Status Code Registration
1076
1077   The HTTP Status Code Registry located at
1078   <http://www.iana.org/assignments/http-status-codes> shall be updated
1079   with the registrations below:
1080
1081   +-------+---------------------+-------------+
1082   | Value | Description         | Reference   |
1083   +-------+---------------------+-------------+
1084   | 304   | Not Modified        | Section 4.1 |
1085   | 412   | Precondition Failed | Section 4.2 |
1086   +-------+---------------------+-------------+
1087
10886.2.  Header Field Registration
1089
1090   The Message Header Field Registry located at <http://www.iana.org/
1091   assignments/message-headers/message-header-index.html> shall be
1092   updated with the permanent registrations below (see [BCP90]):
1093
1094   +---------------------+----------+----------+-------------+
1095   | Header Field Name   | Protocol | Status   | Reference   |
1096   +---------------------+----------+----------+-------------+
1097   | ETag                | http     | standard | Section 2.3 |
1098   | If-Match            | http     | standard | Section 3.1 |
1099   | If-Modified-Since   | http     | standard | Section 3.3 |
1100   | If-None-Match       | http     | standard | Section 3.2 |
1101   | If-Unmodified-Since | http     | standard | Section 3.4 |
1102   | Last-Modified       | http     | standard | Section 2.2 |
1103   +---------------------+----------+----------+-------------+
1104
1105   The change controller is: "IETF (iesg@ietf.org) - Internet
1106   Engineering Task Force".
1107
11087.  Security Considerations
1109
1110   This section is meant to inform developers, information providers,
1111   and users of known security concerns specific to the HTTP/1.1
1112   conditional request mechanisms.  More general security considerations
1113   are addressed in HTTP messaging [Part1] and semantics [Part2].
1114
1115   The validators defined by this specification are not intended to
1116
1117
1118
1119Fielding & Reschke       Expires August 27, 2013               [Page 20]
1120
1121Internet-Draft        HTTP/1.1 Conditional Requests        February 2013
1122
1123
1124   ensure the validity of a representation, guard against malicious
1125   changes, or detect man-in-the-middle attacks.  At best, they enable
1126   more efficient cache updates and optimistic concurrent writes when
1127   all participants are behaving nicely.  At worst, the conditions will
1128   fail and the client will receive a response that is no more harmful
1129   than an HTTP exchange without conditional requests.
1130
1131   An entity-tag can be abused in ways that create privacy risks.  For
1132   example, a site might deliberately construct a semantically invalid
1133   entity-tag that is unique to the user or user agent, send it in a
1134   cacheable response with a long freshness time, and then read that
1135   entity-tag in later conditional requests as a means of re-identifying
1136   that user or user agent.  Such an identifying tag would become a
1137   persistent identifier for as long as the user agent retained the
1138   original cache entry.  User agents that cache representations ought
1139   to ensure that the cache is cleared or replaced whenever the user
1140   performs privacy-maintaining actions, such as clearing stored cookies
1141   or changing to a private browsing mode.
1142
11438.  Acknowledgments
1144
1145   See Section 9 of [Part1].
1146
11479.  References
1148
11499.1.  Normative References
1150
1151   [Part1]    Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1152              Protocol (HTTP/1.1): Message Syntax and Routing",
1153              draft-ietf-httpbis-p1-messaging-22 (work in progress),
1154              February 2013.
1155
1156   [Part2]    Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1157              Protocol (HTTP/1.1): Semantics and Content",
1158              draft-ietf-httpbis-p2-semantics-22 (work in progress),
1159              February 2013.
1160
1161   [Part5]    Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
1162              "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
1163              draft-ietf-httpbis-p5-range-22 (work in progress),
1164              February 2013.
1165
1166   [Part6]    Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
1167              Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
1168              draft-ietf-httpbis-p6-cache-22 (work in progress),
1169              February 2013.
1170
1171   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
1172
1173
1174
1175Fielding & Reschke       Expires August 27, 2013               [Page 21]
1176
1177Internet-Draft        HTTP/1.1 Conditional Requests        February 2013
1178
1179
1180              Requirement Levels", BCP 14, RFC 2119, March 1997.
1181
1182   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
1183              Specifications: ABNF", STD 68, RFC 5234, January 2008.
1184
11859.2.  Informative References
1186
1187   [BCP90]    Klyne, G., Nottingham, M., and J. Mogul, "Registration
1188              Procedures for Message Header Fields", BCP 90, RFC 3864,
1189              September 2004.
1190
1191   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
1192              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
1193              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
1194
1195   [RFC4918]  Dusseault, L., Ed., "HTTP Extensions for Web Distributed
1196              Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
1197
1198Appendix A.  Changes from RFC 2616
1199
1200   The definition of validator weakness has been expanded and clarified.
1201   (Section 2.1)
1202
1203   Weak entity-tags are now allowed in all requests except range
1204   requests (Sections 2.1 and 3.2).
1205
1206   The ETag header field ABNF has been changed to not use quoted-string,
1207   thus avoiding escaping issues.  (Section 2.3)
1208
1209   ETag is defined to provide an entity tag for the selected
1210   representation, thereby clarifying what it applies to in various
1211   situations (such as a PUT response).  (Section 2.3)
1212
1213   The precedence for evaluation of conditional requests has been
1214   defined.  (Section 5)
1215
1216Appendix B.  Imported ABNF
1217
1218   The following core rules are included by reference, as defined in
1219   Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return),
1220   CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double
1221   quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any
1222   8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII
1223   character).
1224
1225   The rules below are defined in [Part1]:
1226
1227     OWS           = <OWS, defined in [Part1], Section 3.2.3>
1228
1229
1230
1231Fielding & Reschke       Expires August 27, 2013               [Page 22]
1232
1233Internet-Draft        HTTP/1.1 Conditional Requests        February 2013
1234
1235
1236     obs-text      = <obs-text, defined in [Part1], Section 3.2.6>
1237
1238   The rules below are defined in other parts:
1239
1240     HTTP-date     = <HTTP-date, defined in [Part2], Section 7.1.1.1>
1241
1242Appendix C.  Collected ABNF
1243
1244   ETag = entity-tag
1245
1246   HTTP-date = <HTTP-date, defined in [Part2], Section 7.1.1.1>
1247
1248   If-Match = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS
1249    entity-tag ] ) )
1250   If-Modified-Since = HTTP-date
1251   If-None-Match = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS
1252    entity-tag ] ) )
1253   If-Unmodified-Since = HTTP-date
1254
1255   Last-Modified = HTTP-date
1256
1257   OWS = <OWS, defined in [Part1], Section 3.2.3>
1258
1259   entity-tag = [ weak ] opaque-tag
1260   etagc = "!" / %x23-7E ; '#'-'~'
1261    / obs-text
1262
1263   obs-text = <obs-text, defined in [Part1], Section 3.2.6>
1264   opaque-tag = DQUOTE *etagc DQUOTE
1265
1266   weak = %x57.2F ; W/
1267
1268Appendix D.  Change Log (to be removed by RFC Editor before publication)
1269
1270   Changes up to the first Working Group Last Call draft are summarized
1271   in <http://tools.ietf.org/html/
1272   draft-ietf-httpbis-p4-conditional-19#appendix-C>.
1273
1274D.1.  Since draft-ietf-httpbis-p4-conditional-19
1275
1276   Closed issues:
1277
1278   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/241>: "Need to
1279      clarify eval order/interaction of conditional headers"
1280
1281   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/345>: "Required
1282      headers on 304 and 206"
1283
1284
1285
1286
1287Fielding & Reschke       Expires August 27, 2013               [Page 23]
1288
1289Internet-Draft        HTTP/1.1 Conditional Requests        February 2013
1290
1291
1292   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/350>: "Optionality
1293      of Conditional Request Support"
1294
1295   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/354>: "ETags and
1296      Conditional Requests"
1297
1298   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/361>: "ABNF
1299      requirements for recipients"
1300
1301   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/363>: "Rare cases"
1302
1303   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/365>: "Conditional
1304      Request Security Considerations"
1305
1306   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/371>: "If-Modified-
1307      Since lacks definition for method != GET"
1308
1309   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/372>: "refactor
1310      conditional header field descriptions"
1311
1312D.2.  Since draft-ietf-httpbis-p4-conditional-20
1313
1314   o  Conformance criteria and considerations regarding error handling
1315      are now defined in Part 1.
1316
1317D.3.  Since draft-ietf-httpbis-p4-conditional-21
1318
1319   Closed issues:
1320
1321   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/96>: "Conditional
1322      GET text"
1323
1324   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/350>: "Optionality
1325      of Conditional Request Support"
1326
1327   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/384>: "unclear prose
1328      in definition of 304"
1329
1330   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/401>: "ETags and
1331      Conneg"
1332
1333   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/402>: "Comparison
1334      function for If-Match and If-None-Match"
1335
1336   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/406>: "304 without
1337      validator"
1338
1339
1340
1341
1342
1343Fielding & Reschke       Expires August 27, 2013               [Page 24]
1344
1345Internet-Draft        HTTP/1.1 Conditional Requests        February 2013
1346
1347
1348   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/427>: "If-Match and
1349      428"
1350
1351Index
1352
1353   3
1354      304 Not Modified (status code)  17
1355
1356   4
1357      412 Precondition Failed (status code)  17
1358
1359   E
1360      ETag header field  9
1361
1362   G
1363      Grammar
1364         entity-tag  9
1365         ETag  9
1366         etagc  9
1367         If-Match  13
1368         If-Modified-Since  15
1369         If-None-Match  14
1370         If-Unmodified-Since  16
1371         Last-Modified  7
1372         opaque-tag  9
1373         weak  9
1374
1375   I
1376      If-Match header field  13
1377      If-Modified-Since header field  15
1378      If-None-Match header field  14
1379      If-Unmodified-Since header field  16
1380
1381   L
1382      Last-Modified header field  7
1383
1384   M
1385      metadata  5
1386
1387   S
1388      selected representation  4
1389
1390   V
1391      validator  5
1392         strong  5
1393         weak  5
1394
1395
1396
1397
1398
1399Fielding & Reschke       Expires August 27, 2013               [Page 25]
1400
1401Internet-Draft        HTTP/1.1 Conditional Requests        February 2013
1402
1403
1404Authors' Addresses
1405
1406   Roy T. Fielding (editor)
1407   Adobe Systems Incorporated
1408   345 Park Ave
1409   San Jose, CA  95110
1410   USA
1411
1412   EMail: fielding@gbiv.com
1413   URI:   http://roy.gbiv.com/
1414
1415
1416   Julian F. Reschke (editor)
1417   greenbytes GmbH
1418   Hafenweg 16
1419   Muenster, NW  48155
1420   Germany
1421
1422   EMail: julian.reschke@greenbytes.de
1423   URI:   http://greenbytes.de/tech/webdav/
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455Fielding & Reschke       Expires August 27, 2013               [Page 26]
1456
Note: See TracBrowser for help on using the repository browser.