source: draft-ietf-httpbis/21/draft-ietf-httpbis-p4-conditional-21.txt @ 2650

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

prepare release of -21 drafts on Oct 4

  • Property svn:eol-style set to native
  • Property svn:executable set to *
File size: 52.4 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: April 7, 2013                                   October 4, 2012
9
10
11      Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
12                  draft-ietf-httpbis-p4-conditional-21
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.2.
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 April 7, 2013                 [Page 1]
56
57Internet-Draft        HTTP/1.1 Conditional Requests         October 2012
58
59
60   This Internet-Draft will expire on April 7, 2013.
61
62Copyright Notice
63
64   Copyright (c) 2012 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 April 7, 2013                 [Page 2]
112
113Internet-Draft        HTTP/1.1 Conditional Requests         October 2012
114
115
116Table of Contents
117
118   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
119     1.1.  Conformance and Error Handling . . . . . . . . . . . . . .  4
120     1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  5
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.  Rules for When to Use Entity-tags and Last-Modified
132           Dates  . . . . . . . . . . . . . . . . . . . . . . . . . . 12
133   3.  Precondition Header Fields . . . . . . . . . . . . . . . . . . 13
134     3.1.  If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 13
135     3.2.  If-None-Match  . . . . . . . . . . . . . . . . . . . . . . 14
136     3.3.  If-Modified-Since  . . . . . . . . . . . . . . . . . . . . 16
137     3.4.  If-Unmodified-Since  . . . . . . . . . . . . . . . . . . . 17
138     3.5.  If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 17
139   4.  Status Code Definitions  . . . . . . . . . . . . . . . . . . . 18
140     4.1.  304 Not Modified . . . . . . . . . . . . . . . . . . . . . 18
141     4.2.  412 Precondition Failed  . . . . . . . . . . . . . . . . . 18
142   5.  Precedence . . . . . . . . . . . . . . . . . . . . . . . . . . 19
143   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
144     6.1.  Status Code Registration . . . . . . . . . . . . . . . . . 20
145     6.2.  Header Field Registration  . . . . . . . . . . . . . . . . 20
146   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
147   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 21
148   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
149     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 21
150     9.2.  Informative References . . . . . . . . . . . . . . . . . . 22
151   Appendix A.  Changes from RFC 2616 . . . . . . . . . . . . . . . . 22
152   Appendix B.  Imported ABNF . . . . . . . . . . . . . . . . . . . . 22
153   Appendix C.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 23
154   Appendix D.  Change Log (to be removed by RFC Editor before
155                publication)  . . . . . . . . . . . . . . . . . . . . 23
156     D.1.  Since draft-ietf-httpbis-p4-conditional-19 . . . . . . . . 23
157     D.2.  Since draft-ietf-httpbis-p4-conditional-20 . . . . . . . . 24
158   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
159
160
161
162
163
164
165
166
167Fielding & Reschke        Expires April 7, 2013                 [Page 3]
168
169Internet-Draft        HTTP/1.1 Conditional Requests         October 2012
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.  Each
177   precondition is based on metadata that is expected to change if the
178   selected representation of the target resource is changed.  This
179   document defines the HTTP/1.1 conditional request mechanisms in terms
180   of the architecture, syntax notation, and conformance criteria
181   defined in [Part1].
182
183   Conditional GET requests are the most efficient mechanism for HTTP
184   cache updates [Part6].  Conditionals can also be applied to state-
185   changing methods, such as PUT and DELETE, to prevent the "lost
186   update" problem: one client accidentally overwriting the work of
187   another client that has been acting in parallel.
188
189   Conditional request preconditions are based on the state of the
190   target resource as a whole (its current value set) or the state as
191   observed in a previously obtained representation (one value in that
192   set).  A resource might have multiple current representations, each
193   with its own observable state.  The conditional request mechanisms
194   assume that the mapping of requests to corresponding representations
195   will be consistent over time if the server intends to take advantage
196   of conditionals.  Regardless, if the mapping is inconsistent and the
197   server is unable to select the appropriate representation, then no
198   harm will result when the precondition evaluates to false.
199
200   We use the term "selected representation" to refer to the current
201   representation of the target resource that would have been selected
202   in a successful response if the same request had used the method GET
203   and had excluded all of the conditional request header fields.  The
204   conditional request preconditions are evaluated by comparing the
205   values provided in the request header fields to the current metadata
206   for the selected representation.
207
2081.1.  Conformance and Error Handling
209
210   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
211   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
212   document are to be interpreted as described in [RFC2119].
213
214   Conformance criteria and considerations regarding error handling are
215   defined in Section 2.5 of [Part1].
216
217
218
219
220
221
222
223Fielding & Reschke        Expires April 7, 2013                 [Page 4]
224
225Internet-Draft        HTTP/1.1 Conditional Requests         October 2012
226
227
2281.2.  Syntax Notation
229
230   This specification uses the Augmented Backus-Naur Form (ABNF)
231   notation of [RFC5234] with the list rule extension defined in Section
232   1.2 of [Part1].  Appendix B describes rules imported from other
233   documents.  Appendix C shows the collected ABNF with the list rule
234   expanded.
235
2362.  Validators
237
238   This specification defines two forms of metadata that are commonly
239   used to observe resource state and test for preconditions:
240   modification dates (Section 2.2) and opaque entity tags
241   (Section 2.3).  Additional metadata that reflects resource state has
242   been defined by various extensions of HTTP, such as WebDAV [RFC4918],
243   that are beyond the scope of this specification.  A resource metadata
244   value is referred to as a "validator" when it is used within a
245   precondition.
246
2472.1.  Weak versus Strong
248
249   Validators come in two flavors: strong or weak.  Weak validators are
250   easy to generate but are far less useful for comparisons.  Strong
251   validators are ideal for comparisons but can be very difficult (and
252   occasionally impossible) to generate efficiently.  Rather than impose
253   that all forms of resource adhere to the same strength of validator,
254   HTTP exposes the type of validator in use and imposes restrictions on
255   when weak validators can be used as preconditions.
256
257   A "strong validator" is a representation metadata value that MUST be
258   changed to a new, previously unused or guaranteed unique, value
259   whenever a change occurs to the representation data such that a
260   change would be observable in the payload body of a 200 (OK) response
261   to GET.
262
263   A strong validator MAY be changed for other reasons, such as when a
264   semantically significant part of the representation metadata is
265   changed (e.g., Content-Type), but it is in the best interests of the
266   origin server to only change the value when it is necessary to
267   invalidate the stored responses held by remote caches and authoring
268   tools.  A strong validator MUST be unique across all representations
269   of a given resource, such that no two representations of that
270   resource share the same validator unless their payload body would be
271   identical.
272
273   Cache entries might persist for arbitrarily long periods, regardless
274   of expiration times.  Thus, a cache might attempt to validate an
275   entry using a validator that it obtained in the distant past.  A
276
277
278
279Fielding & Reschke        Expires April 7, 2013                 [Page 5]
280
281Internet-Draft        HTTP/1.1 Conditional Requests         October 2012
282
283
284   strong validator MUST be unique across all versions of all
285   representations associated with a particular resource over time.
286   However, there is no implication of uniqueness across representations
287   of different resources (i.e., the same strong validator might be in
288   use for representations of multiple resources at the same time and
289   does not imply that those representations are equivalent).
290
291   There are a variety of strong validators used in practice.  The best
292   are based on strict revision control, wherein each change to a
293   representation always results in a unique node name and revision
294   identifier being assigned before the representation is made
295   accessible to GET.  A collision-resistant hash function applied to
296   the representation data is also sufficient if the data is available
297   prior to the response header fields being sent and the digest does
298   not need to be recalculated every time a validation request is
299   received.  However, if a resource has distinct representations that
300   differ only in their metadata, such as might occur with content
301   negotiation over media types that happen to share the same data
302   format, then the origin server SHOULD incorporate additional
303   information in the validator to distinguish those representations and
304   avoid confusing cache behavior.
305
306   In contrast, a "weak validator" is a representation metadata value
307   that might not be changed for every change to the representation
308   data.  This weakness might be due to limitations in how the value is
309   calculated, such as clock resolution or an inability to ensure
310   uniqueness for all possible representations of the resource, or due
311   to a desire by the resource owner to group representations by some
312   self-determined set of equivalency rather than unique sequences of
313   data.  An origin server SHOULD change a weak entity-tag whenever it
314   considers prior representations to be unacceptable as a substitute
315   for the current representation.  In other words, a weak entity-tag
316   ought to change whenever the origin server wants caches to invalidate
317   old responses.
318
319   For example, the representation of a weather report that changes in
320   content every second, based on dynamic measurements, might be grouped
321   into sets of equivalent representations (from the origin server's
322   perspective) with the same weak validator in order to allow cached
323   representations to be valid for a reasonable period of time (perhaps
324   adjusted dynamically based on server load or weather quality).
325   Likewise, a representation's modification time, if defined with only
326   one-second resolution, might be a weak validator if it is possible
327   for the representation to be modified twice during a single second
328   and retrieved between those modifications.
329
330   A "use" of a validator occurs when either a client generates a
331   request and includes the validator in a precondition or when a server
332
333
334
335Fielding & Reschke        Expires April 7, 2013                 [Page 6]
336
337Internet-Draft        HTTP/1.1 Conditional Requests         October 2012
338
339
340   compares two validators.  Weak validators are only usable in contexts
341   that do not depend on exact equality of a representation's payload
342   body.  Strong validators are usable and preferred for all conditional
343   requests, including cache validation, partial content ranges, and
344   "lost update" avoidance.
345
3462.2.  Last-Modified
347
348   The "Last-Modified" header field indicates the date and time at which
349   the origin server believes the selected representation was last
350   modified.
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 April 7, 2013                 [Page 7]
392
393Internet-Draft        HTTP/1.1 Conditional Requests         October 2012
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 April 7, 2013                 [Page 8]
448
449Internet-Draft        HTTP/1.1 Conditional Requests         October 2012
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 provides the current entity-tag for the
460   selected representation.  An entity-tag is an opaque validator for
461   differentiating between multiple representations of the same
462   resource, regardless of whether those multiple representations are
463   due to resource state changes over time, content negotiation
464   resulting in multiple representations being valid at the same time,
465   or both.  An entity-tag consists of an opaque quoted string, possibly
466   prefixed by a weakness indicator.
467
468     ETag       = entity-tag
469
470     entity-tag = [ weak ] opaque-tag
471     weak       = %x57.2F ; "W/", case-sensitive
472     opaque-tag = DQUOTE *etagc DQUOTE
473     etagc      = %x21 / %x23-7E / obs-text
474                ; VCHAR except double quotes, plus obs-text
475
476      Note: Previously, opaque-tag was defined to be a quoted-string
477      ([RFC2616], Section 3.11), thus some recipients might perform
478      backslash unescaping.  Servers therefore ought to avoid backslash
479      characters in entity tags.
480
481   An entity-tag can be more reliable for validation than a modification
482   date in situations where it is inconvenient to store modification
483   dates, where the one-second resolution of HTTP date values is not
484   sufficient, or where modification dates are not consistently
485   maintained.
486
487   Examples:
488
489     ETag: "xyzzy"
490     ETag: W/"xyzzy"
491     ETag: ""
492
493   An entity-tag can be either a weak or strong validator, with strong
494   being the default.  If an origin server provides an entity-tag for a
495   representation and the generation of that entity-tag does not satisfy
496   the requirements for a strong validator (Section 2.1), then that
497   entity-tag MUST be marked as weak by prefixing its opaque value with
498   "W/" (case-sensitive).
499
500
501
502
503Fielding & Reschke        Expires April 7, 2013                 [Page 9]
504
505Internet-Draft        HTTP/1.1 Conditional Requests         October 2012
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  The strong comparison function: in order to be considered equal,
539      both opaque-tags MUST be identical character-by-character, and
540      both MUST NOT be weak.
541
542   o  The weak comparison function: in order to be considered equal,
543      both opaque-tags MUST be identical character-by-character, but
544      either or both of them MAY be tagged as "weak" without affecting
545      the result.
546
547   The example below shows the results for a set of entity-tag pairs,
548   and both the weak and strong comparison function results:
549
550
551
552
553
554
555
556
557
558
559Fielding & Reschke        Expires April 7, 2013                [Page 10]
560
561Internet-Draft        HTTP/1.1 Conditional Requests         October 2012
562
563
564   +--------+--------+-------------------+-----------------+
565   | ETag 1 | ETag 2 | Strong Comparison | Weak Comparison |
566   +--------+--------+-------------------+-----------------+
567   | W/"1"  | W/"1"  | no match          | match           |
568   | W/"1"  | W/"2"  | no match          | no match        |
569   | W/"1"  | "1"    | no match          | match           |
570   | "1"    | "1"    | match             | match           |
571   +--------+--------+-------------------+-----------------+
572
5732.3.3.  Example: Entity-tags varying on Content-Negotiated Resources
574
575   Consider a resource that is subject to content negotiation (Section
576   3.4 of [Part2]), and where the representations returned upon a GET
577   request vary based on the Accept-Encoding request header field
578   (Section 6.3.4 of [Part2]):
579
580   >> Request:
581
582     GET /index HTTP/1.1
583     Host: www.example.com
584     Accept-Encoding: gzip
585
586
587   In this case, the response might or might not use the gzip content
588   coding.  If it does not, the response might look like:
589
590   >> Response:
591
592     HTTP/1.1 200 OK
593     Date: Thu, 26 Mar 2010 00:05:00 GMT
594     ETag: "123-a"
595     Content-Length: 70
596     Vary: Accept-Encoding
597     Content-Type: text/plain
598
599     Hello World!
600     Hello World!
601     Hello World!
602     Hello World!
603     Hello World!
604
605   An alternative representation that does use gzip content coding would
606   be:
607
608
609
610
611
612
613
614
615Fielding & Reschke        Expires April 7, 2013                [Page 11]
616
617Internet-Draft        HTTP/1.1 Conditional Requests         October 2012
618
619
620   >> Response:
621
622     HTTP/1.1 200 OK
623     Date: Thu, 26 Mar 2010 00:05:00 GMT
624     ETag: "123-b"
625     Content-Length: 43
626     Vary: Accept-Encoding
627     Content-Type: text/plain
628     Content-Encoding: gzip
629
630     ...binary data...
631
632      Note: Content codings are a property of the representation, so
633      therefore an entity-tag of an encoded representation has to be
634      distinct from an unencoded representation to prevent conflicts
635      during cache updates and range requests.  In contrast, transfer
636      codings (Section 4 of [Part1]) apply only during message transfer
637      and do not require distinct entity-tags.
638
6392.4.  Rules for When to Use Entity-tags and Last-Modified Dates
640
641   We adopt a set of rules and recommendations for origin servers,
642   clients, and caches regarding when various validator types ought to
643   be used, and for what purposes.
644
645   HTTP/1.1 origin servers:
646
647   o  SHOULD send an entity-tag validator unless it is not feasible to
648      generate one.
649
650   o  MAY send a weak entity-tag instead of a strong entity-tag, if
651      performance considerations support the use of weak entity-tags, or
652      if it is unfeasible to send a strong entity-tag.
653
654   o  SHOULD send a Last-Modified value if it is feasible to send one.
655
656   In other words, the preferred behavior for an HTTP/1.1 origin server
657   is to send both a strong entity-tag and a Last-Modified value.
658
659   HTTP/1.1 clients:
660
661   o  MUST use that entity-tag in any cache-conditional request (using
662      If-Match or If-None-Match) if an entity-tag has been provided by
663      the origin server.
664
665   o  SHOULD use the Last-Modified value in non-subrange cache-
666      conditional requests (using If-Modified-Since) if only a Last-
667      Modified value has been provided by the origin server.
668
669
670
671Fielding & Reschke        Expires April 7, 2013                [Page 12]
672
673Internet-Draft        HTTP/1.1 Conditional Requests         October 2012
674
675
676   o  MAY use the Last-Modified value in subrange cache-conditional
677      requests (using If-Unmodified-Since) if only a Last-Modified value
678      has been provided by an HTTP/1.0 origin server.  The user agent
679      SHOULD provide a way to disable this, in case of difficulty.
680
681   o  SHOULD use both validators in cache-conditional requests if both
682      an entity-tag and a Last-Modified value have been provided by the
683      origin server.  This allows both HTTP/1.0 and HTTP/1.1 caches to
684      respond appropriately.
685
686   An HTTP/1.1 origin server, upon receiving a conditional request that
687   includes both a Last-Modified date (e.g., in an If-Modified-Since or
688   If-Unmodified-Since header field) and one or more entity-tags (e.g.,
689   in an If-Match, If-None-Match, or If-Range header field) as cache
690   validators, MUST NOT return a response status code of 304 (Not
691   Modified) unless doing so is consistent with all of the conditional
692   header fields in the request.
693
694   An HTTP/1.1 caching proxy, upon receiving a conditional request that
695   includes both a Last-Modified date and one or more entity-tags as
696   cache validators, MUST NOT return a locally cached response to the
697   client unless that cached response is consistent with all of the
698   conditional header fields in the request.
699
700      Note: The general principle behind these rules is that HTTP/1.1
701      servers and clients ought to transmit as much non-redundant
702      information as is available in their responses and requests.
703      HTTP/1.1 systems receiving this information will make the most
704      conservative assumptions about the validators they receive.
705
706      HTTP/1.0 clients and caches might ignore entity-tags.  Generally,
707      last-modified values received or used by these systems will
708      support transparent and efficient caching, and so HTTP/1.1 origin
709      servers still ought to provide Last-Modified values.
710
7113.  Precondition Header Fields
712
713   This section defines the syntax and semantics of HTTP/1.1 header
714   fields for applying preconditions on requests.  Section 5 defines the
715   order of evaluation when more than one precondition is present in a
716   request.
717
7183.1.  If-Match
719
720   The "If-Match" header field can be used to make a request method
721   conditional on the current existence or value of an entity-tag for
722   one or more representations of the target resource.
723
724
725
726
727Fielding & Reschke        Expires April 7, 2013                [Page 13]
728
729Internet-Draft        HTTP/1.1 Conditional Requests         October 2012
730
731
732   If-Match is generally useful for resource update requests, such as
733   PUT requests, as a means for protecting against accidental overwrites
734   when multiple clients are acting in parallel on the same resource
735   (i.e., the "lost update" problem).  An If-Match field-value of "*"
736   places the precondition on the existence of any current
737   representation for the target resource.
738
739     If-Match = "*" / 1#entity-tag
740
741   The If-Match condition is met if and only if any of the entity-tags
742   listed in the If-Match field value match the entity-tag of the
743   selected representation for the target resource (as per
744   Section 2.3.2), or if "*" is given and any current representation
745   exists for the target resource.
746
747   If the condition is met, the server MAY perform the request method as
748   if the If-Match header field was not present.
749
750   Origin servers MUST NOT perform the requested method if the condition
751   is not met; instead they MUST respond with the 412 (Precondition
752   Failed) status code.
753
754   Proxy servers using a cached response as the selected representation
755   MUST NOT perform the requested method if the condition is not met;
756   instead, they MUST forward the request towards the origin server.
757
758   If the request would, without the If-Match header field, result in
759   anything other than a 2xx (Successful) or 412 (Precondition Failed)
760   status code, then the If-Match header field MUST be ignored.
761
762   Examples:
763
764     If-Match: "xyzzy"
765     If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
766     If-Match: *
767
7683.2.  If-None-Match
769
770   The "If-None-Match" header field can be used to make a request method
771   conditional on not matching any of the current entity-tag values for
772   representations of the target resource.
773
774   If-None-Match is primarily used in conditional GET requests to enable
775   efficient updates of cached information with a minimum amount of
776   transaction overhead.  A client that has one or more representations
777   previously obtained from the target resource can send If-None-Match
778   with a list of the associated entity-tags in the hope of receiving a
779   304 (Not Modified) response if at least one of those representations
780
781
782
783Fielding & Reschke        Expires April 7, 2013                [Page 14]
784
785Internet-Draft        HTTP/1.1 Conditional Requests         October 2012
786
787
788   matches the selected representation.
789
790   If-None-Match can also be used with a value of "*" to prevent an
791   unsafe request method (e.g., PUT) from inadvertently modifying an
792   existing representation of the target resource when the client
793   believes that the resource does not have a current representation.
794   This is a variation on the "lost update" problem that might arise if
795   more than one client attempts to create an initial representation for
796   the target resource.
797
798     If-None-Match = "*" / 1#entity-tag
799
800   The If-None-Match condition is met if and only if none of the entity-
801   tags listed in the If-None-Match field value match the entity-tag of
802   the selected representation for the target resource (as per
803   Section 2.3.2), or if "*" is given and no current representation
804   exists for that resource.
805
806   If the condition is not met, the server MUST NOT perform the
807   requested method.  Instead, if the request method was GET or HEAD,
808   the server SHOULD respond with a 304 (Not Modified) status code,
809   including the cache-related header fields (particularly ETag) of the
810   selected representation that has a matching entity-tag.  For all
811   other request methods, the server MUST respond with a 412
812   (Precondition Failed) status code.
813
814   If the condition is met, the server MAY perform the requested method
815   as if the If-None-Match header field did not exist, but MUST also
816   ignore any If-Modified-Since header field(s) in the request.  That
817   is, if no entity-tags match, then the server MUST NOT return a 304
818   (Not Modified) response.
819
820   If the request would, without the If-None-Match header field, result
821   in anything other than a 2xx (Successful) or 304 (Not Modified)
822   status code, then the If-None-Match header field MUST be ignored.
823   (See Section 2.4 for a discussion of server behavior when both If-
824   Modified-Since and If-None-Match appear in the same request.)
825
826   Examples:
827
828     If-None-Match: "xyzzy"
829     If-None-Match: W/"xyzzy"
830     If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
831     If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
832     If-None-Match: *
833
834
835
836
837
838
839Fielding & Reschke        Expires April 7, 2013                [Page 15]
840
841Internet-Draft        HTTP/1.1 Conditional Requests         October 2012
842
843
8443.3.  If-Modified-Since
845
846   The "If-Modified-Since" header field can be used with GET or HEAD to
847   make the method conditional by modification date: if the selected
848   representation has not been modified since the time specified in this
849   field, then do not perform the request method; instead, respond as
850   detailed below.
851
852     If-Modified-Since = HTTP-date
853
854   An example of the field is:
855
856     If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
857
858   A GET method with an If-Modified-Since header field and no Range
859   header field requests that the selected representation be transferred
860   only if it has been modified since the date given by the If-Modified-
861   Since header field.  The algorithm for determining this includes the
862   following cases:
863
864   1.  If the request would normally result in anything other than a 200
865       (OK) status code, or if the passed If-Modified-Since date is
866       invalid, the response is exactly the same as for a normal GET.  A
867       date which is later than the server's current time is invalid.
868
869   2.  If the selected representation has been modified since the If-
870       Modified-Since date, the response is exactly the same as for a
871       normal GET.
872
873   3.  If the selected representation has not been modified since a
874       valid If-Modified-Since date, the server SHOULD return a 304 (Not
875       Modified) response.
876
877   The purpose of this feature is to allow efficient updates of cached
878   information with a minimum amount of transaction overhead.
879
880      Note: The Range header field modifies the meaning of If-Modified-
881      Since; see Section 5.4 of [Part5] for full details.
882
883      Note: If-Modified-Since times are interpreted by the server, whose
884      clock might not be synchronized with the client.
885
886      Note: When handling an If-Modified-Since header field, some
887      servers will use an exact date comparison function, rather than a
888      less-than function, for deciding whether to send a 304 (Not
889      Modified) response.  To get best results when sending an If-
890      Modified-Since header field for cache validation, clients are
891      advised to use the exact date string received in a previous Last-
892
893
894
895Fielding & Reschke        Expires April 7, 2013                [Page 16]
896
897Internet-Draft        HTTP/1.1 Conditional Requests         October 2012
898
899
900      Modified header field whenever possible.
901
902      Note: If a client uses an arbitrary date in the If-Modified-Since
903      header field instead of a date taken from the Last-Modified header
904      field for the same request, the client needs to be aware that this
905      date is interpreted in the server's understanding of time.
906      Unsynchronized clocks and rounding problems, due to the different
907      encodings of time between the client and server, are concerns.
908      This includes the possibility of race conditions if the document
909      has changed between the time it was first requested and the If-
910      Modified-Since date of a subsequent request, and the possibility
911      of clock-skew-related problems if the If-Modified-Since date is
912      derived from the client's clock without correction to the server's
913      clock.  Corrections for different time bases between client and
914      server are at best approximate due to network latency.
915
9163.4.  If-Unmodified-Since
917
918   The "If-Unmodified-Since" header field can be used to make a request
919   method conditional by modification date: if the selected
920   representation has been modified since the time specified in this
921   field, then the server MUST NOT perform the requested operation and
922   MUST instead respond with the 412 (Precondition Failed) status code.
923   If the selected representation has not been modified since the time
924   specified in this field, the server SHOULD perform the request method
925   as if the If-Unmodified-Since header field were not present.
926
927     If-Unmodified-Since = HTTP-date
928
929   An example of the field is:
930
931     If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
932
933   If a request normally (i.e., in absence of the If-Unmodified-Since
934   header field) would result in anything other than a 2xx (Successful)
935   or 412 (Precondition Failed) status code, the If-Unmodified-Since
936   header field SHOULD be ignored.
937
938   If the specified date is invalid, the header field MUST be ignored.
939
9403.5.  If-Range
941
942   The "If-Range" header field provides a special conditional request
943   mechanism that is similar to If-Match and If-Unmodified-Since but
944   specific to HTTP range requests.  If-Range is defined in Section 5.3
945   of [Part5].
946
947
948
949
950
951Fielding & Reschke        Expires April 7, 2013                [Page 17]
952
953Internet-Draft        HTTP/1.1 Conditional Requests         October 2012
954
955
9564.  Status Code Definitions
957
9584.1.  304 Not Modified
959
960   The 304 status code indicates that a conditional GET request has been
961   received and would have resulted in a 200 (OK) response if it were
962   not for the fact that the condition has evaluated to false.  In other
963   words, there is no need for the server to transfer a representation
964   of the target resource because the client's request indicates that it
965   already has a valid representation, as indicated by the 304 response
966   header fields, and is therefore redirecting the client to make use of
967   that stored representation as if it were the payload of a 200
968   response.  The 304 response MUST NOT contain a message-body, and thus
969   is always terminated by the first empty line after the header fields.
970
971   A 304 response MUST include a Date header field (Section 8.1.1.2 of
972   [Part2]) unless the origin server does not have a clock that can
973   provide a reasonable approximation of the current time.  If a 200
974   (OK) response to the same request would have included any of the
975   header fields Cache-Control, Content-Location, ETag, Expires, or
976   Vary, then those same header fields MUST be sent in a 304 response.
977
978   Since the goal of a 304 response is to minimize information transfer
979   when the recipient already has one or more cached representations,
980   the response SHOULD NOT include representation metadata other than
981   the above listed fields unless said metadata exists for the purpose
982   of guiding cache updates (e.g., future HTTP extensions).
983
984   If the recipient of a 304 response does not have a cached
985   representation corresponding to the entity-tag indicated by the 304
986   response, then the recipient MUST NOT use the 304 to update its own
987   cache.  If this conditional request originated with an outbound
988   client, such as a user agent with its own cache sending a conditional
989   GET to a shared proxy, then the 304 response MAY be forwarded to that
990   client.  Otherwise, the recipient MUST disregard the 304 response and
991   repeat the request without any preconditions.
992
993   If a cache uses a received 304 response to update a cache entry, the
994   cache MUST update the entry to reflect any new field values given in
995   the response.
996
9974.2.  412 Precondition Failed
998
999   The 412 status code indicates that one or more preconditions given in
1000   the request header fields evaluated to false when tested on the
1001   server.  This response code allows the client to place preconditions
1002   on the current resource state (its current representations and
1003   metadata) and thus prevent the request method from being applied if
1004
1005
1006
1007Fielding & Reschke        Expires April 7, 2013                [Page 18]
1008
1009Internet-Draft        HTTP/1.1 Conditional Requests         October 2012
1010
1011
1012   the target resource is in an unexpected state.
1013
10145.  Precedence
1015
1016   When more than one conditional request header field is present in a
1017   request, the order in which the fields are evaluated becomes
1018   important.  In practice, the fields defined in this document are
1019   consistently implemented in a single, logical order, due to the fact
1020   that entity tags are presumed to be more accurate than date
1021   validators.  For example, the only reason to send both If-Modified-
1022   Since and If-None-Match in the same GET request is to support
1023   intermediary caches that might not have implemented If-None-Match, so
1024   it makes sense to ignore the If-Modified-Since when entity tags are
1025   understood and available for the selected representation.
1026
1027   The general rule of conditional precedence is that exact match
1028   conditions are evaluated before cache-validating conditions and,
1029   within that order, last-modified conditions are only evaluated if the
1030   corresponding entity tag condition is not present (or not applicable
1031   because the selected representation does not have an entity tag).
1032
1033   Specifically, the fields defined by this specification are evaluated
1034   as follows:
1035
1036   1.  When If-Match is present, evaluate it:
1037
1038       *  if true, continue to step 3
1039
1040       *  if false, respond 412 (Precondition Failed)
1041
1042   2.  When If-Match is not present and If-Unmodified-Since is present,
1043       evaluate it:
1044
1045       *  if true, continue to step 3
1046
1047       *  if false, respond 412 (Precondition Failed)
1048
1049   3.  When the method is GET and both Range and If-Range are present,
1050       evaluate it:
1051
1052       *  if the validator matches, respond 206 (Partial Content)
1053
1054       *  if the validator does not match, respond 200 (OK)
1055
1056   4.  When If-None-Match is present, evaluate it:
1057
1058       *  if true, all conditions are met
1059
1060
1061
1062
1063Fielding & Reschke        Expires April 7, 2013                [Page 19]
1064
1065Internet-Draft        HTTP/1.1 Conditional Requests         October 2012
1066
1067
1068       *  if false for GET/HEAD, respond 304 (Not Modified)
1069
1070       *  if false for other methods, respond 412 (Precondition Failed)
1071
1072   5.  When the method is GET or HEAD, If-None-Match is not present, and
1073       If-Modified-Since is present, evaluate it:
1074
1075       *  if true, all conditions are met
1076
1077       *  if false, respond 304 (Not Modified)
1078
1079   Any extension to HTTP/1.1 that defines additional conditional request
1080   header fields ought to define its own expectations regarding the
1081   order for evaluating such fields in relation to those defined in this
1082   document and other conditionals that might be found in practice.
1083
10846.  IANA Considerations
1085
10866.1.  Status Code Registration
1087
1088   The HTTP Status Code Registry located at
1089   <http://www.iana.org/assignments/http-status-codes> shall be updated
1090   with the registrations below:
1091
1092   +-------+---------------------+-------------+
1093   | Value | Description         | Reference   |
1094   +-------+---------------------+-------------+
1095   | 304   | Not Modified        | Section 4.1 |
1096   | 412   | Precondition Failed | Section 4.2 |
1097   +-------+---------------------+-------------+
1098
10996.2.  Header Field Registration
1100
1101   The Message Header Field Registry located at <http://www.iana.org/
1102   assignments/message-headers/message-header-index.html> shall be
1103   updated with the permanent registrations below (see [RFC3864]):
1104
1105   +---------------------+----------+----------+-------------+
1106   | Header Field Name   | Protocol | Status   | Reference   |
1107   +---------------------+----------+----------+-------------+
1108   | ETag                | http     | standard | Section 2.3 |
1109   | If-Match            | http     | standard | Section 3.1 |
1110   | If-Modified-Since   | http     | standard | Section 3.3 |
1111   | If-None-Match       | http     | standard | Section 3.2 |
1112   | If-Unmodified-Since | http     | standard | Section 3.4 |
1113   | Last-Modified       | http     | standard | Section 2.2 |
1114   +---------------------+----------+----------+-------------+
1115
1116
1117
1118
1119Fielding & Reschke        Expires April 7, 2013                [Page 20]
1120
1121Internet-Draft        HTTP/1.1 Conditional Requests         October 2012
1122
1123
1124   The change controller is: "IETF (iesg@ietf.org) - Internet
1125   Engineering Task Force".
1126
11277.  Security Considerations
1128
1129   No additional security considerations have been identified beyond
1130   those applicable to HTTP in general [Part1].
1131
1132   The validators defined by this specification are not intended to
1133   ensure the validity of a representation, guard against malicious
1134   changes, or detect man-in-the-middle attacks.  At best, they enable
1135   more efficient cache updates and optimistic concurrent writes when
1136   all participants are behaving nicely.  At worst, the conditions will
1137   fail and the client will receive a response that is no more harmful
1138   than an HTTP exchange without conditional requests.
1139
11408.  Acknowledgments
1141
1142   See Section 9 of [Part1].
1143
11449.  References
1145
11469.1.  Normative References
1147
1148   [Part1]    Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1149              Protocol (HTTP/1.1): Message Syntax and Routing",
1150              draft-ietf-httpbis-p1-messaging-21 (work in progress),
1151              October 2012.
1152
1153   [Part2]    Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1154              Protocol (HTTP/1.1): Semantics and Content",
1155              draft-ietf-httpbis-p2-semantics-21 (work in progress),
1156              October 2012.
1157
1158   [Part5]    Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
1159              "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
1160              draft-ietf-httpbis-p5-range-21 (work in progress),
1161              October 2012.
1162
1163   [Part6]    Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
1164              Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
1165              draft-ietf-httpbis-p6-cache-21 (work in progress),
1166              October 2012.
1167
1168   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
1169              Requirement Levels", BCP 14, RFC 2119, March 1997.
1170
1171   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
1172
1173
1174
1175Fielding & Reschke        Expires April 7, 2013                [Page 21]
1176
1177Internet-Draft        HTTP/1.1 Conditional Requests         October 2012
1178
1179
1180              Specifications: ABNF", STD 68, RFC 5234, January 2008.
1181
11829.2.  Informative References
1183
1184   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
1185              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
1186              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
1187
1188   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
1189              Procedures for Message Header Fields", BCP 90, RFC 3864,
1190              September 2004.
1191
1192   [RFC4918]  Dusseault, L., Ed., "HTTP Extensions for Web Distributed
1193              Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
1194
1195Appendix A.  Changes from RFC 2616
1196
1197   Allow weak entity-tags in all requests except range requests
1198   (Sections 2.1 and 3.2).
1199
1200   Change "ETag" header field ABNF not to use quoted-string, thus
1201   avoiding escaping issues.  (Section 2.3)
1202
1203Appendix B.  Imported ABNF
1204
1205   The following core rules are included by reference, as defined in
1206   Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return),
1207   CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double
1208   quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any
1209   8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII
1210   character).
1211
1212   The rules below are defined in [Part1]:
1213
1214     OWS           = <OWS, defined in [Part1], Section 3.2.1>
1215     obs-text      = <obs-text, defined in [Part1], Section 3.2.4>
1216
1217   The rules below are defined in other parts:
1218
1219     HTTP-date     = <HTTP-date, defined in [Part2], Section 8.1.1.1>
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231Fielding & Reschke        Expires April 7, 2013                [Page 22]
1232
1233Internet-Draft        HTTP/1.1 Conditional Requests         October 2012
1234
1235
1236Appendix C.  Collected ABNF
1237
1238   ETag = entity-tag
1239
1240   HTTP-date = <HTTP-date, defined in [Part2], Section 8.1.1.1>
1241
1242   If-Match = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS
1243    entity-tag ] ) )
1244   If-Modified-Since = HTTP-date
1245   If-None-Match = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS
1246    entity-tag ] ) )
1247   If-Unmodified-Since = HTTP-date
1248
1249   Last-Modified = HTTP-date
1250
1251   OWS = <OWS, defined in [Part1], Section 3.2.1>
1252
1253   entity-tag = [ weak ] opaque-tag
1254   etagc = "!" / %x23-7E ; '#'-'~'
1255    / obs-text
1256
1257   obs-text = <obs-text, defined in [Part1], Section 3.2.4>
1258   opaque-tag = DQUOTE *etagc DQUOTE
1259
1260   weak = %x57.2F ; W/
1261
1262Appendix D.  Change Log (to be removed by RFC Editor before publication)
1263
1264   Changes up to the first Working Group Last Call draft are summarized
1265   in <http://tools.ietf.org/html/
1266   draft-ietf-httpbis-p4-conditional-19#appendix-C>.
1267
1268D.1.  Since draft-ietf-httpbis-p4-conditional-19
1269
1270   Closed issues:
1271
1272   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/241>: "Need to
1273      clarify eval order/interaction of conditional headers"
1274
1275   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/345>: "Required
1276      headers on 304 and 206"
1277
1278   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/350>: "Optionality
1279      of Conditional Request Support"
1280
1281   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/354>: "ETags and
1282      Conditional Requests"
1283
1284
1285
1286
1287Fielding & Reschke        Expires April 7, 2013                [Page 23]
1288
1289Internet-Draft        HTTP/1.1 Conditional Requests         October 2012
1290
1291
1292   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/361>: "ABNF
1293      requirements for recipients"
1294
1295   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/363>: "Rare cases"
1296
1297   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/365>: "Conditional
1298      Request Security Considerations"
1299
1300   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/371>: "If-Modified-
1301      Since lacks definition for method != GET"
1302
1303   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/372>: "refactor
1304      conditional header field descriptions"
1305
1306D.2.  Since draft-ietf-httpbis-p4-conditional-20
1307
1308   o  Conformance criteria and considerations regarding error handling
1309      are now defined in Part 1.
1310
1311Index
1312
1313   3
1314      304 Not Modified (status code)  18
1315
1316   4
1317      412 Precondition Failed (status code)  18
1318
1319   E
1320      ETag header field  9
1321
1322   G
1323      Grammar
1324         entity-tag  9
1325         ETag  9
1326         etagc  9
1327         If-Match  14
1328         If-Modified-Since  16
1329         If-None-Match  15
1330         If-Unmodified-Since  17
1331         Last-Modified  7
1332         opaque-tag  9
1333         weak  9
1334
1335   I
1336      If-Match header field  13
1337      If-Modified-Since header field  16
1338      If-None-Match header field  14
1339      If-Unmodified-Since header field  17
1340
1341
1342
1343Fielding & Reschke        Expires April 7, 2013                [Page 24]
1344
1345Internet-Draft        HTTP/1.1 Conditional Requests         October 2012
1346
1347
1348   L
1349      Last-Modified header field  7
1350
1351   M
1352      metadata  5
1353
1354   S
1355      selected representation  4
1356
1357   V
1358      validator  5
1359         strong  5
1360         weak  5
1361
1362Authors' Addresses
1363
1364   Roy T. Fielding (editor)
1365   Adobe Systems Incorporated
1366   345 Park Ave
1367   San Jose, CA  95110
1368   USA
1369
1370   EMail: fielding@gbiv.com
1371   URI:   http://roy.gbiv.com/
1372
1373
1374   Julian F. Reschke (editor)
1375   greenbytes GmbH
1376   Hafenweg 16
1377   Muenster, NW  48155
1378   Germany
1379
1380   EMail: julian.reschke@greenbytes.de
1381   URI:   http://greenbytes.de/tech/webdav/
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399Fielding & Reschke        Expires April 7, 2013                [Page 25]
1400
Note: See TracBrowser for help on using the repository browser.