source: draft-ietf-httpbis/00/draft-ietf-httpbis-p4-conditional-00.txt @ 63

Last change on this file since 63 was 63, checked in by fielding@…, 12 years ago

Update issues list URI and draft names

  • Property svn:eol-style set to native
File size: 39.4 KB
Line 
1
2
3
4Network Working Group                                   R. Fielding, Ed.
5Internet-Draft                                              Day Software
6Obsoletes: 2068, 2616                                          J. Gettys
7(if approved)                                       One Laptop per Child
8Intended status: Standards Track                                J. Mogul
9Expires: June 22, 2008                                                HP
10                                                              H. Frystyk
11                                                               Microsoft
12                                                             L. Masinter
13                                                           Adobe Systems
14                                                                P. Leach
15                                                               Microsoft
16                                                          T. Berners-Lee
17                                                                 W3C/MIT
18                                                       December 20, 2007
19
20
21                 HTTP/1.1, part 4: Conditional Requests
22                  draft-ietf-httpbis-p4-conditional-00
23
24Status of this Memo
25
26   By submitting this Internet-Draft, each author represents that any
27   applicable patent or other IPR claims of which he or she is aware
28   have been or will be disclosed, and any of which he or she becomes
29   aware will be disclosed, in accordance with Section 6 of BCP 79.
30
31   Internet-Drafts are working documents of the Internet Engineering
32   Task Force (IETF), its areas, and its working groups.  Note that
33   other groups may also distribute working documents as Internet-
34   Drafts.
35
36   Internet-Drafts are draft documents valid for a maximum of six months
37   and may be updated, replaced, or obsoleted by other documents at any
38   time.  It is inappropriate to use Internet-Drafts as reference
39   material or to cite them other than as "work in progress."
40
41   The list of current Internet-Drafts can be accessed at
42   http://www.ietf.org/ietf/1id-abstracts.txt.
43
44   The list of Internet-Draft Shadow Directories can be accessed at
45   http://www.ietf.org/shadow.html.
46
47   This Internet-Draft will expire on June 22, 2008.
48
49Copyright Notice
50
51   Copyright (C) The IETF Trust (2007).
52
53
54
55Fielding, et al.          Expires June 22, 2008                 [Page 1]
56
57Internet-Draft              HTTP/1.1, part 4               December 2007
58
59
60Abstract
61
62   The Hypertext Transfer Protocol (HTTP) is an application-level
63   protocol for distributed, collaborative, hypermedia information
64   systems.  HTTP has been in use by the World Wide Web global
65   information initiative since 1990.  This document is Part 4 of the
66   seven-part specification that defines the protocol referred to as
67   "HTTP/1.1" and, taken together, obsoletes RFC 2616.  Part 4 defines
68   request header fields for indicating conditional requests and the
69   rules for constructing responses to those requests.
70
71Editorial Note (To be removed by RFC Editor)
72
73   This version of the HTTP specification contains only minimal
74   editorial changes from [RFC2616] (abstract, introductory paragraph,
75   and authors' addresses).  All other changes are due to partitioning
76   the original into seven mostly independent parts.  The intent is for
77   readers of future drafts to able to use draft 00 as the basis for
78   comparison when the WG makes later changes to the specification text.
79   This draft will shortly be followed by draft 01 (containing the first
80   round of changes that have already been agreed to on the mailing
81   list).  There is no point in reviewing this draft other than to
82   verify that the partitioning has been done correctly.  Roy T.
83   Fielding, Yves Lafon, and Julian Reschke will be the editors after
84   draft 00 is submitted.
85
86   Discussion of this draft should take place on the HTTPBIS working
87   group mailing list (ietf-http-wg@w3.org).  The current issues list is
88   at <http://www3.tools.ietf.org/wg/httpbis/trac/report/11> and related
89   documents (including fancy diffs) can be found at
90   <http://www3.tools.ietf.org/wg/httpbis/>.
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111Fielding, et al.          Expires June 22, 2008                 [Page 2]
112
113Internet-Draft              HTTP/1.1, part 4               December 2007
114
115
116Table of Contents
117
118   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
119   2.  Entity Tags  . . . . . . . . . . . . . . . . . . . . . . . . .  4
120   3.  Status Code Definitions  . . . . . . . . . . . . . . . . . . .  4
121     3.1.  304 Not Modified . . . . . . . . . . . . . . . . . . . . .  4
122     3.2.  412 Precondition Failed  . . . . . . . . . . . . . . . . .  5
123   4.  Weak and Strong Validators . . . . . . . . . . . . . . . . . .  5
124   5.  Rules for When to Use Entity Tags and Last-Modified Dates  . .  8
125   6.  Header Field Definitions . . . . . . . . . . . . . . . . . . . 10
126     6.1.  ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
127     6.2.  If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 10
128     6.3.  If-Modified-Since  . . . . . . . . . . . . . . . . . . . . 11
129     6.4.  If-None-Match  . . . . . . . . . . . . . . . . . . . . . . 13
130     6.5.  If-Unmodified-Since  . . . . . . . . . . . . . . . . . . . 14
131     6.6.  Last-Modified  . . . . . . . . . . . . . . . . . . . . . . 15
132   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
133   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
134   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 16
135   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
136   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
137   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
138   Intellectual Property and Copyright Statements . . . . . . . . . . 20
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167Fielding, et al.          Expires June 22, 2008                 [Page 3]
168
169Internet-Draft              HTTP/1.1, part 4               December 2007
170
171
1721.  Introduction
173
174   This document will define aspects of HTTP related to conditional
175   request messages based on time stamps and entity-tags.  Right now it
176   only includes the extracted relevant sections of RFC 2616 [RFC2616]
177   without edit.
178
179
1802.  Entity Tags
181
182   Entity tags are used for comparing two or more entities from the same
183   requested resource.  HTTP/1.1 uses entity tags in the ETag
184   (Section 6.1), If-Match (Section 6.2), If-None-Match (Section 6.4),
185   and If-Range (Section 5.3 of [Part5]) header fields.  The definition
186   of how they are used and compared as cache validators is in
187   Section 4.  An entity tag consists of an opaque quoted string,
188   possibly prefixed by a weakness indicator.
189
190      entity-tag = [ weak ] opaque-tag
191      weak       = "W/"
192      opaque-tag = quoted-string
193
194   A "strong entity tag" MAY be shared by two entities of a resource
195   only if they are equivalent by octet equality.
196
197   A "weak entity tag," indicated by the "W/" prefix, MAY be shared by
198   two entities of a resource only if the entities are equivalent and
199   could be substituted for each other with no significant change in
200   semantics.  A weak entity tag can only be used for weak comparison.
201
202   An entity tag MUST be unique across all versions of all entities
203   associated with a particular resource.  A given entity tag value MAY
204   be used for entities obtained by requests on different URIs.  The use
205   of the same entity tag value in conjunction with entities obtained by
206   requests on different URIs does not imply the equivalence of those
207   entities.
208
209
2103.  Status Code Definitions
211
2123.1.  304 Not Modified
213
214   If the client has performed a conditional GET request and access is
215   allowed, but the document has not been modified, the server SHOULD
216   respond with this status code.  The 304 response MUST NOT contain a
217   message-body, and thus is always terminated by the first empty line
218   after the header fields.
219
220
221
222
223Fielding, et al.          Expires June 22, 2008                 [Page 4]
224
225Internet-Draft              HTTP/1.1, part 4               December 2007
226
227
228   The response MUST include the following header fields:
229
230   o  Date, unless its omission is required by Section 8.3.1 of [Part1]
231
232   If a clockless origin server obeys these rules, and proxies and
233   clients add their own Date to any response received without one (as
234   already specified by [RFC2068], section 14.19), caches will operate
235   correctly.
236
237   o  ETag and/or Content-Location, if the header would have been sent
238      in a 200 response to the same request
239
240   o  Expires, Cache-Control, and/or Vary, if the field-value might
241      differ from that sent in any previous response for the same
242      variant
243
244   If the conditional GET used a strong cache validator (see [Part6]),
245   the response SHOULD NOT include other entity-headers.  Otherwise
246   (i.e., the conditional GET used a weak validator), the response MUST
247   NOT include other entity-headers; this prevents inconsistencies
248   between cached entity-bodies and updated headers.
249
250   If a 304 response indicates an entity not currently cached, then the
251   cache MUST disregard the response and repeat the request without the
252   conditional.
253
254   If a cache uses a received 304 response to update a cache entry, the
255   cache MUST update the entry to reflect any new field values given in
256   the response.
257
2583.2.  412 Precondition Failed
259
260   The precondition given in one or more of the request-header fields
261   evaluated to false when it was tested on the server.  This response
262   code allows the client to place preconditions on the current resource
263   metainformation (header field data) and thus prevent the requested
264   method from being applied to a resource other than the one intended.
265
266
2674.  Weak and Strong Validators
268
269   Since both origin servers and caches will compare two validators to
270   decide if they represent the same or different entities, one normally
271   would expect that if the entity (the entity-body or any entity-
272   headers) changes in any way, then the associated validator would
273   change as well.  If this is true, then we call this validator a
274   "strong validator."
275
276
277
278
279Fielding, et al.          Expires June 22, 2008                 [Page 5]
280
281Internet-Draft              HTTP/1.1, part 4               December 2007
282
283
284   However, there might be cases when a server prefers to change the
285   validator only on semantically significant changes, and not when
286   insignificant aspects of the entity change.  A validator that does
287   not always change when the resource changes is a "weak validator."
288
289   Entity tags are normally "strong validators," but the protocol
290   provides a mechanism to tag an entity tag as "weak."  One can think
291   of a strong validator as one that changes whenever the bits of an
292   entity changes, while a weak value changes whenever the meaning of an
293   entity changes.  Alternatively, one can think of a strong validator
294   as part of an identifier for a specific entity, while a weak
295   validator is part of an identifier for a set of semantically
296   equivalent entities.
297
298      Note: One example of a strong validator is an integer that is
299      incremented in stable storage every time an entity is changed.
300
301      An entity's modification time, if represented with one-second
302      resolution, could be a weak validator, since it is possible that
303      the resource might be modified twice during a single second.
304
305      Support for weak validators is optional.  However, weak validators
306      allow for more efficient caching of equivalent objects; for
307      example, a hit counter on a site is probably good enough if it is
308      updated every few days or weeks, and any value during that period
309      is likely "good enough" to be equivalent.
310
311   A "use" of a validator is either when a client generates a request
312   and includes the validator in a validating header field, or when a
313   server compares two validators.
314
315   Strong validators are usable in any context.  Weak validators are
316   only usable in contexts that do not depend on exact equality of an
317   entity.  For example, either kind is usable for a conditional GET of
318   a full entity.  However, only a strong validator is usable for a sub-
319   range retrieval, since otherwise the client might end up with an
320   internally inconsistent entity.
321
322   Clients MAY issue simple (non-subrange) GET requests with either weak
323   validators or strong validators.  Clients MUST NOT use weak
324   validators in other forms of request.
325
326   The only function that the HTTP/1.1 protocol defines on validators is
327   comparison.  There are two validator comparison functions, depending
328   on whether the comparison context allows the use of weak validators
329   or not:
330
331
332
333
334
335Fielding, et al.          Expires June 22, 2008                 [Page 6]
336
337Internet-Draft              HTTP/1.1, part 4               December 2007
338
339
340   o  The strong comparison function: in order to be considered equal,
341      both validators MUST be identical in every way, and both MUST NOT
342      be weak.
343
344   o  The weak comparison function: in order to be considered equal,
345      both validators MUST be identical in every way, but either or both
346      of them MAY be tagged as "weak" without affecting the result.
347
348   An entity tag is strong unless it is explicitly tagged as weak.
349   Section 2 gives the syntax for entity tags.
350
351   A Last-Modified time, when used as a validator in a request, is
352   implicitly weak unless it is possible to deduce that it is strong,
353   using the following rules:
354
355   o  The validator is being compared by an origin server to the actual
356      current validator for the entity and,
357
358   o  That origin server reliably knows that the associated entity did
359      not change twice during the second covered by the presented
360      validator.
361
362   or
363
364   o  The validator is about to be used by a client in an If-Modified-
365      Since or If-Unmodified-Since header, because the client has a
366      cache entry for the associated entity, and
367
368   o  That cache entry includes a Date value, which gives the time when
369      the origin server sent the original response, and
370
371   o  The presented Last-Modified time is at least 60 seconds before the
372      Date value.
373
374   or
375
376   o  The validator is being compared by an intermediate cache to the
377      validator stored in its cache entry for the entity, and
378
379   o  That cache entry includes a Date value, which gives the time when
380      the origin server sent the original response, and
381
382   o  The presented Last-Modified time is at least 60 seconds before the
383      Date value.
384
385   This method relies on the fact that if two different responses were
386   sent by the origin server during the same second, but both had the
387   same Last-Modified time, then at least one of those responses would
388
389
390
391Fielding, et al.          Expires June 22, 2008                 [Page 7]
392
393Internet-Draft              HTTP/1.1, part 4               December 2007
394
395
396   have a Date value equal to its Last-Modified time.  The arbitrary 60-
397   second limit guards against the possibility that the Date and Last-
398   Modified values are generated from different clocks, or at somewhat
399   different times during the preparation of the response.  An
400   implementation MAY use a value larger than 60 seconds, if it is
401   believed that 60 seconds is too short.
402
403   If a client wishes to perform a sub-range retrieval on a value for
404   which it has only a Last-Modified time and no opaque validator, it
405   MAY do this only if the Last-Modified time is strong in the sense
406   described here.
407
408   A cache or origin server receiving a conditional request, other than
409   a full-body GET request, MUST use the strong comparison function to
410   evaluate the condition.
411
412   These rules allow HTTP/1.1 caches and clients to safely perform sub-
413   range retrievals on values that have been obtained from HTTP/1.0
414   servers.
415
416
4175.  Rules for When to Use Entity Tags and Last-Modified Dates
418
419   We adopt a set of rules and recommendations for origin servers,
420   clients, and caches regarding when various validator types ought to
421   be used, and for what purposes.
422
423   HTTP/1.1 origin servers:
424
425   o  SHOULD send an entity tag validator unless it is not feasible to
426      generate one.
427
428   o  MAY send a weak entity tag instead of a strong entity tag, if
429      performance considerations support the use of weak entity tags, or
430      if it is unfeasible to send a strong entity tag.
431
432   o  SHOULD send a Last-Modified value if it is feasible to send one,
433      unless the risk of a breakdown in semantic transparency that could
434      result from using this date in an If-Modified-Since header would
435      lead to serious problems.
436
437   In other words, the preferred behavior for an HTTP/1.1 origin server
438   is to send both a strong entity tag and a Last-Modified value.
439
440   In order to be legal, a strong entity tag MUST change whenever the
441   associated entity value changes in any way.  A weak entity tag SHOULD
442   change whenever the associated entity changes in a semantically
443   significant way.
444
445
446
447Fielding, et al.          Expires June 22, 2008                 [Page 8]
448
449Internet-Draft              HTTP/1.1, part 4               December 2007
450
451
452      Note: in order to provide semantically transparent caching, an
453      origin server must avoid reusing a specific strong entity tag
454      value for two different entities, or reusing a specific weak
455      entity tag value for two semantically different entities.  Cache
456      entries might persist for arbitrarily long periods, regardless of
457      expiration times, so it might be inappropriate to expect that a
458      cache will never again attempt to validate an entry using a
459      validator that it obtained at some point in the past.
460
461   HTTP/1.1 clients:
462
463   o  If an entity tag has been provided by the origin server, MUST use
464      that entity tag in any cache-conditional request (using If-Match
465      or If-None-Match).
466
467   o  If only a Last-Modified value has been provided by the origin
468      server, SHOULD use that value in non-subrange cache-conditional
469      requests (using If-Modified-Since).
470
471   o  If only a Last-Modified value has been provided by an HTTP/1.0
472      origin server, MAY use that value in subrange cache-conditional
473      requests (using If-Unmodified-Since:).  The user agent SHOULD
474      provide a way to disable this, in case of difficulty.
475
476   o  If both an entity tag and a Last-Modified value have been provided
477      by the origin server, SHOULD use both validators in cache-
478      conditional requests.  This allows both HTTP/1.0 and HTTP/1.1
479      caches to respond appropriately.
480
481   An HTTP/1.1 origin server, upon receiving a conditional request that
482   includes both a Last-Modified date (e.g., in an If-Modified-Since or
483   If-Unmodified-Since header field) and one or more entity tags (e.g.,
484   in an If-Match, If-None-Match, or If-Range header field) as cache
485   validators, MUST NOT return a response status of 304 (Not Modified)
486   unless doing so is consistent with all of the conditional header
487   fields in the request.
488
489   An HTTP/1.1 caching proxy, upon receiving a conditional request that
490   includes both a Last-Modified date and one or more entity tags as
491   cache validators, MUST NOT return a locally cached response to the
492   client unless that cached response is consistent with all of the
493   conditional header fields in the request.
494
495      Note: The general principle behind these rules is that HTTP/1.1
496      servers and clients should transmit as much non-redundant
497      information as is available in their responses and requests.
498      HTTP/1.1 systems receiving this information will make the most
499      conservative assumptions about the validators they receive.
500
501
502
503Fielding, et al.          Expires June 22, 2008                 [Page 9]
504
505Internet-Draft              HTTP/1.1, part 4               December 2007
506
507
508      HTTP/1.0 clients and caches will ignore entity tags.  Generally,
509      last-modified values received or used by these systems will
510      support transparent and efficient caching, and so HTTP/1.1 origin
511      servers should provide Last-Modified values.  In those rare cases
512      where the use of a Last-Modified value as a validator by an
513      HTTP/1.0 system could result in a serious problem, then HTTP/1.1
514      origin servers should not provide one.
515
516
5176.  Header Field Definitions
518
519   This section defines the syntax and semantics of all standard
520   HTTP/1.1 header fields.  For entity-header fields, both sender and
521   recipient refer to either the client or the server, depending on who
522   sends and who receives the entity.
523
5246.1.  ETag
525
526   The ETag response-header field provides the current value of the
527   entity tag for the requested variant.  The headers used with entity
528   tags are described in sections 6.2, 6.4 and Section 5.3 of [Part5].
529   The entity tag MAY be used for comparison with other entities from
530   the same resource (see Section 4).
531
532       ETag = "ETag" ":" entity-tag
533
534   Examples:
535
536      ETag: "xyzzy"
537      ETag: W/"xyzzy"
538      ETag: ""
539
5406.2.  If-Match
541
542   The If-Match request-header field is used with a method to make it
543   conditional.  A client that has one or more entities previously
544   obtained from the resource can verify that one of those entities is
545   current by including a list of their associated entity tags in the
546   If-Match header field.  Entity tags are defined in Section 2.  The
547   purpose of this feature is to allow efficient updates of cached
548   information with a minimum amount of transaction overhead.  It is
549   also used, on updating requests, to prevent inadvertent modification
550   of the wrong version of a resource.  As a special case, the value "*"
551   matches any current entity of the resource.
552
553       If-Match = "If-Match" ":" ( "*" | 1#entity-tag )
554
555   If any of the entity tags match the entity tag of the entity that
556
557
558
559Fielding, et al.          Expires June 22, 2008                [Page 10]
560
561Internet-Draft              HTTP/1.1, part 4               December 2007
562
563
564   would have been returned in the response to a similar GET request
565   (without the If-Match header) on that resource, or if "*" is given
566   and any current entity exists for that resource, then the server MAY
567   perform the requested method as if the If-Match header field did not
568   exist.
569
570   A server MUST use the strong comparison function (see Section 4) to
571   compare the entity tags in If-Match.
572
573   If none of the entity tags match, or if "*" is given and no current
574   entity exists, the server MUST NOT perform the requested method, and
575   MUST return a 412 (Precondition Failed) response.  This behavior is
576   most useful when the client wants to prevent an updating method, such
577   as PUT, from modifying a resource that has changed since the client
578   last retrieved it.
579
580   If the request would, without the If-Match header field, result in
581   anything other than a 2xx or 412 status, then the If-Match header
582   MUST be ignored.
583
584   The meaning of "If-Match: *" is that the method SHOULD be performed
585   if the representation selected by the origin server (or by a cache,
586   possibly using the Vary mechanism, see Section 3.5 of [Part6])
587   exists, and MUST NOT be performed if the representation does not
588   exist.
589
590   A request intended to update a resource (e.g., a PUT) MAY include an
591   If-Match header field to signal that the request method MUST NOT be
592   applied if the entity corresponding to the If-Match value (a single
593   entity tag) is no longer a representation of that resource.  This
594   allows the user to indicate that they do not wish the request to be
595   successful if the resource has been changed without their knowledge.
596   Examples:
597
598       If-Match: "xyzzy"
599       If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
600       If-Match: *
601
602   The result of a request having both an If-Match header field and
603   either an If-None-Match or an If-Modified-Since header fields is
604   undefined by this specification.
605
6066.3.  If-Modified-Since
607
608   The If-Modified-Since request-header field is used with a method to
609   make it conditional: if the requested variant has not been modified
610   since the time specified in this field, an entity will not be
611   returned from the server; instead, a 304 (not modified) response will
612
613
614
615Fielding, et al.          Expires June 22, 2008                [Page 11]
616
617Internet-Draft              HTTP/1.1, part 4               December 2007
618
619
620   be returned without any message-body.
621
622       If-Modified-Since = "If-Modified-Since" ":" HTTP-date
623
624   An example of the field is:
625
626       If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
627
628   A GET method with an If-Modified-Since header and no Range header
629   requests that the identified entity be transferred only if it has
630   been modified since the date given by the If-Modified-Since header.
631   The algorithm for determining this includes the following cases:
632
633   1.  If the request would normally result in anything other than a 200
634       (OK) status, or if the passed If-Modified-Since date is invalid,
635       the response is exactly the same as for a normal GET.  A date
636       which is later than the server's current time is invalid.
637
638   2.  If the variant has been modified since the If-Modified-Since
639       date, the response is exactly the same as for a normal GET.
640
641   3.  If the variant has not been modified since a valid If-Modified-
642       Since date, the server SHOULD return a 304 (Not Modified)
643       response.
644
645   The purpose of this feature is to allow efficient updates of cached
646   information with a minimum amount of transaction overhead.
647
648      Note: The Range request-header field modifies the meaning of If-
649      Modified-Since; see Section 5.4 of [Part5] for full details.
650
651      Note: If-Modified-Since times are interpreted by the server, whose
652      clock might not be synchronized with the client.
653
654      Note: When handling an If-Modified-Since header field, some
655      servers will use an exact date comparison function, rather than a
656      less-than function, for deciding whether to send a 304 (Not
657      Modified) response.  To get best results when sending an If-
658      Modified-Since header field for cache validation, clients are
659      advised to use the exact date string received in a previous Last-
660      Modified header field whenever possible.
661
662      Note: If a client uses an arbitrary date in the If-Modified-Since
663      header instead of a date taken from the Last-Modified header for
664      the same request, the client should be aware of the fact that this
665      date is interpreted in the server's understanding of time.  The
666      client should consider unsynchronized clocks and rounding problems
667      due to the different encodings of time between the client and
668
669
670
671Fielding, et al.          Expires June 22, 2008                [Page 12]
672
673Internet-Draft              HTTP/1.1, part 4               December 2007
674
675
676      server.  This includes the possibility of race conditions if the
677      document has changed between the time it was first requested and
678      the If-Modified-Since date of a subsequent request, and the
679      possibility of clock-skew-related problems if the If-Modified-
680      Since date is derived from the client's clock without correction
681      to the server's clock.  Corrections for different time bases
682      between client and server are at best approximate due to network
683      latency.
684
685   The result of a request having both an If-Modified-Since header field
686   and either an If-Match or an If-Unmodified-Since header fields is
687   undefined by this specification.
688
6896.4.  If-None-Match
690
691   The If-None-Match request-header field is used with a method to make
692   it conditional.  A client that has one or more entities previously
693   obtained from the resource can verify that none of those entities is
694   current by including a list of their associated entity tags in the
695   If-None-Match header field.  The purpose of this feature is to allow
696   efficient updates of cached information with a minimum amount of
697   transaction overhead.  It is also used to prevent a method (e.g.
698   PUT) from inadvertently modifying an existing resource when the
699   client believes that the resource does not exist.
700
701   As a special case, the value "*" matches any current entity of the
702   resource.
703
704       If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag )
705
706   If any of the entity tags match the entity tag of the entity that
707   would have been returned in the response to a similar GET request
708   (without the If-None-Match header) on that resource, or if "*" is
709   given and any current entity exists for that resource, then the
710   server MUST NOT perform the requested method, unless required to do
711   so because the resource's modification date fails to match that
712   supplied in an If-Modified-Since header field in the request.
713   Instead, if the request method was GET or HEAD, the server SHOULD
714   respond with a 304 (Not Modified) response, including the cache-
715   related header fields (particularly ETag) of one of the entities that
716   matched.  For all other request methods, the server MUST respond with
717   a status of 412 (Precondition Failed).
718
719   See Section 4 for rules on how to determine if two entities tags
720   match.  The weak comparison function can only be used with GET or
721   HEAD requests.
722
723   If none of the entity tags match, then the server MAY perform the
724
725
726
727Fielding, et al.          Expires June 22, 2008                [Page 13]
728
729Internet-Draft              HTTP/1.1, part 4               December 2007
730
731
732   requested method as if the If-None-Match header field did not exist,
733   but MUST also ignore any If-Modified-Since header field(s) in the
734   request.  That is, if no entity tags match, then the server MUST NOT
735   return a 304 (Not Modified) response.
736
737   If the request would, without the If-None-Match header field, result
738   in anything other than a 2xx or 304 status, then the If-None-Match
739   header MUST be ignored.  (See Section 5 for a discussion of server
740   behavior when both If-Modified-Since and If-None-Match appear in the
741   same request.)
742
743   The meaning of "If-None-Match: *" is that the method MUST NOT be
744   performed if the representation selected by the origin server (or by
745   a cache, possibly using the Vary mechanism, see Section 3.5 of
746   [Part6]) exists, and SHOULD be performed if the representation does
747   not exist.  This feature is intended to be useful in preventing races
748   between PUT operations.
749
750   Examples:
751
752       If-None-Match: "xyzzy"
753       If-None-Match: W/"xyzzy"
754       If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
755       If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
756       If-None-Match: *
757
758   The result of a request having both an If-None-Match header field and
759   either an If-Match or an If-Unmodified-Since header fields is
760   undefined by this specification.
761
7626.5.  If-Unmodified-Since
763
764   The If-Unmodified-Since request-header field is used with a method to
765   make it conditional.  If the requested resource has not been modified
766   since the time specified in this field, the server SHOULD perform the
767   requested operation as if the If-Unmodified-Since header were not
768   present.
769
770   If the requested variant has been modified since the specified time,
771   the server MUST NOT perform the requested operation, and MUST return
772   a 412 (Precondition Failed).
773
774      If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date
775
776   An example of the field is:
777
778       If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
779
780
781
782
783Fielding, et al.          Expires June 22, 2008                [Page 14]
784
785Internet-Draft              HTTP/1.1, part 4               December 2007
786
787
788   If the request normally (i.e., without the If-Unmodified-Since
789   header) would result in anything other than a 2xx or 412 status, the
790   If-Unmodified-Since header SHOULD be ignored.
791
792   If the specified date is invalid, the header is ignored.
793
794   The result of a request having both an If-Unmodified-Since header
795   field and either an If-None-Match or an If-Modified-Since header
796   fields is undefined by this specification.
797
7986.6.  Last-Modified
799
800   The Last-Modified entity-header field indicates the date and time at
801   which the origin server believes the variant was last modified.
802
803       Last-Modified  = "Last-Modified" ":" HTTP-date
804
805   An example of its use is
806
807       Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
808
809   The exact meaning of this header field depends on the implementation
810   of the origin server and the nature of the original resource.  For
811   files, it may be just the file system last-modified time.  For
812   entities with dynamically included parts, it may be the most recent
813   of the set of last-modify times for its component parts.  For
814   database gateways, it may be the last-update time stamp of the
815   record.  For virtual objects, it may be the last time the internal
816   state changed.
817
818   An origin server MUST NOT send a Last-Modified date which is later
819   than the server's time of message origination.  In such cases, where
820   the resource's last modification would indicate some time in the
821   future, the server MUST replace that date with the message
822   origination date.
823
824   An origin server SHOULD obtain the Last-Modified value of the entity
825   as close as possible to the time that it generates the Date value of
826   its response.  This allows a recipient to make an accurate assessment
827   of the entity's modification time, especially if the entity changes
828   near the time that the response is generated.
829
830   HTTP/1.1 servers SHOULD send Last-Modified whenever feasible.
831
832
8337.  IANA Considerations
834
835   TBD.
836
837
838
839Fielding, et al.          Expires June 22, 2008                [Page 15]
840
841Internet-Draft              HTTP/1.1, part 4               December 2007
842
843
8448.  Security Considerations
845
846   No additional security considerations have been identified beyond
847   those applicable to HTTP in general [Part1].
848
849
8509.  Acknowledgments
851
852   Based on an XML translation of RFC 2616 by Julian Reschke.
853
854
85510.  References
856
857   [Part1]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
858              Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1,
859              part 1: URIs, Connections, and Message Parsing",
860              draft-ietf-httpbis-p1-messaging-00 (work in progress),
861              December 2007.
862
863   [Part5]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
864              Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1,
865              part 5: Range Requests and Partial Responses",
866              draft-ietf-httpbis-p5-range-00 (work in progress),
867              December 2007.
868
869   [Part6]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
870              Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1,
871              part 6: Caching", draft-ietf-httpbis-p6-cache-00 (work in
872              progress), December 2007.
873
874   [RFC2068]  Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
875              Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
876              RFC 2068, January 1997.
877
878   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
879              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
880              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
881
882
883Index
884
885   3
886      304 Not Modified (status code)  4
887
888   4
889      412 Precondition Failed (status code)  5
890
891   E
892
893
894
895Fielding, et al.          Expires June 22, 2008                [Page 16]
896
897Internet-Draft              HTTP/1.1, part 4               December 2007
898
899
900      ETag header  10
901
902   G
903      Grammar
904         entity-tag  4
905         ETag  10
906         If-Match  10
907         If-Modified-Since  12
908         If-None-Match  13
909         If-Unmodified-Since  14
910         Last-Modified  15
911         opaque-tag  4
912         weak  4
913
914   H
915      Headers
916         ETag  10
917         If-Match  10
918         If-Modified-Since  11
919         If-None-Match  13
920         If-Unmodified-Since  14
921         Last-Modified  15
922
923   I
924      If-Match header  10
925      If-Modified-Since header  11
926      If-None-Match header  13
927      If-Unmodified-Since header  14
928
929   L
930      Last-Modified header  15
931
932   S
933      Status Codes
934         304 Not Modified  4
935         412 Precondition Failed  5
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951Fielding, et al.          Expires June 22, 2008                [Page 17]
952
953Internet-Draft              HTTP/1.1, part 4               December 2007
954
955
956Authors' Addresses
957
958   Roy T. Fielding (editor)
959   Day Software
960   23 Corporate Plaza DR, Suite 280
961   Newport Beach, CA  92660
962   USA
963
964   Phone: +1-949-706-5300
965   Fax:   +1-949-706-5305
966   Email: fielding@gbiv.com
967   URI:   http://roy.gbiv.com/
968
969
970   Jim Gettys
971   One Laptop per Child
972   21 Oak Knoll Road
973   Carlisle, MA  01741
974   USA
975
976   Email: jg@laptop.org
977   URI:   http://www.laptop.org/
978
979
980   Jeffrey C. Mogul
981   Hewlett-Packard Company
982   HP Labs, Large Scale Systems Group
983   1501 Page Mill Road, MS 1177
984   Palo Alto, CA  94304
985   USA
986
987   Email: JeffMogul@acm.org
988
989
990   Henrik Frystyk Nielsen
991   Microsoft Corporation
992   1 Microsoft Way
993   Redmond, WA  98052
994   USA
995
996   Email: henrikn@microsoft.com
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007Fielding, et al.          Expires June 22, 2008                [Page 18]
1008
1009Internet-Draft              HTTP/1.1, part 4               December 2007
1010
1011
1012   Larry Masinter
1013   Adobe Systems, Incorporated
1014   345 Park Ave
1015   San Jose, CA  95110
1016   USA
1017
1018   Email: LMM@acm.org
1019   URI:   http://larry.masinter.net/
1020
1021
1022   Paul J. Leach
1023   Microsoft Corporation
1024   1 Microsoft Way
1025   Redmond, WA  98052
1026
1027   Email: paulle@microsoft.com
1028
1029
1030   Tim Berners-Lee
1031   World Wide Web Consortium
1032   MIT Computer Science and Artificial Intelligence Laboratory
1033   The Stata Center, Building 32
1034   32 Vassar Street
1035   Cambridge, MA  02139
1036   USA
1037
1038   Email: timbl@w3.org
1039   URI:   http://www.w3.org/People/Berners-Lee/
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063Fielding, et al.          Expires June 22, 2008                [Page 19]
1064
1065Internet-Draft              HTTP/1.1, part 4               December 2007
1066
1067
1068Full Copyright Statement
1069
1070   Copyright (C) The IETF Trust (2007).
1071
1072   This document is subject to the rights, licenses and restrictions
1073   contained in BCP 78, and except as set forth therein, the authors
1074   retain all their rights.
1075
1076   This document and the information contained herein are provided on an
1077   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1078   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
1079   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1080   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1081   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1082   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1083
1084
1085Intellectual Property
1086
1087   The IETF takes no position regarding the validity or scope of any
1088   Intellectual Property Rights or other rights that might be claimed to
1089   pertain to the implementation or use of the technology described in
1090   this document or the extent to which any license under such rights
1091   might or might not be available; nor does it represent that it has
1092   made any independent effort to identify any such rights.  Information
1093   on the procedures with respect to rights in RFC documents can be
1094   found in BCP 78 and BCP 79.
1095
1096   Copies of IPR disclosures made to the IETF Secretariat and any
1097   assurances of licenses to be made available, or the result of an
1098   attempt made to obtain a general license or permission for the use of
1099   such proprietary rights by implementers or users of this
1100   specification can be obtained from the IETF on-line IPR repository at
1101   http://www.ietf.org/ipr.
1102
1103   The IETF invites any interested party to bring to its attention any
1104   copyrights, patents or patent applications, or other proprietary
1105   rights that may cover technology that may be required to implement
1106   this standard.  Please address the information to the IETF at
1107   ietf-ipr@ietf.org.
1108
1109
1110Acknowledgment
1111
1112   Funding for the RFC Editor function is provided by the IETF
1113   Administrative Support Activity (IASA).
1114
1115
1116
1117
1118
1119Fielding, et al.          Expires June 22, 2008                [Page 20]
1120
Note: See TracBrowser for help on using the repository browser.