source: draft-ietf-httpbis/09/draft-ietf-httpbis-p4-conditional-09.txt @ 847

Last change on this file since 847 was 772, checked in by julian.reschke@…, 10 years ago

Prepare publication of -09 drafts on March 08

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