source: draft-ietf-httpbis/06/draft-ietf-httpbis-p4-conditional-06.txt @ 784

Last change on this file since 784 was 558, checked in by fielding@…, 11 years ago

Draft 06 (as recorded by www.ietf.org)

  • Property svn:eol-style set to native
File size: 49.5 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 10, 2009                                     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 9, 2009
23
24
25                 HTTP/1.1, part 4: Conditional Requests
26                  draft-ietf-httpbis-p4-conditional-06
27
28Status of this Memo
29
30   This Internet-Draft is submitted to IETF in full conformance with the
31   provisions of BCP 78 and BCP 79.  This document may contain material
32   from IETF Documents or IETF Contributions published or made publicly
33   available before November 10, 2008.  The person(s) controlling the
34   copyright in some of this material may not have granted the IETF
35   Trust the right to allow modifications of such material outside the
36   IETF Standards Process.  Without obtaining an adequate license from
37   the person(s) controlling the copyright in such materials, this
38   document may not be modified outside the IETF Standards Process, and
39   derivative works of it may not be created outside the IETF Standards
40   Process, except to format it for publication as an RFC or to
41   translate it into languages other than English.
42
43   Internet-Drafts are working documents of the Internet Engineering
44   Task Force (IETF), its areas, and its working groups.  Note that
45   other groups may also distribute working documents as Internet-
46   Drafts.
47
48   Internet-Drafts are draft documents valid for a maximum of six months
49   and may be updated, replaced, or obsoleted by other documents at any
50   time.  It is inappropriate to use Internet-Drafts as reference
51   material or to cite them other than as "work in progress."
52
53
54
55Fielding, et al.       Expires September 10, 2009               [Page 1]
56
57Internet-Draft              HTTP/1.1, Part 4                  March 2009
58
59
60   The list of current Internet-Drafts can be accessed at
61   http://www.ietf.org/ietf/1id-abstracts.txt.
62
63   The list of Internet-Draft Shadow Directories can be accessed at
64   http://www.ietf.org/shadow.html.
65
66   This Internet-Draft will expire on September 10, 2009.
67
68Copyright Notice
69
70   Copyright (c) 2009 IETF Trust and the persons identified as the
71   document authors.  All rights reserved.
72
73   This document is subject to BCP 78 and the IETF Trust's Legal
74   Provisions Relating to IETF Documents in effect on the date of
75   publication of this document (http://trustee.ietf.org/license-info).
76   Please review these documents carefully, as they describe your rights
77   and restrictions with respect to this document.
78
79Abstract
80
81   The Hypertext Transfer Protocol (HTTP) is an application-level
82   protocol for distributed, collaborative, hypermedia information
83   systems.  HTTP has been in use by the World Wide Web global
84   information initiative since 1990.  This document is Part 4 of the
85   seven-part specification that defines the protocol referred to as
86   "HTTP/1.1" and, taken together, obsoletes RFC 2616.  Part 4 defines
87   request header fields for indicating conditional requests and the
88   rules for constructing responses to those requests.
89
90Editorial Note (To be removed by RFC Editor)
91
92   Discussion of this draft should take place on the HTTPBIS working
93   group mailing list (ietf-http-wg@w3.org).  The current issues list is
94   at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related
95   documents (including fancy diffs) can be found at
96   <http://tools.ietf.org/wg/httpbis/>.
97
98   The changes in this draft are summarized in Appendix C.7.
99
100
101
102
103
104
105
106
107
108
109
110
111Fielding, et al.       Expires September 10, 2009               [Page 2]
112
113Internet-Draft              HTTP/1.1, Part 4                  March 2009
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.  Message Header Registration  . . . . . . . . . . . . . . . 17
139   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
140   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 18
141   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
142     10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
143     10.2. Informative References . . . . . . . . . . . . . . . . . . 19
144   Appendix A.  Compatibility with Previous Versions  . . . . . . . . 19
145     A.1.  Changes from RFC 2616  . . . . . . . . . . . . . . . . . . 19
146   Appendix B.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 20
147   Appendix C.  Change Log (to be removed by RFC Editor before
148                publication)  . . . . . . . . . . . . . . . . . . . . 20
149     C.1.  Since RFC2616  . . . . . . . . . . . . . . . . . . . . . . 21
150     C.2.  Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 21
151     C.3.  Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 21
152     C.4.  Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 21
153     C.5.  Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 21
154     C.6.  Since draft-ietf-httpbis-p4-conditional-04 . . . . . . . . 22
155     C.7.  Since draft-ietf-httpbis-p4-conditional-05 . . . . . . . . 22
156   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
157   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
158
159
160
161
162
163
164
165
166
167Fielding, et al.       Expires September 10, 2009               [Page 3]
168
169Internet-Draft              HTTP/1.1, Part 4                  March 2009
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 10, 2009               [Page 4]
224
225Internet-Draft              HTTP/1.1, Part 4                  March 2009
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 3.2.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       = "W/"
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 10, 2009               [Page 5]
280
281Internet-Draft              HTTP/1.1, Part 4                  March 2009
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 8.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 8.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 10, 2009               [Page 6]
336
337Internet-Draft              HTTP/1.1, Part 4                  March 2009
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 10, 2009               [Page 7]
392
393Internet-Draft              HTTP/1.1, Part 4                  March 2009
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.
406
407   The example below shows the results for a set of entity tag pairs,
408   and both the weak and strong comparison function results:
409
410   +--------+--------+-------------------+-----------------+
411   | ETag 1 | ETag 2 | Strong Comparison | Weak Comparison |
412   +--------+--------+-------------------+-----------------+
413   | W/"1"  | W/"1"  | no match          | match           |
414   | W/"1"  | W/"2"  | no match          | no match        |
415   | W/"1"  | "1"    | no match          | match           |
416   | "1"    | "1"    | match             | match           |
417   +--------+--------+-------------------+-----------------+
418
419   An entity tag is strong unless it is explicitly tagged as weak.
420   Section 2 gives the syntax for entity tags.
421
422   A Last-Modified time, when used as a validator in a request, is
423   implicitly weak unless it is possible to deduce that it is strong,
424   using the following rules:
425
426   o  The validator is being compared by an origin server to the actual
427      current validator for the entity and,
428
429   o  That origin server reliably knows that the associated entity did
430      not change twice during the second covered by the presented
431      validator.
432
433   or
434
435   o  The validator is about to be used by a client in an If-Modified-
436      Since or If-Unmodified-Since header, because the client has a
437      cache entry for the associated entity, and
438
439   o  That cache entry includes a Date value, which gives the time when
440      the origin server sent the original response, and
441
442   o  The presented Last-Modified time is at least 60 seconds before the
443      Date value.
444
445
446
447Fielding, et al.       Expires September 10, 2009               [Page 8]
448
449Internet-Draft              HTTP/1.1, Part 4                  March 2009
450
451
452   or
453
454   o  The validator is being compared by an intermediate cache to the
455      validator stored in its cache entry for the entity, and
456
457   o  That cache entry includes a Date value, which gives the time when
458      the origin server sent the original response, and
459
460   o  The presented Last-Modified time is at least 60 seconds before the
461      Date value.
462
463   This method relies on the fact that if two different responses were
464   sent by the origin server during the same second, but both had the
465   same Last-Modified time, then at least one of those responses would
466   have a Date value equal to its Last-Modified time.  The arbitrary 60-
467   second limit guards against the possibility that the Date and Last-
468   Modified values are generated from different clocks, or at somewhat
469   different times during the preparation of the response.  An
470   implementation MAY use a value larger than 60 seconds, if it is
471   believed that 60 seconds is too short.
472
473   If a client wishes to perform a sub-range retrieval on a value for
474   which it has only a Last-Modified time and no opaque validator, it
475   MAY do this only if the Last-Modified time is strong in the sense
476   described here.
477
478   A cache or origin server receiving a conditional range request
479   ([Part5]) MUST use the strong comparison function to evaluate the
480   condition.
481
482   These rules allow HTTP/1.1 caches and clients to safely perform sub-
483   range retrievals on values that have been obtained from HTTP/1.0
484   servers.
485
486
4875.  Rules for When to Use Entity Tags and Last-Modified Dates
488
489   We adopt a set of rules and recommendations for origin servers,
490   clients, and caches regarding when various validator types ought to
491   be used, and for what purposes.
492
493   HTTP/1.1 origin servers:
494
495   o  SHOULD send an entity tag validator unless it is not feasible to
496      generate one.
497
498   o  MAY send a weak entity tag instead of a strong entity tag, if
499      performance considerations support the use of weak entity tags, or
500
501
502
503Fielding, et al.       Expires September 10, 2009               [Page 9]
504
505Internet-Draft              HTTP/1.1, Part 4                  March 2009
506
507
508      if it is unfeasible to send a strong entity tag.
509
510   o  SHOULD send a Last-Modified value if it is feasible to send one,
511      unless the risk of a breakdown in semantic transparency that could
512      result from using this date in an If-Modified-Since header would
513      lead to serious problems.
514
515   In other words, the preferred behavior for an HTTP/1.1 origin server
516   is to send both a strong entity tag and a Last-Modified value.
517
518   In order to be legal, a strong entity tag MUST change whenever the
519   associated entity changes in any way.  A weak entity tag SHOULD
520   change whenever the associated entity changes in a semantically
521   significant way.
522
523      Note: in order to provide semantically transparent caching, an
524      origin server must avoid reusing a specific strong entity tag
525      value for two different entities, or reusing a specific weak
526      entity tag value for two semantically different entities.  Cache
527      entries might persist for arbitrarily long periods, regardless of
528      expiration times, so it might be inappropriate to expect that a
529      cache will never again attempt to validate an entry using a
530      validator that it obtained at some point in the past.
531
532   HTTP/1.1 clients:
533
534   o  If an entity tag has been provided by the origin server, MUST use
535      that entity tag in any cache-conditional request (using If-Match
536      or If-None-Match).
537
538   o  If only a Last-Modified value has been provided by the origin
539      server, SHOULD use that value in non-subrange cache-conditional
540      requests (using If-Modified-Since).
541
542   o  If only a Last-Modified value has been provided by an HTTP/1.0
543      origin server, MAY use that value in subrange cache-conditional
544      requests (using If-Unmodified-Since:).  The user agent SHOULD
545      provide a way to disable this, in case of difficulty.
546
547   o  If both an entity tag and a Last-Modified value have been provided
548      by the origin server, SHOULD use both validators in cache-
549      conditional requests.  This allows both HTTP/1.0 and HTTP/1.1
550      caches to respond appropriately.
551
552   An HTTP/1.1 origin server, upon receiving a conditional request that
553   includes both a Last-Modified date (e.g., in an If-Modified-Since or
554   If-Unmodified-Since header field) and one or more entity tags (e.g.,
555   in an If-Match, If-None-Match, or If-Range header field) as cache
556
557
558
559Fielding, et al.       Expires September 10, 2009              [Page 10]
560
561Internet-Draft              HTTP/1.1, Part 4                  March 2009
562
563
564   validators, MUST NOT return a response status of 304 (Not Modified)
565   unless doing so is consistent with all of the conditional header
566   fields in the request.
567
568   An HTTP/1.1 caching proxy, upon receiving a conditional request that
569   includes both a Last-Modified date and one or more entity tags as
570   cache validators, MUST NOT return a locally cached response to the
571   client unless that cached response is consistent with all of the
572   conditional header fields in the request.
573
574      Note: The general principle behind these rules is that HTTP/1.1
575      servers and clients should transmit as much non-redundant
576      information as is available in their responses and requests.
577      HTTP/1.1 systems receiving this information will make the most
578      conservative assumptions about the validators they receive.
579
580      HTTP/1.0 clients and caches will ignore entity tags.  Generally,
581      last-modified values received or used by these systems will
582      support transparent and efficient caching, and so HTTP/1.1 origin
583      servers should provide Last-Modified values.  In those rare cases
584      where the use of a Last-Modified value as a validator by an
585      HTTP/1.0 system could result in a serious problem, then HTTP/1.1
586      origin servers should not provide one.
587
588
5896.  Header Field Definitions
590
591   This section defines the syntax and semantics of HTTP/1.1 header
592   fields related to conditional requests.
593
594   For entity-header fields, both sender and recipient refer to either
595   the client or the server, depending on who sends and who receives the
596   entity.
597
5986.1.  ETag
599
600   The response-header field "ETag" provides the current value of the
601   entity tag (see Section 2) for the requested variant.  The headers
602   used with entity tags are described in Sections 6.2 and 6.4 of this
603   document, and in Section 5.3 of [Part5].  The entity tag MAY be used
604   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 10, 2009              [Page 11]
616
617Internet-Draft              HTTP/1.1, Part 4                  March 2009
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 request-header field "If-Match" is used with a method to make it
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.  Entity tags are defined in Section 2.  The
648   purpose of this feature is to allow efficient updates of cached
649   information with a minimum amount of transaction overhead.  It is
650   also used, on updating requests, to prevent inadvertent modification
651   of the wrong version of a resource.  As a special case, the value "*"
652   matches any current entity of the resource.
653
654     If-Match   = "If-Match" ":" OWS If-Match-v
655     If-Match-v = "*" / 1#entity-tag
656
657   If any of the entity tags match the entity tag of the entity that
658   would have been returned in the response to a similar GET request
659   (without the If-Match header) on that resource, or if "*" is given
660   and any current entity exists for that resource, then the server MAY
661   perform the requested method as if the If-Match header field did not
662   exist.
663
664   A server MUST use the strong comparison function (see Section 4) to
665   compare the entity tags in If-Match.
666
667   If none of the entity tags match, or if "*" is given and no current
668
669
670
671Fielding, et al.       Expires September 10, 2009              [Page 12]
672
673Internet-Draft              HTTP/1.1, Part 4                  March 2009
674
675
676   entity exists, the server MUST NOT perform the requested method, and
677   MUST return a 412 (Precondition Failed) response.  This behavior is
678   most useful when the client wants to prevent an updating method, such
679   as PUT, from modifying a resource that has changed since the client
680   last retrieved it.
681
682   If the request would, without the If-Match header field, result in
683   anything other than a 2xx or 412 status, then the If-Match header
684   MUST be ignored.
685
686   The meaning of "If-Match: *" is that the method SHOULD be performed
687   if the representation selected by the origin server (or by a cache,
688   possibly using the Vary mechanism, see Section 3.5 of [Part6])
689   exists, and MUST NOT be performed if the representation does not
690   exist.
691
692   A request intended to update a resource (e.g., a PUT) MAY include an
693   If-Match header field to signal that the request method MUST NOT be
694   applied if the entity corresponding to the If-Match value (a single
695   entity tag) is no longer a representation of that resource.  This
696   allows the user to indicate that they do not wish the request to be
697   successful if the resource has been changed without their knowledge.
698   Examples:
699
700     If-Match: "xyzzy"
701     If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
702     If-Match: *
703
704   The result of a request having both an If-Match header field and
705   either an If-None-Match or an If-Modified-Since header fields is
706   undefined by this specification.
707
7086.3.  If-Modified-Since
709
710   The request-header field "If-Modified-Since" is used with a method to
711   make it conditional: if the requested variant has not been modified
712   since the time specified in this field, an entity will not be
713   returned from the server; instead, a 304 (Not Modified) response will
714   be returned without any message-body.
715
716     If-Modified-Since   = "If-Modified-Since" ":" OWS
717                           If-Modified-Since-v
718     If-Modified-Since-v = HTTP-date
719
720   An example of the field is:
721
722     If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
723
724
725
726
727Fielding, et al.       Expires September 10, 2009              [Page 13]
728
729Internet-Draft              HTTP/1.1, Part 4                  March 2009
730
731
732   A GET method with an If-Modified-Since header and no Range header
733   requests that the identified entity be transferred only if it has
734   been modified since the date given by the If-Modified-Since header.
735   The algorithm for determining this includes the following cases:
736
737   1.  If the request would normally result in anything other than a 200
738       (OK) status, or if the passed If-Modified-Since date is invalid,
739       the response is exactly the same as for a normal GET.  A date
740       which is later than the server's current time is invalid.
741
742   2.  If the variant has been modified since the If-Modified-Since
743       date, the response is exactly the same as for a normal GET.
744
745   3.  If the variant has not been modified since a valid If-Modified-
746       Since date, the server SHOULD return a 304 (Not Modified)
747       response.
748
749   The purpose of this feature is to allow efficient updates of cached
750   information with a minimum amount of transaction overhead.
751
752      Note: The Range request-header field modifies the meaning of If-
753      Modified-Since; see Section 5.4 of [Part5] for full details.
754
755      Note: If-Modified-Since times are interpreted by the server, whose
756      clock might not be synchronized with the client.
757
758      Note: When handling an If-Modified-Since header field, some
759      servers will use an exact date comparison function, rather than a
760      less-than function, for deciding whether to send a 304 (Not
761      Modified) response.  To get best results when sending an If-
762      Modified-Since header field for cache validation, clients are
763      advised to use the exact date string received in a previous Last-
764      Modified header field whenever possible.
765
766      Note: If a client uses an arbitrary date in the If-Modified-Since
767      header instead of a date taken from the Last-Modified header for
768      the same request, the client should be aware of the fact that this
769      date is interpreted in the server's understanding of time.  The
770      client should consider unsynchronized clocks and rounding problems
771      due to the different encodings of time between the client and
772      server.  This includes the possibility of race conditions if the
773      document has changed between the time it was first requested and
774      the If-Modified-Since date of a subsequent request, and the
775      possibility of clock-skew-related problems if the If-Modified-
776      Since date is derived from the client's clock without correction
777      to the server's clock.  Corrections for different time bases
778      between client and server are at best approximate due to network
779      latency.
780
781
782
783Fielding, et al.       Expires September 10, 2009              [Page 14]
784
785Internet-Draft              HTTP/1.1, Part 4                  March 2009
786
787
788   The result of a request having both an If-Modified-Since header field
789   and either an If-Match or an If-Unmodified-Since header fields is
790   undefined by this specification.
791
7926.4.  If-None-Match
793
794   The request-header field "If-None-Match" is used with a method to
795   make it conditional.  A client that has one or more entities
796   previously obtained from the resource can verify that none of those
797   entities is current by including a list of their associated entity
798   tags in the If-None-Match header field.  The purpose of this feature
799   is to allow 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   See Section 4 for rules on how to determine if two entity tags match.
824
825   If none of the entity tags match, then the server MAY perform the
826   requested method as if the If-None-Match header field did not exist,
827   but MUST also ignore any If-Modified-Since header field(s) in the
828   request.  That is, if no entity tags match, then the server MUST NOT
829   return a 304 (Not Modified) response.
830
831   If the request would, without the If-None-Match header field, result
832   in anything other than a 2xx or 304 status, then the If-None-Match
833   header MUST be ignored.  (See Section 5 for a discussion of server
834   behavior when both If-Modified-Since and If-None-Match appear in the
835   same request.)
836
837
838
839Fielding, et al.       Expires September 10, 2009              [Page 15]
840
841Internet-Draft              HTTP/1.1, Part 4                  March 2009
842
843
844   The meaning of "If-None-Match: *" is that the method MUST NOT be
845   performed if the representation selected by the origin server (or by
846   a cache, possibly using the Vary mechanism, see Section 3.5 of
847   [Part6]) exists, and SHOULD be performed if the representation does
848   not exist.  This feature is intended to be useful in preventing races
849   between PUT operations.
850
851   Examples:
852
853     If-None-Match: "xyzzy"
854     If-None-Match: W/"xyzzy"
855     If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
856     If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
857     If-None-Match: *
858
859   The result of a request having both an If-None-Match header field and
860   either an If-Match or an If-Unmodified-Since header fields is
861   undefined by this specification.
862
8636.5.  If-Unmodified-Since
864
865   The request-header field "If-Unmodified-Since" is used with a method
866   to make it conditional.  If the requested resource has not been
867   modified since the time specified in this field, the server SHOULD
868   perform the requested operation as if the If-Unmodified-Since header
869   were not present.
870
871   If the requested variant has been modified since the specified time,
872   the server MUST NOT perform the requested operation, and MUST return
873   a 412 (Precondition Failed).
874
875     If-Unmodified-Since   = "If-Unmodified-Since" ":" OWS
876                             If-Unmodified-Since-v
877     If-Unmodified-Since-v = HTTP-date
878
879   An example of the field is:
880
881     If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
882
883   If the request normally (i.e., without the If-Unmodified-Since
884   header) would result in anything other than a 2xx or 412 status, the
885   If-Unmodified-Since header SHOULD be ignored.
886
887   If the specified date is invalid, the header is ignored.
888
889   The result of a request having both an If-Unmodified-Since header
890   field and either an If-None-Match or an If-Modified-Since header
891   fields is undefined by this specification.
892
893
894
895Fielding, et al.       Expires September 10, 2009              [Page 16]
896
897Internet-Draft              HTTP/1.1, Part 4                  March 2009
898
899
9006.6.  Last-Modified
901
902   The entity-header field "Last-Modified" 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.  Message Header Registration
943
944   The Message Header Registry located at <http://www.iana.org/
945   assignments/message-headers/message-header-index.html> should be
946   updated with the permanent registrations below (see [RFC3864]):
947
948
949
950
951Fielding, et al.       Expires September 10, 2009              [Page 17]
952
953Internet-Draft              HTTP/1.1, Part 4                  March 2009
954
955
956   +---------------------+----------+----------+-------------+
957   | Header Field Name   | Protocol | Status   | Reference   |
958   +---------------------+----------+----------+-------------+
959   | ETag                | http     | standard | Section 6.1 |
960   | If-Match            | http     | standard | Section 6.2 |
961   | If-Modified-Since   | http     | standard | Section 6.3 |
962   | If-None-Match       | http     | standard | Section 6.4 |
963   | If-Unmodified-Since | http     | standard | Section 6.5 |
964   | Last-Modified       | http     | standard | Section 6.6 |
965   +---------------------+----------+----------+-------------+
966
967   The change controller is: "IETF (iesg@ietf.org) - Internet
968   Engineering Task Force".
969
970
9718.  Security Considerations
972
973   No additional security considerations have been identified beyond
974   those applicable to HTTP in general [Part1].
975
976
9779.  Acknowledgments
978
979
98010.  References
981
98210.1.  Normative References
983
984   [Part1]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
985              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
986              and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
987              and Message Parsing", draft-ietf-httpbis-p1-messaging-06
988              (work in progress), March 2009.
989
990   [Part5]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
991              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
992              and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
993              Partial Responses", draft-ietf-httpbis-p5-range-06 (work
994              in progress), March 2009.
995
996   [Part6]    Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
997              Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
998              and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",
999              draft-ietf-httpbis-p6-cache-06 (work in progress),
1000              March 2009.
1001
1002   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
1003              Requirement Levels", BCP 14, RFC 2119, March 1997.
1004
1005
1006
1007Fielding, et al.       Expires September 10, 2009              [Page 18]
1008
1009Internet-Draft              HTTP/1.1, Part 4                  March 2009
1010
1011
1012   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
1013              Specifications: ABNF", STD 68, RFC 5234, January 2008.
1014
101510.2.  Informative References
1016
1017   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
1018              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
1019              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
1020
1021   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
1022              Procedures for Message Header Fields", BCP 90, RFC 3864,
1023              September 2004.
1024
1025
1026Appendix A.  Compatibility with Previous Versions
1027
1028A.1.  Changes from RFC 2616
1029
1030   Allow weak entity tags in all requests except range requests
1031   (Sections 4 and 6.4).
1032
1033
1034
1035
1036
1037
1038
1039
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 September 10, 2009              [Page 19]
1064
1065Internet-Draft              HTTP/1.1, Part 4                  March 2009
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 3.2.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 = "W/"
1099
1100
1101
1102   ABNF diagnostics:
1103
1104   ; ETag defined but not used
1105   ; If-Match defined but not used
1106   ; If-Modified-Since defined but not used
1107   ; If-None-Match defined but not used
1108   ; If-Unmodified-Since defined but not used
1109   ; Last-Modified defined but not used
1110
1111
1112Appendix C.  Change Log (to be removed by RFC Editor before publication)
1113
1114
1115
1116
1117
1118
1119Fielding, et al.       Expires September 10, 2009              [Page 20]
1120
1121Internet-Draft              HTTP/1.1, Part 4                  March 2009
1122
1123
1124C.1.  Since RFC2616
1125
1126   Extracted relevant partitions from [RFC2616].
1127
1128C.2.  Since draft-ietf-httpbis-p4-conditional-00
1129
1130   Closed issues:
1131
1132   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
1133      Informative references"
1134
1135   Other changes:
1136
1137   o  Move definitions of 304 and 412 condition codes from Part2.
1138
1139C.3.  Since draft-ietf-httpbis-p4-conditional-01
1140
1141   Ongoing work on ABNF conversion
1142   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
1143
1144   o  Add explicit references to BNF syntax and rules imported from
1145      other parts of the specification.
1146
1147C.4.  Since draft-ietf-httpbis-p4-conditional-02
1148
1149   Closed issues:
1150
1151   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/116>: "Weak ETags on
1152      non-GET requests"
1153
1154   Ongoing work on IANA Message Header Registration
1155   (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
1156
1157   o  Reference RFC 3984, and update header registrations for headers
1158      defined in this document.
1159
1160C.5.  Since draft-ietf-httpbis-p4-conditional-03
1161
1162   Closed issues:
1163
1164   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/71>: "Examples for
1165      ETag matching"
1166
1167   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/124>: "'entity
1168      value' undefined"
1169
1170   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/126>: "bogus 2068
1171      Date header reference"
1172
1173
1174
1175Fielding, et al.       Expires September 10, 2009              [Page 21]
1176
1177Internet-Draft              HTTP/1.1, Part 4                  March 2009
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
1201
1202Index
1203
1204   3
1205      304 Not Modified (status code)  6
1206
1207   4
1208      412 Precondition Failed (status code)  6
1209
1210   E
1211      ETag header  11
1212
1213   G
1214      Grammar
1215         entity-tag  5
1216         ETag  11
1217         ETag-v  11
1218         If-Match  12
1219         If-Match-v  12
1220         If-Modified-Since  13
1221         If-Modified-Since-v  13
1222         If-None-Match  15
1223         If-None-Match-v  15
1224         If-Unmodified-Since  16
1225         If-Unmodified-Since-v  16
1226         Last-Modified  17
1227         Last-Modified-v  17
1228
1229
1230
1231Fielding, et al.       Expires September 10, 2009              [Page 22]
1232
1233Internet-Draft              HTTP/1.1, Part 4                  March 2009
1234
1235
1236         opaque-tag  5
1237         weak  5
1238
1239   H
1240      Headers
1241         ETag  11
1242         If-Match  12
1243         If-Modified-Since  13
1244         If-None-Match  15
1245         If-Unmodified-Since  16
1246         Last-Modified  17
1247
1248   I
1249      If-Match header  12
1250      If-Modified-Since header  13
1251      If-None-Match header  15
1252      If-Unmodified-Since header  16
1253
1254   L
1255      Last-Modified header  17
1256
1257   S
1258      Status Codes
1259         304 Not Modified  6
1260         412 Precondition Failed  6
1261
1262
1263Authors' Addresses
1264
1265   Roy T. Fielding (editor)
1266   Day Software
1267   23 Corporate Plaza DR, Suite 280
1268   Newport Beach, CA  92660
1269   USA
1270
1271   Phone: +1-949-706-5300
1272   Fax:   +1-949-706-5305
1273   Email: fielding@gbiv.com
1274   URI:   http://roy.gbiv.com/
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287Fielding, et al.       Expires September 10, 2009              [Page 23]
1288
1289Internet-Draft              HTTP/1.1, Part 4                  March 2009
1290
1291
1292   Jim Gettys
1293   One Laptop per Child
1294   21 Oak Knoll Road
1295   Carlisle, MA  01741
1296   USA
1297
1298   Email: jg@laptop.org
1299   URI:   http://www.laptop.org/
1300
1301
1302   Jeffrey C. Mogul
1303   Hewlett-Packard Company
1304   HP Labs, Large Scale Systems Group
1305   1501 Page Mill Road, MS 1177
1306   Palo Alto, CA  94304
1307   USA
1308
1309   Email: JeffMogul@acm.org
1310
1311
1312   Henrik Frystyk Nielsen
1313   Microsoft Corporation
1314   1 Microsoft Way
1315   Redmond, WA  98052
1316   USA
1317
1318   Email: henrikn@microsoft.com
1319
1320
1321   Larry Masinter
1322   Adobe Systems, Incorporated
1323   345 Park Ave
1324   San Jose, CA  95110
1325   USA
1326
1327   Email: LMM@acm.org
1328   URI:   http://larry.masinter.net/
1329
1330
1331   Paul J. Leach
1332   Microsoft Corporation
1333   1 Microsoft Way
1334   Redmond, WA  98052
1335
1336   Email: paulle@microsoft.com
1337
1338
1339
1340
1341
1342
1343Fielding, et al.       Expires September 10, 2009              [Page 24]
1344
1345Internet-Draft              HTTP/1.1, Part 4                  March 2009
1346
1347
1348   Tim Berners-Lee
1349   World Wide Web Consortium
1350   MIT Computer Science and Artificial Intelligence Laboratory
1351   The Stata Center, Building 32
1352   32 Vassar Street
1353   Cambridge, MA  02139
1354   USA
1355
1356   Email: timbl@w3.org
1357   URI:   http://www.w3.org/People/Berners-Lee/
1358
1359
1360   Yves Lafon (editor)
1361   World Wide Web Consortium
1362   W3C / ERCIM
1363   2004, rte des Lucioles
1364   Sophia-Antipolis, AM  06902
1365   France
1366
1367   Email: ylafon@w3.org
1368   URI:   http://www.raubacapeu.net/people/yves/
1369
1370
1371   Julian F. Reschke (editor)
1372   greenbytes GmbH
1373   Hafenweg 16
1374   Muenster, NW  48155
1375   Germany
1376
1377   Phone: +49 251 2807760
1378   Fax:   +49 251 2807761
1379   Email: julian.reschke@greenbytes.de
1380   URI:   http://greenbytes.de/tech/webdav/
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399Fielding, et al.       Expires September 10, 2009              [Page 25]
1400
Note: See TracBrowser for help on using the repository browser.