idnits 2.17.1 draft-ietf-webdav-redirectref-protocol-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 27 longer pages, the longest (page 1) being 62 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 28 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 57 instances of lines with control characters in the document. ** The abstract seems to contain references ([B], [OC]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 13 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 20, 2000) is 8830 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Alvestrand' is mentioned on line 1372, but not defined ** Obsolete normative reference: RFC 2396 (ref. 'URI') (Obsoleted by RFC 3986) -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' ** Obsolete normative reference: RFC 2616 (ref. 'HTTP') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2518 (ref. 'WebDAV') (Obsoleted by RFC 4918) == Outdated reference: A later version (-02) exists of draft-ietf-webdav-binding-protocol-00 -- Possible downref: Normative reference to a draft: ref. 'B' == Outdated reference: A later version (-10) exists of draft-ietf-webdav-ordering-protocol-00 Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 WEBDAV Working Group J. Slein, Xerox 2 INTERNET DRAFT E.J. Whitehead Jr., UC Irvine 3 J. Davis, CourseNet 4 G. Clemm, Rational 5 C. Fay, FileNet 6 J. Crawford, IBM 7 T. Chihaya, DataChannel 8 August 20, 1999 9 Expires February 20, 2000 11 WebDAV Redirect Reference Resources 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with all 16 provisions of Section 10 of RFC2026. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, and 18 its working groups. Note that other groups may also distribute working 19 documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference material 24 or to cite them other than as "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Distribution of this document is unlimited. Please send comments to the 33 Distributed Authoring and Versioning (WebDAV) working group at , which may be joined by sending a message with subject 35 "subscribe" to . 37 Discussions of the WEBDAV working group are archived at URL: 38 . 40 Abstract 42 The WebDAV Distributed Authoring Protocol provides basic support for 43 collections, offering the ability to create and list unordered 44 collections. 46 This specification is one of a group of three specifications that 47 supplement the WebDAV Distributed Authoring Protocol to increase the 48 power of WebDAV collections. This specification defines redirect 49 reference resources, one mechanism for allowing a single resource to 50 appear in more than one collection. A redirect reference resource is a 51 resource in one collection that responds to most requests by redirecting 52 the request (using an HTTP 1.1 302 Moved Temporarily response) to a 53 different resource, possibly in a different collection. [B] defines 54 bindings, another approach to allowing a single resource to be accessed 55 from multiple collections. [OC] provides ordered collections. 57 Table of Contents 59 1 Notational Conventions.......................................3 60 2 Introduction.................................................3 61 3 Terminology..................................................4 62 4 Overview of Redirect Reference Resources.....................5 63 5 MKREF Method.................................................5 64 5.1 Overview of MKREF............................................5 65 5.2 Status Codes.................................................6 66 5.3 Example: MKREF...............................................6 67 6 Listing the Redirect Reference Resources in a Collection.....6 68 6.1 Example: PROPFIND on a Collection with Redirect Reference 69 Resources....................................................7 70 6.2 Example: PROPFIND with Passthrough: F on a Collection with 71 Redirect Reference Resources.................................9 72 7 Copying Redirect Reference Resources........................10 73 7.1 Example: COPY on a Redirect Reference Resource..............11 74 7.2 Example: COPY on a Collection That Contains a Redirect 75 Reference Resource..........................................11 76 8 Deleting and Moving Redirect Reference Resources............12 77 9 Locking Redirect Reference Resources........................12 78 9.1 Example: LOCK on a Redirect Reference Resource..............14 79 9.2 Example: LOCK on a Collection That Contains a Redirect 80 Reference Resource, with Passthrough: T.....................15 81 10 Other Operations on Redirect Reference Resources............16 82 10.1 Example: GET on a Redirect Reference Resource...............17 83 10.2 Example: PUT on a Redirect Reference Resource with 84 "Passthrough: F"............................................18 85 10.3 Example: PROPPATCH on a Redirect Reference Resource.........18 86 11 Operations on Targets of Redirect Reference Resources.......19 87 12 Relative URIs in Ref-Target and DAV:reftarget...............19 88 12.1 Example: Resolving a Relative URI in Ref-Target.............19 89 12.2 Example: Resolving a Relative URI in DAV:reftarget..........20 90 13 Redirect References to Collections..........................21 91 14 Headers.....................................................21 92 14.1 Ref-Target Entity Header....................................21 93 14.2 Resource-Type Entity Header.................................22 94 14.3 Passthrough Request Header..................................22 95 15 Properties..................................................22 96 15.1 reftarget Property..........................................22 97 15.2 location Pseudo-Property....................................23 98 16 XML Elements................................................23 99 16.1 redirectref XML Element.....................................23 100 17 Extensions to the DAV:response XML Element for Multi-Status 101 Responses...................................................23 102 18 Capability Discovery........................................23 103 18.1 Example: Discovery of Support for Redirect Reference 104 Resources...................................................24 105 19 Security Considerations.....................................24 106 19.1 Privacy Concerns............................................24 107 19.2 Redirect Loops..............................................25 108 19.3 Redirect Reference Resources and Denial of Service..........25 109 19.4 Private Locations May Be Revealed...........................25 110 20 Internationalization Considerations.........................25 111 21 IANA Considerations.........................................26 112 22 Copyright...................................................26 113 23 Intellectual Property.......................................26 114 24 Acknowledgements............................................26 115 25 References..................................................26 116 26 Authors' Addresses..........................................27 117 27 Appendices..................................................28 118 27.1 Appendix 1: Extensions to the WebDAV Document Type 119 Definition..................................................28 121 1 Notational Conventions 123 Since this document describes a set of extensions to the HTTP/1.1 124 protocol, the augmented BNF used here to describe protocol elements is 125 exactly the same as described in Section 2.1 of [HTTP]. Since this 126 augmented BNF uses the basic production rules provided in Section 2.2 of 127 [HTTP], these rules apply to this document as well. 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 2 Introduction 135 The simple collections that the WebDAV Distributed Authoring Protocol 136 specification supports are powerful enough to be widely useful. They 137 provide for the hierarchical organization of resources, with mechanisms 138 for creating and deleting collections, copying and moving them, locking 139 them, adding members to them and removing members from them, and getting 140 listings of their members. Delete, copy, move, list, and lock 141 operations can be applied recursively, so that a client can operate on 142 whole hierarchies with a single request. 144 This specification is one of a family of three specifications that build 145 on the infrastructure defined in [HTTP] and [WebDAV] to extend the 146 capabilities of collections. The companion specification [OC] defines 147 protocol extensions to support ordered collections. The present 148 specification and the companion specification [B] define mechanisms for 149 allowing the same resource to appear in multiple collections. This 150 capability is useful for several reasons: 152 Organizing resources into hierarchies places them into smaller 153 groupings, known as collections, which are more easily browsed and 154 manipulated than a flat namespace. However, hierarchies require 155 categorization decisions that locate resources at a single location in 156 the hierarchy, a drawback when a resource has multiple valid categories. 157 For example, in a hierarchy of vehicle descriptions containing 158 collections for cars and boats, a description of a combination car/boat 159 vehicle could belong in either collection. Ideally, the description 160 should be accessible from both. 162 Hierarchies also make resource sharing more difficult, since resources 163 that have utility across many collections are still forced into a single 164 collection. For example, the mathematics department at one university 165 might create a collection of information on fractals that contains 166 bindings to some local resources, but also provides access to some 167 resources at other universities. For many reasons, it may be 168 undesirable to make physical copies of the shared resources on the local 169 server - to conserve disk space, to respect copyright constraints, or to 170 make any changes in the shared resources visible automatically. 172 The BIND method defined in [B] provides one mechanism for allowing a 173 single resource to appear in multiple collections. It lets clients 174 associate a new URI with an existing resource. This URI can then be 175 used to submit requests to the resource. Since URIs in WebDAV are 176 hierarchical, and correspond to a hierarchy of collections in resource 177 space, the BIND method also has the effect of adding the resource to a 178 collection. As new URIs are associated with the resource, it appears in 179 additional collections. 181 The redirect reference resources defined here are a different mechanism 182 for allowing a single resource to appear in multiple collections. A 183 redirect reference resource is a resource in one collection whose 184 purpose is to forward requests to another resource (its target), usually 185 in a different collection. In this way, it allows clients to submit 186 requests to the target resource from another collection. It redirects 187 most requests to the target resource using the HTTP 302 (Moved 188 Temporarily) status code, thereby providing a form of mediated access to 189 the target resource. 191 These two approaches to allowing clients to add a single resource to 192 multiple collections have very different characteristics: 194 A redirect reference is a resource, and so can have properties of its 195 own. Such information as who created the reference, when, and why can 196 be stored on the redirect reference resource. Since redirect references 197 are implemented using HTTP 302 responses, it generally takes two round 198 trips to submit a request to the intended resource. Servers are not 199 required to enforce the integrity of redirect references. Redirect 200 references work equally well for local resources and for resources that 201 reside on a different server from the reference. 203 By contrast, a BIND request does not create a new resource, but simply 204 makes available a new URI for submitting requests to an existing 205 resource. The new URI can be used like any other URI to submit a 206 request to a resource. Only one round trip is needed to submit a 207 request to the intended target. Servers are required to enforce the 208 integrity of the relationships between the new URIs clients create and 209 the resources associated with them. Consequently, it is unlikely that 210 servers will support BIND requests that cross server boundaries. 212 3 Terminology 214 The terminology used here follows and extends that in the WebDAV 215 Distributed Authoring Protocol specification [WebDAV]. Definitions of 216 the terms resource, Uniform Resource Identifier (URI), and Uniform 217 Resource Locator (URL) are provided in [URI]. 219 Reference Resource 220 A resource whose purpose is to forward requests to another 221 resource. Reference resources are an alternative mechanism to 222 bindings (defined in [B]) for allowing clients to create multiple 223 URIs that can be used to submit requests to the same resource. 225 Redirect Reference Resource 226 A resource that forwards requests to another resource using the 227 HTTP 1.1 302 (Moved Temporarily) response mechanism. The client 228 is aware that this type of reference resource is mediating between 229 it and the target resource. 231 Non-Reference Resource 232 A resource that is not a reference to another resource. 234 Target Resource 235 The resource to which requests are forwarded by a reference 236 resource. 238 4 Overview of Redirect Reference Resources 240 For most operations submitted to a redirect reference resource, the 241 response is a 302 (Moved Temporarily), accompanied by the Resource-Type 242 header (defined in Section 14.2 below) set to "DAV:redirectref" and the 243 Location header set to the URI of the target resource. With this 244 information, the client can resubmit the request to the URI of the 245 target resource. The methods COPY (for collections containing redirect 246 reference resources), DELETE, MOVE, and LOCK, for reasons that will be 247 explained, are exceptions to this general behavior. These exceptional 248 operations are applied to the reference resource itself and do not 249 result in a 302 response. 251 If the client is aware that it is operating on a redirect reference 252 resource, it can resolve the reference by retrieving the reference 253 resource's DAV:reftarget property (defined in Section 15.1 below), whose 254 value contains the URI of the target resource. It can then submit 255 requests to the target resource. 257 A redirect reference resource is a new type of resource. To distinguish 258 redirect reference resources from non-reference resources, a new value 259 of the DAV:resourcetype property (defined in [WebDAV]), DAV:redirectref, 260 is defined in Section 16.1 below. 262 Since a redirect reference resource is a resource, it is possible to 263 apply methods to the reference resource rather than to its target 264 resource. The Passthrough request header (defined in Section 14.3 265 below) is provided so that referencing-aware clients can control whether 266 an operation is applied to the redirect reference resource or to its 267 target resource. The Passthrough header can be used with most requests 268 to redirect reference resources. This header is particularly useful 269 with PROPFIND, to retrieve the reference resource's own properties. 271 5 MKREF Method 273 5.1 Overview of MKREF 275 The MKREF method creates a redirect reference resource identified by the 276 Request-URI, whose target is identified by the REQUIRED Ref-Target 277 header. MKREF sets the value of the REQUIRED DAV:reftarget property to 278 the value of the Ref-Target header. 280 The MKREF method creates a new binding between the new redirect 281 reference resource and the last path segment of the Request-URI. The 282 new binding is added to its parent collection, identified by the 283 Request-URI minus its trailing slash (if present) and final segment. 285 MKREF requests MAY include an entity body. This specification does not 286 define the action to be taken if a request entity body is present, but 287 allows it for extensibility. 289 By default, if the Request-URI of the MKREF request identifies an 290 existing resource, the request MUST fail with a 405 (Method Not Allowed) 291 response code. This default behavior can be overridden using the 292 Overwrite header defined in Section 9.6 of [WebDAV]. 294 5.2 Status Codes 296 201 (Created): The redirect reference resource was successfully created. 298 400 (Bad Request): The client set an invalid value for the Ref-Target 299 header. 301 405 (Method Not Allowed): A resource already exists at the Request-URI. 303 409 (Conflict): Several conditions may produce this response. There may 304 be no resource at the location specified in Ref-Target, on a server that 305 prohibits dangling reference resources. The request may be attempting 306 to create the reference resource in a collection that does not exist. 308 412 (Precondition Failed): The Overwrite header is "F" or absent, and a 309 resource already exists at the request-URI. 311 5.3 Example: MKREF 313 >> Request: 315 MKREF /~whitehead/dav/spec08.ref HTTP/1.1 316 Host: www.ics.uci.edu 317 Ref-Target: 319 >> Response: 321 HTTP/1.1 201 Created 323 This request resulted in the creation of a new redirect reference 324 resource at www.ics.uci.edu/~whitehead/dav/spec08.ref, which points to 325 the resource identified by the Ref-Target header. In this example, the 326 target resource of the referential resource is identified by the URI 327 http://www.ics.uci.edu/~whitehead/dav/i-d/draft-webdav-protocol-08.txt. 328 The referential resource's DAV:resourcetype property is set to 329 DAV:redirectref. Its DAV:reftarget property is set to the value of the 330 Ref-Target header, "/i-d/draft-webdav-protocol-08.txt". 332 6 Listing the Redirect Reference Resources in a Collection 334 A URI of a redirect reference resource can be an internal member URI of 335 a collection just as the URI of a non-reference resource can. A listing 336 of the internal member URIs of a collection shows all of the URIs that 337 are internal members of the collection, whether they identify redirect 338 reference resources or non-reference resources. That is, a WebDAV 339 PROPFIND request on a collection resource with the Depth header set to 1 340 or infinity MUST return a response XML element for each member URI in 341 the collection, whether it identifies a non-reference resource or a 342 redirect reference resource. 344 For each redirect reference resource, the response element MUST contain 345 a 302 (Moved Temporarily) status code unless a Passthrough header with 346 the value "F" is included with the PROPFIND request. The DAV:location 347 pseudo-property and the DAV:resourcetype property MUST be included with 348 the 302 status code, extending the syntax of the DAV:response element 349 that was defined in [WebDAV] as described in Section 17 below. A 350 referencing-aware client can tell from the DAV:resourcetype property 351 that the collection contains a redirect reference resource. The 352 DAV:location pseudo-property contains the absolute URI of the target 353 resource. A referencing-aware client can either use the URI value of 354 the DAV:location pseudo-property to retrieve the properties of the 355 target resource, or it can submit a PROPFIND to the redirect reference 356 resource with "Passthrough: F" to retrieve its properties. It is 357 recommended that future editors of [WebDAV] define the DAV:location 358 pseudo-property in [WebDAV], so that non-referencing clients will also 359 be able to use the response to retrieve the properties of the target 360 resource. 362 If the Depth header is set to infinity in the PROPFIND request, the 363 server MUST NOT follow redirect reference resources into any collections 364 to which they may refer. 366 The Passthrough header (defined in Section 14.3) MAY be used with a 367 PROPFIND request on a collection. 369 6.1 Example: PROPFIND on a Collection with Redirect Reference Resources 371 Suppose a PROPFIND request with Depth = infinity is submitted to the 372 following collection, with the members shown here: 374 http://www.svr.com/MyCollection/ 375 (non-reference resource) diary.html 376 (redirect reference resource) nunavut 378 >> Request: 380 PROPFIND /MyCollection/ HTTP/1.1 381 Host: www.svr.com 382 Depth: infinity 383 Content-Type: text/xml 384 Content-Length: xxxx 386 387 388 389 390 392 393 395 >> Response: 397 HTTP/1.1 207 Multi-Status 398 Content-Type: text/xml 399 Content-Length: xxxx 401 402 404 405 http://www.svr.com/MyCollection/ 406 407 408 409 diary, interests, hobbies 410 411 HTTP/1.1 200 OK 412 413 414 415 http://www.svr.com/MyCollection/diary.html 416 417 418 419 diary, travel, family, history 420 421 HTTP/1.1 200 OK 422 423 424 425 http://www.svr.com/MyCollection/nunavut 426 HTTP/1.1 302 Moved Temporarily 427 428 429 http://www.inac.gc.ca/art/inuit/ 430 431 432 433 434 436 In this example the Depth header is set to infinity, and the Passthrough 437 header is not used. The collection contains one URI that identifies a 438 redirect reference resource. The response element for the redirect 439 reference resource has a status of 302 (Moved Temporarily), and includes 440 a DAV:prop element with the DAV:location pseudo-property and the 441 DAV:resourcetype property to allow clients to retrieve the properties of 442 its target resource. (The response element for the redirect reference 443 resource does not include the requested properties. The client can 444 submit another PROPFIND request to the URI in the DAV:location pseudo- 445 property to retrieve those properties.) 446 6.2 Example: PROPFIND with Passthrough: F on a Collection with Redirect 447 Reference Resources 449 Suppose a PROPFIND request with Passthrough = F and Depth = infinity is 450 submitted to the following collection, with the members shown here: 452 /MyCollection/ 453 (non-reference resource) diary.html 454 (redirect reference resource) nunavut 456 >> Request: 458 PROPFIND /MyCollection/ HTTP/1.1 459 Host: www.svr.com 460 Depth: infinity 461 Passthrough: F 462 Content-Type: text/xml 463 Content-Length: xxxx 465 466 467 468 469 470 471 473 >> Response: 475 HTTP/1.1 207 Multi-Status 476 Content-Type: text/xml 477 Content-Length: xxxx 479 480 481 482 http://www.svr.com/MyCollection/ 483 484 485 486 487 HTTP/1.1 200 OK 488 489 490 491 HTTP/1.1 404 Not Found 492 493 494 495 http://www.svr.com/MyCollection/diary.html 496 497 498 499 500 HTTP/1.1 200 OK 502 503 504 505 HTTP/1.1 404 Not Found 506 507 508 509 http://www.svr.com/MyCollection/nunavut 510 511 512 513 514 http://www.inac.gc.ca/art/inuit/ 515 516 517 HTTP/1.1 200 OK 518 519 520 522 Since the Passthrough header has the value "F", the response shows the 523 properties of the redirect reference resource in the collection rather 524 than the properties of its target. The value of the Passthrough header 525 also prevents a 302 response from being returned for the redirect 526 reference resource. 528 7 Copying Redirect Reference Resources 530 A client's intent in performing a COPY operation is to create a new 531 resource that is similar to the original resource and behaves like the 532 original resource, and that can be modified without affecting the 533 original resource. For a COPY request to a redirect reference resource, 534 the expectation would be a 302 response that the client could use to 535 copy the target resource. This would yield an independent resource that 536 could be modified without affecting the original resource. For COPY 537 requests to collections that contain redirect reference resources, the 538 situation is less clear. There is tension between two expectations. On 539 the one hand, the client may expect the new copy of the collection to 540 behave like the old one (which implies having reference resources where 541 the old one had reference resources). On the other hand, the client may 542 expect that it will be possible to modify the resources in the new 543 collection without affecting the resources in the old collection (which 544 implies having copies of the target resources where the original 545 collection had reference resources). 547 For a COPY request on an individual reference resource, the response 548 MUST be a 302 (Moved Temporarily) status code, with the URI of the 549 target resource in the Location header, and "Resource-Type: 550 DAV:redirectref" to distinguish the response from an ordinary HTTP 551 redirect. This is the normal behavior for redirect reference resources, 552 allowing the client to resubmit the request to the target resource 553 identified in the Location header. This also yields intuitively correct 554 behavior for a COPY request to an individual reference resource. 555 Reference-aware clients can use the Passthrough header with the value 556 "F" to copy the redirect reference resource itself. 558 For COPY on a collection containing redirect reference resources, 559 different semantics may be desirable in different scenarios. 560 Consequently, this specification makes a fairly arbitrary choice to take 561 the simplest path. When a COPY request is submitted to a collection 562 containing redirect reference resources, the server MUST copy the 563 redirect reference resources to the new collection rather than returning 564 302 status codes for them. This will result in a new collection that 565 behaves like the old one, and avoids responding with multiple 302 status 566 codes, each of which the client would have to process separately. 567 Reference-aware clients can force the server to respond with 302 status 568 codes rather than copying the reference resources by using the 569 Passthrough header with the value "T". 571 7.1 Example: COPY on a Redirect Reference Resource 573 >> Request: 575 COPY /MyCollection/tuva HTTP/1.1 576 Host: www.svr.com 577 Destination: http://www.svr.com/OtherCollection/tuva.html 579 >> Response: 581 HTTP/1.1 302 Moved Temporarily 582 Location: http://www.svr.com/Asia/History/tuva.html 583 Resource-Type: DAV:redirectref 585 In this example, the request-URI identifies a redirect reference 586 resource whose target resource is identified by 587 http://www.svr.com/Asia/History/tuva.html. In this case, the server 588 responded with a 302, and provided the URL of the target resource in the 589 Location header. The Resource-Type header indicates to a reference- 590 aware client that this is not an HTTP 1.1 redirect, but a reference to 591 the resource identified by the Location header. The client can now 592 resubmit the COPY request to the target resource, producing the desired 593 result: a duplicate of the original target resource that can be modified 594 independently of the original. 596 7.2 Example: COPY on a Collection That Contains a Redirect Reference 597 Resource 599 Suppose a COPY request is submitted to the following collection, with 600 the members shown: 602 /MyCollection/ 603 (non-reference resource) diary.html 604 (redirect reference resource) nunavut with target 605 /Someplace/nunavut.map 607 >> Request: 609 COPY /MyCollection/ HTTP/1.1 610 Host: www.svr.com 611 Destination: http://www.svr.com/OtherCollection/ 612 >> Response: 614 HTTP/1.1 201 Created 616 In this case, since /MyCollection/nunavut is a redirect reference 617 resource, the reference resource itself, and not its target resource, 618 was copied into the new collection. So the resulting collection is as 619 follows: 621 /OtherCollection/ 622 (non-reference resource) diary.html 623 (redirect reference resource) nunavut with target 624 /Someplace/nunavut.map 626 8 Deleting and Moving Redirect Reference Resources 628 The DELETE method is used to delete bindings to redirect reference 629 resources. DELETE MUST affect bindings to the reference resource itself, 630 unless "Passthrough: T" is used, in which case it generates a 302 (Moved 631 Temporarily) response. Similarly, when a DELETE on a collection 632 encounters a redirect reference resource in the subtree under that 633 collection, it MUST delete bindings to the reference resource, unless 634 "Passthrough: T" is used, in which case it generates a 302 (Moved 635 Temporarily) response. Whether deleting an individual resource or a 636 collection, DELETE on a redirect reference resource does not affect the 637 target of the reference resource. 639 A MOVE operation on a redirect reference resource MUST move the 640 reference resource to a different location, and MUST NOT change the 641 location of its target resource, unless "Passthrough: T" is used, in 642 which case a 302 (Moved Temporarily) response is generated. The 643 DAV:reftarget property is unchanged after a MOVE. Similarly, when a 644 MOVE on a collection encounters a redirect reference resource in the 645 subtree under that collection, it MUST move the reference resource, and 646 not its target, unless "Passthrough: T" is used, in which case a 302 647 (Moved Temporarily) response is generated. 649 DELETE and MOVE differ from other methods in that they do not alter the 650 resource that is being deleted or moved, but rather the collection that 651 contains its binding. They change the membership of that collection. 653 When a redirect reference resource is added to a collection, the aim is 654 to make it look as if the target resource were a member of that 655 collection. When the reference resource is removed from that 656 collection, the aim is to change the membership of that collection. 657 Membership of the target resource in any other collections, either 658 internally or by reference, should not be affected. Consequently, 659 DELETE and MOVE do not follow the normal rules of behavior for reference 660 resources. Instead, they are applied by default to the reference 661 resource itself, not to its target resource, and by default do not 662 result in 302 status codes. 664 9 Locking Redirect Reference Resources 665 The semantics of LOCK described here resulted from balancing a set of 666 incompatible considerations: 668 o Ideally, a LOCK on a redirect reference resource should lock both the 669 reference resource and its target resource. The owner of an 670 exclusive write lock, for example, would be surprised if anyone else 671 could modify the content of the target resource while he held the 672 lock. He would also be surprised if anyone else could delete the 673 reference to it, or replace the reference resource with one pointing 674 to a different target resource. 675 o Non-referencing clients should be able to use redirect reference 676 resources without encountering surprising results. 677 o The basic characteristics of redirect reference resources should be 678 honored. Redirect reference resources should be simple for servers 679 to implement. In particular, a server should never have to resolve a 680 redirect reference. A server should not have to provide proxy 681 capabilities in order to implement redirect references. 682 o There should be consistency between the behavior of LOCK on a single 683 redirect reference resource and the behavior of LOCK on a collection 684 that contains redirect reference resources. 685 o The behavior of all requests to redirect reference resources should 686 be as consistent as possible. In the absence of a Passthrough header, 687 all methods should return a 302 when sent to a redirect reference 688 resource. 689 o LOCK semantics for redirect reference resources should be consistent 690 with the LOCK semantics defined in [WebDAV]. 692 We have compromised the intuitive locking behavior and support for non- 693 referencing clients in order to preserve various sorts of consistency. 695 The behavior of LOCK for redirect reference resources was determined by 696 what is possible for the case of locking collections that contain 697 redirect reference resources. 699 The default behavior for any operation on a redirect reference resource 700 is that a 302 (Moved Temporarily) response will be returned, unless the 701 Passthrough header with a value of "F" is used. However, this policy 702 has unacceptable consequences when locking a collection that contains 703 redirect reference resources. Since [WebDAV] requires LOCK on a 704 collection to be an atomic operation, if a 302 response is received for 705 any member of the collection, the entire LOCK must fail. This would 706 make it impossible to lock any collection that contained a redirect 707 reference resource. 709 To avoid this result, a LOCK with Depth > 0 on a collection MUST lock 710 any redirect reference resources it encounters, and not return 302 711 responses for them, unless the Passthrough header with a value of "T" is 712 used. Use of the Passthrough header with a value of "T" in a LOCK 713 request on a collection will cause the entire lock to fail if a redirect 714 reference resource is encountered. 716 This gives part of the expected default lock behavior without forcing 717 the server to resolve the redirect reference or become a proxy server in 718 cases where the target resides on a different server. 720 There will be no hint in any response code that there are redirect 721 reference resources whose targets need to be locked. The client will 722 most likely not lock any target resources until it attempts an operation 723 on the target resource and gets a 302 response. It is possible that a 724 non-referencing client may never realize that the reference resource's 725 target has not been locked. 727 Clearly, a LOCK with Depth = infinity on a collection MUST NOT follow 728 any redirect reference resources whose targets are collections into the 729 target collections; it MUST NOT cause any resources in those target 730 collections to be locked. 732 The behavior of LOCK for individual redirect reference resources is 733 designed to be consistent with LOCK behavior for collections that 734 contain redirect reference resources. By default a LOCK on a redirect 735 reference resource MUST lock only the reference resource, not its target 736 resource, and it MUST NOT return a 302 response. A reference-aware 737 client can use the Passthrough header with a value of "T" to get a 302 738 response with the URI of the target resource in the Location header. 740 UNLOCK behaves as specified in [WebDAV], unlocking all resources 741 included in the lock identified by the Lock-Token header. 743 9.1 Example: LOCK on a Redirect Reference Resource 745 >> Request: 747 LOCK /MyCollection/tuva HTTP/1.1 748 Host: www.svr.com 749 Content-Type: text/xml 750 Content-Length: nnnn 751 Authorizaton: Digest username="jas", 752 realm=jas@webdav.sb.aol.com, nonce=". . . ", 753 uri="/MyCollection/tuva", 754 response=". . . ", opaque=". . . " 756 757 758 759 760 761 http://www.svr.com/~jas/contact.html 762 763 765 >> Response: 767 HTTP/1.1 200 OK 768 Content-Type: text/xml 769 Content-Length: nnnn 771 772 773 774 775 776 777 0 778 779 http://www.svr.com/~jas/contact.html 780 781 782 opaquelocktoken:e71dfae-5dec-22d6-fea5-00a0c91e6be4 783 784 785 786 788 The request and response look exactly as specified in [WebDAV]. In this 789 example, the request-URI, http://www.svr.com/MyCollection/tuva, 790 identifies a redirect reference resource, which was successfully locked. 791 The target resource of the redirect reference resource is not locked. 793 9.2 Example: LOCK on a Collection That Contains a Redirect Reference 794 Resource, with Passthrough: T 796 Suppose a LOCK request is submitted to the following collection, with 797 the members shown: 799 /MyCollection/ 800 (non-reference resource) diary.html 801 (redirect reference resource) nunavut 803 >> Request: 805 LOCK /MyCollection/ HTTP/1.1 806 Host: www.svr.com 807 Passthrough: T 808 Content-Type: text/xml 809 Content-Length: nnnn 810 Authorizaton: Digest username="jas", 811 realm=jas@webdav.sb.aol.com, nonce=". . . ", 812 uri="/MyCollection/tuva", 813 response=". . . ", opaque=". . . " 815 816 817 818 819 820 http://www.svr.com/~jas/contact.html 821 822 824 >> Response: 826 HTTP/1.1 207 Multi-Status 827 Content-Type: text/xml 828 Content-Length: nnnn 829 830 831 832 http://www.svr.com/MyCollection/ 833 834 835 HTTP/1.1 424 Failed Dependency 836 837 838 839 http://www.svr.com/MyCollection/diary.html 840 HTTP/1.1 424 Failed Dependency 841 842 843 http://www.svr.com/MyCollection/nunavut 844 HTTP/1.1 302 Moved Temporarily 845 846 847 http://www.inac.gc.ca/art/inuit/ 848 849 850 851 852 854 The "Passthrough: T" header caused the server to return a 302 response 855 code for the redirect reference resource in the collection. 856 Consequently, neither the collection nor any of the resources identified 857 by its internal member URIs were locked. A referencing-aware client can 858 submit a separate LOCK request to the URI in the DAV:location pseudo- 859 property returned for the redirect reference resource, and can resubmit 860 the LOCK request with "Passthrough: F" to the collection. At that point 861 both the reference resource and its target resource will be locked (as 862 well as the collection and all the resources identified by its other 863 members). 865 10 Other Operations on Redirect Reference Resources 867 Although non-referencing-aware clients cannot create reference 868 resources, they should be able to submit requests through the reference 869 resources created by reference-aware WebDAV clients. They should be 870 able to follow any references to their targets. To make this possible, 871 a server that receives a GET, HEAD, PUT, POST, OPTIONS, PROPFIND, 872 PROPPATCH, MKCOL, MKREF, BIND, or ORDERPATCH request made via a redirect 873 reference resource MUST return a 302 (Moved Temporarily) status code. 874 The client and server MUST follow [HTTP] Section 10.3.3 "302 Moved 875 Temporarily," but with these additional rules: 877 o The Location response header MUST contain the absolute target URI of 878 the reference resource. 880 o The response MUST include the Resource-Type header. This header 881 allows reference-aware WebDAV clients to recognize the resource as a 882 reference resource and understand the reason for the redirection. 884 A reference-aware WebDAV client can act on this response in one of two 885 ways. It can, like a non-referencing client, resubmit the request to 886 the URI in the Location header in order to operate on the target 887 resource. Alternatively, it can resubmit the request to the URI of the 888 redirect reference resource with the Passthrough header set to "F" in 889 order to operate on the reference resource itself. If the Passthrough 890 header is present with a value of "F", the request MUST be applied to 891 the reference resource itself, and a 302 response MUST NOT be returned. 893 If a reference-aware client knows before submitting its request that the 894 request-URI identifies a redirect reference resource, and if the client 895 wants to apply the method to the reference resource, it can save the 896 round trip caused by the 302 response by using "Passthrough: F" in its 897 initial request to the URI. 899 "Passthrough: F" can be used with GET or HEAD to retrieve the entity 900 headers of a redirect reference resource. When "Passthrough: F" is used 901 with GET or HEAD, the referencing entity headers (Ref-Type and Ref- 902 Target) MUST be returned, along with all HTTP headers that make sense 903 for reference resources (for example, Cache-Control, Age, ETag, Expires, 904 and Last-Modified). 906 "Passthrough: F" can be used with PUT to replace the redirect reference 907 resource with a non-reference resource. It can be used with OPTIONS to 908 retrieve the capabilities of a redirect reference resource. 910 Clients MUST NOT, however, use "Passthrough: F" with POST. Since a 911 reference resource cannot accept another entity as its subordinate, an 912 attempt to POST to a reference resource with "Passthrough: F" will also 913 fail. If a server receives a POST request with "Passthrough: F" on a 914 redirect reference resource, it MUST fail the request with a 400 (Bad 915 Request) status code. 917 Since MKCOL fails when applied to existing resources, if the client 918 attempts to resubmit the request to the target resource, the request 919 MUST fail (unless the reference resource is a dangling reference). 920 Similarly, if the client attempts to resubmit the request to the 921 reference resource with "Passthrough: F", the request MUST fail. 923 Since ORDERPATCH applies only to collections, an ORDERPATCH request with 924 a Passthrough header with the value "F" on a redirect reference resource 925 MUST fail. 927 10.1 Example: GET on a Redirect Reference Resource 929 >> Request: 931 GET /bar.html HTTP/1.1 932 Host: www.foo.com 934 >> Response: 936 HTTP/1.1 302 Moved Temporarily 937 Location: http://www.svr.com/Internet/xxspec08.html 938 Resource-Type: DAV:redirectref 939 Since /bar.html is a redirect reference resource and the Passthrough 940 header is not included in the request, the response is a 302 (Moved 941 Temporarily). The Resource-Type header informs a reference-aware client 942 that this is not an ordinary HTTP 1.1 redirect, but is a redirect 943 reference resource. The URI of the target resource is provided in the 944 Location header so that the client can resubmit the request to the 945 target resource. 947 10.2 Example: PUT on a Redirect Reference Resource with "Passthrough: F" 949 >> Request: 951 PUT /bar.html HTTP/1.1 952 Host: www.foo.com 953 Passthrough: F 954 Content-Type: text/xml; charset="utf-8" 955 Content-Length: xxxx 957 . . . some content . . . 959 >> Response: 961 HTTP/1.1 200 OK 963 Although /bar.html is a redirect reference resource, the presence of the 964 "Passthrough: F" header prevents a 302 response, and instead causes the 965 request to be applied to the reference resource. The result in this 966 case is that the reference resource is replaced by a non-reference 967 resource having the content submitted with the request. 969 10.3 Example: PROPPATCH on a Redirect Reference Resource 971 Request: 973 PROPPATCH /bar.html HTTP/1.1 974 Host: www.foo.com 975 Content-Type: text/xml; charset="utf-8" 976 Content-Length: xxxx 978 979 981 982 983 984 Jim Whitehead 985 Roy Fielding 986 987 988 989 990 991 992 994 Response: 996 HTTP/1.1 302 Moved Temporarily 997 Location: http://www.svr.com/Internet/xxspec08.html 998 Resource-Type: DAV:redirectref 1000 Since /bar.html is a redirect reference resource and the Passthrough 1001 header is not included in the request, the response is a 302 (Moved 1002 Temporarily). The Resource-Type header informs a reference-aware client 1003 that this is not an ordinary HTTP 1.1 redirect, but is a redirect 1004 reference resource. The URI of the target resource is provided in the 1005 Location header so that the client can resubmit the request to the 1006 target resource. 1008 11 Operations on Targets of Redirect Reference Resources 1010 Operations on targets of redirect reference resources have no effect on 1011 the reference resource. 1013 12 Relative URIs in Ref-Target and DAV:reftarget 1015 The URI in a Ref-Target header MAY be a relative URI. Similarly, the 1016 href in a DAV:reftarget property MAY be a relative URI. In both cases, 1017 the base URI to be used for resolving the relative URI to absolute form 1018 is the URI used in the HTTP message to identify the redirect reference 1019 resource to which the Ref-Target entity header or DAV:reftarget property 1020 belongs. 1022 In the case of a Ref-Target header, the base URI is constructed as 1023 follows: Its scheme component is "http", its authority component is the 1024 value of the Host header in the request, and its path component is the 1025 request-URI in the request. See Section 5 of [URI] for a discussion of 1026 relative URI references and how to resolve them. 1028 The DAV:reftarget property appears in the protocol in the context of a 1029 Multi-Status response, in a DAV:response element that contains a single 1030 DAV:href element. The value of this DAV:href element serves as the base 1031 URI for resolving a relative URI in DAV:reftarget. The value of 1032 DAV:href may itself be relative, in which case it must be resolved first 1033 in order to serve as the base URI for the relative URI in DAV:reftarget. 1034 If the DAV:href element is relative, its base URI is constructed from 1035 the scheme component "http", the value of the Host header in the 1036 request, and the request-URI. 1038 12.1 Example: Resolving a Relative URI in Ref-Target 1040 >> Request: 1042 MKREF /north/inuvik HTTP/1.1 1043 Host: www.somehost.edu 1044 Ref-Target: 1046 >> Response: 1048 HTTP/1.1 201 Created 1050 In this example, the base URI is http://www.somehost.edu/north/inuvik. 1051 Then, following the rules in [URI] Section 5, the relative URI in Ref- 1052 Target resolves to the absolute URI 1053 http://www.somehost.edu/north/mapcollection/inuvik.gif. 1055 12.2 Example: Resolving a Relative URI in DAV:reftarget 1057 >> Request: 1059 PROPFIND /geog/ HTTP/1.1 1060 Host: www.xxsvr.com 1061 Passthrough: F 1062 Depth: 1 1063 Content-Type: text/xml 1064 Content-Length: nnn 1066 1067 1068 1069 1070 1071 1072 1074 >> Response: 1076 HTTP/1.1 207 Multi-Status 1077 Content-Type: text/xml 1078 Content-Length: nnn 1080 1081 1082 1083 /geog/ 1084 1085 1086 1087 1088 HTTP/1.1 200 OK 1089 1090 1091 1092 HTTP/1.1 404 Not Found 1093 1094 1095 1096 /geog/stats.html 1097 1098 1099 1100 statistics/population/1997.html 1101 1102 1103 HTTP/1.1 200 OK 1104 1105 1106 1108 In this example, the relative URI statistics/population/1997.html is 1109 returned as the value of reftarget for the reference resource identified 1110 by href /geog/stats.html. The href is itself a relative URI, which 1111 resolves to http://www.xxsrv.com/geog/stats.html. This is the base URI 1112 for resolving the relative URI in reftarget. The absolute URI of 1113 reftarget is http://www.xxsrv.com/geog/statistics/population/1997.html. 1115 13 Redirect References to Collections 1117 In a Request-URI /segment1/segment2/segment3, any of the three segments 1118 may identify a redirect reference resource. (See [URI], Section 3.3, 1119 for definitions of "path" and "segment".) If any segment in a Request- 1120 URI identifies a redirect reference resource, the response is a 302. 1121 The value of the Location header in the 302 response is as follows: 1123 The leftmost path segment of the request-URI that identifies a redirect 1124 reference resource, together with all path segments and separators to 1125 the left of it, is replaced by the value of the redirect reference 1126 resource's DAV:reftarget property (resolved to an absolute URI). The 1127 remainder of the request-URI is concatenated to this path. 1129 Note: If the DAV:reftarget property ends with a "/" and the remainder of 1130 the Request-URI is non-empty (and therefore must begin with a "/"), the 1131 final "/" in the DAV:reftarget property is dropped before the remainder 1132 of the Request-URI is appended. 1134 Consider Request-URI /x/y/z.html. Suppose that /x/ is a redirect 1135 reference resource whose target resource is collection /a/, which 1136 contains redirect reference resource y whose target resource is 1137 collection /b/, which contains redirect reference resource z.html whose 1138 target resource is /c/d.html. 1140 /x/ -----> /a/ 1141 /a/y/ -----> /b/ 1142 /b/z.html -----> /c/d.html 1144 In this case the client must follow up three separate 302 responses 1145 before finally reaching the target resource. The server responds to the 1146 initial request with a 302 with Location: /a/y/z.html, and the client 1147 resubmits the request to /a/y/z.html. The server responds to this 1148 request with a 302 with Location: /b/z.html, and the client resubmits 1149 the request to /b/z.html. The server responds to this request with a 1150 302 with Location: /c/d.html, and the client resubmits the request to 1151 /c/d.html. This final request succeeds. 1153 14 Headers 1155 14.1 Ref-Target Entity Header 1157 Ref-Target = "Ref-Target" ":" Generic-Coded-url 1158 Generic-Coded-url = "<" (absoluteURI | relativeURI) ">" 1159 absoluteURI is defined in Section 3 of [URI]. 1160 relativeURI is defined in Section 5 of [URI]. 1162 The Ref-Target header is defined primarily for use with MKREF requests 1163 to identify the target resource of the new redirect reference resource 1164 being created. 1166 14.2 Resource-Type Entity Header 1168 Resource-Type = "Resource-Type" ":" ("DAV:redirectref" | 1169 ext-resource-type) 1170 ext-resource-type = coded-URL 1172 The Resource-Type header is defined primarily for use in 302 responses, 1173 to allow reference-aware clients to distinguish between HTTP 1.1 1174 redirects and 302 responses for redirect reference resources. The 1175 possible values of this header are DAV:redirectref, and ext-resource- 1176 type. The ext-resource-type production is provided for extensibility. 1178 14.3 Passthrough Request Header 1180 Passthrough = "Passthrough" ":" ("T" | "F") 1182 The optional Passthrough header can be used on any request to a redirect 1183 reference resource. If the Passthrough header has the value "F", the 1184 request MUST be applied to the reference resource itself, and a 302 1185 response MUST NOT be returned. If the Passthrough header has the value 1186 "T", a 302 response MUST be returned, with the URI of the target 1187 resource in the Location header and the Resource-Type header with a 1188 value "DAV:redirectref". 1190 If the Passthrough header is used on a request to any other sort of 1191 resource besides a reference resource, the server SHOULD ignore it. If 1192 the Passthrough header with the value "F" appears in a POST or 1193 ORDERPATCH request to a reference resource, the server MUST respond with 1194 a 400 (Bad Request). 1196 15 Properties 1198 15.1 reftarget Property 1200 Name: reftarget 1201 Namespace: DAV: 1202 Purpose: A property of redirect reference resources that provides an 1203 efficient way for clients to discover the URI of the target 1204 resource. This is a read-only property, whose value can 1205 only be set by using the Ref-Target header with a MKREF 1206 request. 1207 Value: href containing the URI of the target resource. This value 1208 MAY be a relative URI. The reftarget property can occur in 1209 the entity bodies of responses to PROPFIND requests. 1211 1212 15.2 location Pseudo-Property 1214 Name: location 1215 Namespace: DAV: 1216 Purpose: For use with 302 (Moved Temporarily) response codes in 1217 Multi-Status responses. It contains the absolute URI of the 1218 temporary location of the resource. In the context of 1219 redirect reference resources, this value is the absolute URI 1220 of the target resource. It is analogous to the Location 1221 header in HTTP 302 responses defined in [HTTP] Section 1222 10.3.3 "302 Moved Temporarily." Including the location 1223 pseudo-property in a Multi-Status response requires an 1224 extension to the syntax of the DAV:response element defined 1225 in [WebDAV], which is defined in Section 17 below. This 1226 pseudo-property is not expected to be stored on the 1227 reference resource. It is modeled as a property only so that 1228 it can be returned inside a DAV:prop element in a Multi- 1229 Status response. 1230 Value: href containing the absolute URI of the target resource. 1232 1234 16 XML Elements 1236 16.1 redirectref XML Element 1238 Name: redirectref 1239 Namespace: DAV: 1240 Purpose: Used as the value of the DAV:resourcetype property to 1241 specify that the resource type is a redirect reference 1242 resource. 1244 1246 17 Extensions to the DAV:response XML Element for Multi-Status Responses 1248 As described in Sections 6 and 9, the DAV:location pseudo-property and 1249 the DAV:reftype property may be returned in the DAV:response element of 1250 a 207 Multi-Status response, to allow clients to resubmit their requests 1251 to the target resource of a redirect reference resource. 1253 Whenever these properties are included in a Multi-Status response, they 1254 are placed in a DAV:prop element associated with the href to which they 1255 apply. This structure provides a framework for future extensions by 1256 other standards that may need to include additional properties in their 1257 responses. 1259 Consequently, the definition of the DAV:response XML element changes to 1260 the following: 1262 1265 18 Capability Discovery 1266 Sections 9.1 and 15 of [WebDAV] describe the use of compliance classes 1267 with the DAV header in responses to OPTIONS, to indicate which parts of 1268 the Web Distributed Authoring protocols the resource supports. This 1269 specification defines an OPTIONAL extension to [WebDAV]. It defines a 1270 new compliance class, called redirectrefs, for use with the DAV header 1271 in responses to OPTIONS requests. If a resource does support redirect 1272 references, its response to an OPTIONS request MUST indicate that it 1273 does, by listing the new MKREF method as one it supports, and by listing 1274 the new redirectrefs compliance class in the DAV header. 1276 When responding to an OPTIONS request, any type of resource can include 1277 redirectrefs in the value of the DAV header. Doing so indicates that 1278 the server permits a redirect reference resource at the request URI. 1280 18.1 Example: Discovery of Support for Redirect Reference Resources 1282 >> Request: 1284 OPTIONS /somecollection/someresource HTTP/1.1 1285 HOST: somehost.org 1287 >> Response: 1289 HTTP/1.1 200 OK 1290 Date: Tue, 20 Jan 1998 20:52:29 GMT 1291 Connection: close 1292 Accept-Ranges: none 1293 Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE, MKCOL, 1294 PROPFIND, PROPPATCH, LOCK, UNLOCK, MKREF 1295 Public: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE, MKCOL, 1296 PROPFIND, PROPPATCH, LOCK, UNLOCK, BIND, MKREF, ORDERPATCH 1297 DAV: 1, 2, redirectrefs 1299 The DAV header in the response indicates that the resource 1300 /somecollection/someresource is level 1 and level 2 compliant, as 1301 defined in [WebDAV]. In addition, /somecollection/someresource supports 1302 redirect reference resources. The Allow header indicates that MKREF 1303 requests can be submitted to /somecollection/someresource. The Public 1304 header shows that other Request-URIs on the server support additional 1305 methods. 1307 19 Security Considerations 1309 This section is provided to make WebDAV applications aware of the 1310 security implications of this protocol. 1312 All of the security considerations of HTTP/1.1 and the WebDAV 1313 Distributed Authoring Protocol specification also apply to this protocol 1314 specification. In addition, redirect reference resources introduce 1315 several new security concerns and increase the risk of some existing 1316 threats. These issues are detailed below. 1318 19.1 Privacy Concerns 1320 By creating redirect reference resources on a trusted server, it is 1321 possible for a hostile agent to induce users to send private information 1322 to a target on a different server. This risk is mitigated somewhat, 1323 since clients are required to notify the user of the redirection for any 1324 request other than GET or HEAD. (See [HTTP], Section 10.3.3 Moved 1325 Temporarily.) 1327 19.2 Redirect Loops 1329 Although redirect loops were already possible in HTTP 1.1, the 1330 introduction of the MKREF method creates a new avenue for clients to 1331 create loops accidentally or maliciously. If the reference resource and 1332 its target are on the same server, the server may be able to detect 1333 MKREF requests that would create loops. See also [HTTP], Section 10.3 1334 "Redirection 3xx." 1336 19.3 Redirect Reference Resources and Denial of Service 1338 Denial of service attacks were already possible by posting URLs that 1339 were intended for limited use at heavily used Web sites. The 1340 introduction of MKREF creates a new avenue for similar denial of service 1341 attacks. Clients can now create redirect reference resources at heavily 1342 used sites to target locations that were not designed for heavy usage. 1344 19.4 Private Locations May Be Revealed 1346 There are several ways that redirect reference resources may reveal 1347 information about directory structures. First, the DAV:reftarget 1348 property of every redirect reference resource contains the URI of the 1349 target resource. Anyone who has access to the reference resource can 1350 discover the directory path that leads to the target resource. The 1351 owner of the target resource may have wanted to limit knowledge of this 1352 directory structure. 1354 Sufficiently powerful access control mechanisms can control this risk to 1355 some extent. Property-level access control could prevent users from 1356 examining the DAV:reftarget property. (The Ref-Target and Location 1357 headers, which are returned in some responses to requests on redirect 1358 reference resources, reveal the same information, however.) In some 1359 environments, the owner of a resource might be able to use access 1360 control to prevent others from creating references to that resource. 1362 20 Internationalization Considerations 1364 This specification follows the practices of [WebDAV] in encoding all 1365 human-readable content using XML [XML] and in the treatment of names. 1366 Consequently, this specification complies with the IETF Character Set 1367 Policy [Alvestrand]. 1369 WebDAV applications MUST support the character set tagging, character 1370 set encoding, and the language tagging functionality of the XML 1371 specification. This constraint ensures that the human-readable content 1372 of this specification complies with [Alvestrand]. 1374 As in [WebDAV}, names in this specification fall into three categories: 1375 names of protocol elements such as methods and headers, names of XML 1376 elements, and names of properties. Naming of protocol elements follows 1377 the precedent of HTTP, using English names encoded in USASCII for 1378 methods and headers. The names of XML elements used in this 1379 specification are English names encoded in UTF-8. 1381 For error reporting, [WebDAV] follows the convention of HTTP/1.1 status 1382 codes, including with each status code a short, English description of 1383 the code (e.g., 423 Locked). Internationalized applications will ignore 1384 this message, and display an appropriate message in the user's language 1385 and character set. 1387 For rationales for these decisions and advice for application 1388 implementors, see [WebDAV]. 1390 21 IANA Considerations 1392 This document uses the namespaces defined by [WebDAV] for properties and 1393 XML elements. All other IANA considerations mentioned in [WebDAV] also 1394 apply to this document. 1396 22 Copyright 1398 To be supplied by the RFC Editor. 1400 23 Intellectual Property 1402 To be supplied by the RFC Editor. 1404 24 Acknowledgements 1406 This draft has benefited from thoughtful discussion by Jim Amsden, Steve 1407 Carter, Ken Coar, Ellis Cohen, Bruce Cragun, Spencer Dawkins, Mark Day, 1408 Rajiv Dulepet, David Durand, Roy Fielding, Yaron Goland, Fred Hitt, Alex 1409 Hopmann, Marcus Jager, Chris Kaler, Manoj Kasichainula, Rohit Khare, 1410 Daniel LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Surendra 1411 Koduru Reddy, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness, John 1412 Stracke, John Tigue, John Turner, and others. 1414 25 References 1416 [URI] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource 1417 Identifiers (URI): Generic Syntax." RFC 2396. MIT/LCS, U.C. Irvine, 1418 Xerox. August, 1998. 1420 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement 1421 Levels." RFC 2119, BCP 14. Harvard University. March, 1997. 1423 [XML] T. Bray, J. Paoli, C.M. Sperberg-McQueen, "Extensible Markup 1424 Language (XML)." World Wide Web Consortium Recommendation REC-xml- 1425 19980210. http://www.w3.org/TR/1998/REC-xml-19980210. 1427 [HTTP] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. 1428 Leach, T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1." RFC 1429 2616. UC Irvine, Compaq, W3C, Xerox, Microsoft. June, 1999. 1431 [WebDAV] Y. Y. Goland, E. J. Whitehead, Jr., A. Faizi, S. R. Carter, D. 1432 Jensen, "HTTP Extensions for Distributed Authoring - WebDAV." RFC 2518. 1433 Microsoft, U.C. Irvine, Netscape, Novell. February, 1999. 1435 [B] J. Slein, E.J. Whitehead Jr., J. Davis, G. Clemm, C. Fay, J. 1436 Crawford, T. Chihaya, "WebDAV Bindings." Internet Draft (work in 1437 progress) draft-ietf-webdav-binding-protocol-00. Xerox, UC Irvine, 1438 CourseNet, Rational, FileNet, IBM, DataChannel. August, 1999. 1440 [OC] J. Slein, E.J. Whitehead Jr., J. Davis, G. Clemm, C. Fay, J. 1441 Crawford, T. Chihaya, "WebDAV Ordered Collections." Internet Draft (work 1442 in progress) draft-ietf-webdav-ordering-protocol-00. Xerox, UC Irvine, 1443 CourseNet, Rational, FileNet, IBM, DataChannel. August, 1999. 1445 26 Authors' Addresses 1447 J. Slein 1448 Xerox Corporation 1449 800 Phillips Road, 105-50C 1450 Webster, NY 14580 1451 Email: jslein@crt.xerox.com 1453 E. J. Whitehead, Jr. 1454 Dept. of Information and Computer Science 1455 University of California, Irvine 1456 Irvine, CA 92697-3425 1457 Email: ejw@ics.uci.edu 1459 J. Davis 1460 CourseNet Systems 1461 170 Capp Street 1462 San Francisco, CA 94110 1463 Email: jrd3@alum.mit.edu 1465 G. Clemm 1466 Rational Software Corporation 1467 20 Maguire Road 1468 Lexington, MA 02173-3104 1469 Email: gclemm@rational.com 1471 C. Fay 1472 FileNet Corporation 1473 3565 Harbor Boulevard 1474 Costa Mesa, CA 92626-1420 1475 Email: cfay@filenet.com 1477 J. Crawford 1478 IBM 1479 Email: ccjason@us.ibm.com 1481 T. Chihaya 1482 DataChannel, Inc. 1483 155 108th Ave. N.E., Suite 400 1484 Bellevue, WA 98004 1485 Email: Tyson@DataChannel.com 1486 27 Appendices 1488 27.1 Appendix 1: Extensions to the WebDAV Document Type Definition 1490 1491 1492 1493 1494 1495 1496 1499 Expires February 20, 2000