idnits 2.17.1 draft-ietf-webdav-redirectref-protocol-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1511. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1495. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1501. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1517), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 40. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2616]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 909 has weird spacing: '...ment of a 207...' == Line 910 has weird spacing: '...equests to th...' -- 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 (April 5, 2004) is 7325 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) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2518 (Obsoleted by RFC 4918) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 WEBDAV Working Group J. Whitehead 3 Internet-Draft U.C. Santa Cruz 4 Expires: October 4, 2004 G. Clemm 5 IBM 6 J. Reschke, Ed. 7 greenbytes 8 April 5, 2004 10 Web Distributed Authoring and Versioning (WebDAV) Redirect Reference 11 Resources 12 draft-ietf-webdav-redirectref-protocol-08 14 Status of this Memo 16 By submitting this Internet-Draft, I certify that any applicable 17 patent or other IPR claims of which I am aware have been disclosed, 18 and any of which I become aware will be disclosed, in accordance with 19 RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at http:// 31 www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on October 4, 2004. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). All Rights Reserved. 42 Abstract 44 This specification defines redirect reference resources. A redirect 45 reference resource is a resource whose default response is an HTTP/ 46 1.1 3xx (Redirection) status code (see [RFC2616], Section 10.3), 47 redirecting the client to a different resource, the target resource. 48 A redirect reference makes it possible to access the target resource 49 indirectly, through any URI mapped to the redirect reference 50 resource. There are no integrity guarantees associated with redirect 51 reference resources. 53 Distribution of this document is unlimited. Please send comments to 54 the Distributed Authoring and Versioning (WebDAV) working group at 55 , which may be joined by sending a 56 message with subject "subscribe" to 57 . 59 Discussions of the WEBDAV working group are archived at URL: . 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 5 66 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4. Overview of Redirect Reference Resources . . . . . . . . . . 6 68 5. MKREDIRECTREF Method . . . . . . . . . . . . . . . . . . . . 7 69 5.1 Example: Creating a Redirect Reference Resource with 70 MKREDIRECTREF . . . . . . . . . . . . . . . . . . . . . . 8 71 6. Operations on Redirect Reference Resources . . . . . . . . . 8 72 7. Operations on Collections That Contain Redirect Reference 73 Resources . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 7.1 LOCK on a Collection That Contains Redirect References . . 9 75 7.2 Example: PROPFIND on a Collection with Redirect 76 Reference Resources . . . . . . . . . . . . . . . . . . . 10 77 7.3 Example: PROPFIND with Apply-To-Redirect-Ref on a 78 Collection with Redirect Reference Resources . . . . . . . 12 79 7.4 Example: COPY on a Collection That Contains a Redirect 80 Reference Resource . . . . . . . . . . . . . . . . . . . . 13 81 7.5 Example: LOCK on a Collection That Contains a Redirect 82 Reference Resource . . . . . . . . . . . . . . . . . . . . 14 83 8. Operations on Targets of Redirect Reference Resources . . . 16 84 9. Relative URIs in DAV:reftarget . . . . . . . . . . . . . . . 16 85 9.1 Example: Resolving a Relative URI in a Multi-Status 86 Response . . . . . . . . . . . . . . . . . . . . . . . . . 16 87 10. Redirect References to Collections . . . . . . . . . . . . . 17 88 11. Headers . . . . . . . . . . . . . . . . . . . . . . . . . . 19 89 11.1 Redirect-Ref Response Header . . . . . . . . . . . . . . 19 90 11.2 Apply-To-Redirect-Ref Request Header . . . . . . . . . . 19 91 12. Redirect Reference Resource Properties . . . . . . . . . . . 19 92 12.1 DAV:redirect-lifetime (protected) . . . . . . . . . . . 19 93 12.2 DAV:reftarget (protected) . . . . . . . . . . . . . . . 20 94 13. XML Elements . . . . . . . . . . . . . . . . . . . . . . . . 20 95 13.1 redirectref XML Element . . . . . . . . . . . . . . . . 20 96 14. Extensions to the DAV:response XML Element for 97 Multi-Status Responses . . . . . . . . . . . . . . . . . . . 20 99 15. Capability Discovery . . . . . . . . . . . . . . . . . . . . 20 100 15.1 Example: Discovery of Support for Redirect Reference 101 Resources . . . . . . . . . . . . . . . . . . . . . . . 21 102 16. Security Considerations . . . . . . . . . . . . . . . . . . 21 103 16.1 Privacy Concerns . . . . . . . . . . . . . . . . . . . . 21 104 16.2 Redirect Loops . . . . . . . . . . . . . . . . . . . . . 22 105 16.3 Redirect Reference Resources and Denial of Service . . . 22 106 16.4 Revealing Private Locations . . . . . . . . . . . . . . 22 107 17. Internationalization Considerations . . . . . . . . . . . . 22 108 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . 23 109 19. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 110 20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 111 21. Normative References . . . . . . . . . . . . . . . . . . . . 23 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 24 113 A. Changes to the WebDAV Document Type Definition . . . . . . . 24 114 B. Change Log (to be removed by RFC Editor before 115 publication) . . . . . . . . . . . . . . . . . . . . . . . . 25 116 B.1 Since draft-ietf-webdav-redirectref-protocol-02 . . . . . 25 117 B.2 Since draft-ietf-webdav-redirectref-protocol-03 . . . . . 25 118 B.3 Since draft-ietf-webdav-redirectref-protocol-04 . . . . . 25 119 B.4 Since draft-ietf-webdav-redirectref-protocol-05 . . . . . 25 120 B.5 Since draft-ietf-webdav-redirectref-protocol-06 . . . . . 25 121 B.6 Since draft-ietf-webdav-redirectref-protocol-07 . . . . . 25 122 C. Resolved issues (to be removed by RFC Editor before 123 publication) . . . . . . . . . . . . . . . . . . . . . . . . 26 124 C.1 title . . . . . . . . . . . . . . . . . . . . . . . . . . 26 125 C.2 lc-38-not-hierarchical . . . . . . . . . . . . . . . . . . 26 126 C.3 lc-37-integrity . . . . . . . . . . . . . . . . . . . . . 26 127 C.4 5_mkresource . . . . . . . . . . . . . . . . . . . . . . . 27 128 C.5 lc-41-no-webdav . . . . . . . . . . . . . . . . . . . . . 27 129 C.6 lc-24-properties . . . . . . . . . . . . . . . . . . . . . 27 130 C.7 lc-55-iana . . . . . . . . . . . . . . . . . . . . . . . . 28 131 C.8 A_DTD_cleanup . . . . . . . . . . . . . . . . . . . . . . 28 132 D. Open issues (to be removed by RFC Editor prior to 133 publication) . . . . . . . . . . . . . . . . . . . . . . . . 28 134 D.1 old_clients . . . . . . . . . . . . . . . . . . . . . . . 28 135 D.2 lc-85-301 . . . . . . . . . . . . . . . . . . . . . . . . 29 136 D.3 lc-36-server . . . . . . . . . . . . . . . . . . . . . . . 29 137 D.4 lc-33-forwarding . . . . . . . . . . . . . . . . . . . . . 29 138 D.5 3-terminology-redirectref . . . . . . . . . . . . . . . . 30 139 D.6 lc-58-update . . . . . . . . . . . . . . . . . . . . . . . 30 140 D.7 lc-48-s6 . . . . . . . . . . . . . . . . . . . . . . . . . 30 141 D.8 lc-57-noautoupdate . . . . . . . . . . . . . . . . . . . . 31 142 D.9 12.1-property-name . . . . . . . . . . . . . . . . . . . . 31 143 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 144 Intellectual Property and Copyright Statements . . . . . . . 33 146 1. Introduction 148 This is one of a pair of specifications that extend the WebDAV 149 Distributed Authoring Protocol to enable clients to create new access 150 paths to existing resources. This capability is useful for several 151 reasons: 153 The WebDAV Distributed Authoring Protocol makes it possible to 154 organize HTTP resources into hierarchies, placing them into 155 groupings, known as collections, which are more easily browsed and 156 manipulated than a single flat collection. However, hierarchies 157 require categorization decisions that locate resources at a single 158 location in the hierarchy, a drawback when a resource has multiple 159 valid categories. For example, in a hierarchy of vehicle descriptions 160 containing collections for cars and boats, a description of a 161 combination car/boat vehicle could belong in either collection. 162 Ideally, the description should be accessible from both. Allowing 163 clients to create new URIs that access the existing resource lets 164 them put that resource into multiple collections. 166 Hierarchies also make resource sharing more difficult, since 167 resources that have utility across many collections are still forced 168 into a single collection. For example, the mathematics department at 169 one university might create a collection of information on fractals 170 that contains bindings to some local resources, but also provides 171 access to some resources at other universities. For many reasons, it 172 may be undesirable to make physical copies of the shared resources on 173 the local server: to conserve disk space, to respect copyright 174 constraints, or to make any changes in the shared resources visible 175 automatically. Being able to create new access paths to existing 176 resources in other collections or even on other servers is useful for 177 this sort of case. 179 The redirect reference resources defined here provide a mechanism for 180 creating alternative access paths to existing resources. A redirect 181 reference resource is a resource in one collection whose purpose is 182 to forward requests to another resource (its target), possibly in a 183 different collection. In this way, it allows clients to submit 184 requests to the target resource from another collection. It 185 redirects most requests to the target resource using a HTTP status 186 code from the 3xx range (Redirection), thereby providing a form of 187 mediated access to the target resource. 189 A redirect reference is a resource with properties but no body of its 190 own. Properties of a redirect reference resource can contain such 191 information as who created the reference, when, and why. Since 192 redirect reference resources are implemented using HTTP 3xx 193 responses, it generally takes two round trips to submit a request to 194 the intended resource. Redirect references work equally well for 195 local resources and for resources that reside on a different server 196 from the reference. 198 The remainder of this document is structured as follows: Section 3 199 defines terms that will be used throughout the specification. 200 Section 4 provides an overview of redirect reference resources. 201 Section 5 discusses how to create a redirect reference resource. 202 Section 6 defines the semantics of existing methods when applied to 203 redirect reference resources, and Section 7 discusses their semantics 204 when applied to collections that contain redirect reference 205 resources. Sections 8 through 10 discuss several other issues raised 206 by the existence of redirect reference resources. Sections 11 207 through 14 define the new headers, properties, and XML elements 208 required to support redirect reference resources. Section 15 209 discusses capability discovery. Sections 16 through 18 present the 210 security, internationalization, and IANA concerns raised by this 211 specification. The remaining sections provide a variety of supporting 212 information. 214 2. Notational Conventions 216 Since this document describes a set of extensions to the WebDAV 217 Distributed Authoring Protocol [RFC2518], itself an extension to the 218 HTTP/1.1 protocol, the augmented BNF used here to describe protocol 219 elements is exactly the same as described in Section 2.1 of 220 [RFC2616]. Since this augmented BNF uses the basic production rules 221 provided in Section 2.2 of [RFC2616], these rules apply to this 222 document as well. 224 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 225 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 226 document are to be interpreted as described in [RFC2119]. 228 3. Terminology 230 The terminology used here follows and extends that in the WebDAV 231 Distributed Authoring Protocol specification [RFC2518]. Definitions 232 of the terms resource, Uniform Resource Identifier (URI), and Uniform 233 Resource Locator (URL) are provided in [RFC2396]. 235 Redirect Reference Resource 237 A resource created to redirect all requests made to it, using an 238 HTTP status code from the 3xx range, to a defined target resource. 240 Non-Reference Resource 241 A resource that is not a reference to another resource. 243 Target Resource 245 The resource to which requests are forwarded by a reference 246 resource. A target resource can be anything that can be identified 247 by an absolute URI (see [RFC2396], "absoluteURI"). 249 This document uses the terms "precondition", "postcondition" and 250 "protected property" as defined in [RFC3253]. Servers MUST report 251 pre-/postcondition failures as described in section 1.6 of this 252 document. 254 4. Overview of Redirect Reference Resources 256 For all operations submitted to a redirect reference resource, the 257 default response is a 302 (Found), accompanied by the Redirect-Ref 258 header (defined in Section 11.1 below) and the Location header set to 259 the URI of the target resource. With this information, the client 260 can resubmit the request to the URI of the target resource. 262 A redirect reference resource never automatically forwards requests 263 to its target resource. Redirect resources bring the same benefits as 264 links in HTML documents. They can be created and maintained without 265 the involvement or even knowledge of their target resource. This 266 reduces the cost of linking between resources." 268 If the client is aware that it is operating on a redirect reference 269 resource, it can resolve the reference by retrieving the reference 270 resource's DAV:reftarget property (defined in Section 12.2 below), 271 whose value contains the URI of the target resource. It can then 272 submit requests to the target resource. 274 A redirect reference resource is a new type of resource. To 275 distinguish redirect reference resources from non-reference 276 resources, a new value of the DAV:resourcetype property (defined in 277 [RFC2518]), DAV:redirectref, is defined in Section 13.1 below. 279 Since a redirect reference resource is a resource, methods can be 280 applied to the reference resource as well as to its target resource. 281 The Apply-To-Redirect-Ref request header (defined in Section 11.2 282 below) is provided so that referencing-aware clients can control 283 whether an operation is applied to the redirect reference resource or 284 standard HTTP/WebDAV behaviour (redirection with a 3xx status code) 285 should occur. The Apply-To-Redirect-Ref header can be used with most 286 requests to redirect reference resources. This header is 287 particularly useful with PROPFIND, to retrieve the reference 288 resource's own properties. 290 5. MKREDIRECTREF Method 292 The MKREDIRECTREF method requests the creation of a redirect 293 reference resource. 295 If a MKREDIRECTREF request fails, the server state preceding the 296 request MUST be restored. 298 Responses from a MKREDIRECTREF request MUST NOT be cached, as 299 MKREDIRECTREF has non-idempotent semantics. 301 Marshalling: 303 The request body MUST be a DAV:mkredirectref XML element. 305 306 307 308 309 311 The DAV:href element is defined in [RFC2518] (Section 12.3) and 312 MUST contain either an absoluteURI or a relativeURI (see 313 [RFC2396], Section 3 and 5). 315 If the request succeeds, the server MUST return 201 (Created) 316 status. 318 If a response body for a successful request is included, it MUST 319 be a DAV:mkredirectref-response XML element. Note that this 320 document does not define any elements for the MKREDIRECTREF 321 response body, but the DAV:mkredirectref-response element is 322 defined to ensure interoperability between future extensions that 323 do define elements for the MKREDIRECTREF response body. 325 327 Preconditions: 329 (DAV:resource-must-be-null): A resource MUST NOT exist at the 330 request-URL. 332 (DAV:parent-resource-must-be-non-null): The request-URL minus the 333 last past segment MUST identify a collection. 335 (DAV:name-allowed): The last segment of the request URL is 336 available for use as a resource name. 338 (DAV:locked-update-allowed): If the collection identified by the 339 Request-URL minus the last path segment is write-locked, then the 340 appropriate token MUST be specified in an If request header. 342 (DAV:redirect-lifetime-supported): If the request body contains a 343 DAV:redirect-lifetime element, the server MUST support the 344 specified liftime. Support for DAV:temporary is REQUIRED, while 345 support for DAV:permanent is OPTIONAL. 347 Postconditions: 349 (DAV:new-redirectref): a new redirect reference resource is 350 created whose DAV:reftarget property has the value specified in 351 the request body. 353 5.1 Example: Creating a Redirect Reference Resource with MKREDIRECTREF 355 >> Request: 357 MKREDIRECTREF /~whitehead/dav/spec08.ref HTTP/1.1 358 Host: www.example.com 359 Content-Type: text/xml; charset="utf-8" 360 Content-Length: xxx 362 363 364 365 /i-d/draft-webdav-protocol-08.txt 366 367 369 >> Response: 371 HTTP/1.1 201 Created 373 This request resulted in the creation of a new redirect reference 374 resource at http://www.example.com/~whitehead/dav/spec08.ref, which 375 points to the resource identified by the DAV:reftarget property. In 376 this example, the target resource is identified by the URI http:// 377 www.example.com/i-d/draft-webdav-protocol-08.txt. The redirect 378 reference resource's DAV:resourcetype property is set to 379 DAV:redirectref. 381 6. Operations on Redirect Reference Resources 383 Although non-referencing-aware clients cannot create reference 384 resources, they should be able to submit requests through the 385 reference resources created by reference-aware WebDAV clients. They 386 should be able to follow any references to their targets. To make 387 this possible, a server that receives any request made via a redirect 388 reference resource MUST return a 3xx range (Redirection) status code, 389 unless the request includes an Apply-To-Redirect-Ref header 390 specifying "T". The client and server MUST follow [RFC2616] Section 391 10.3, but with these additional rules: 393 o The Location response header MUST contain an absolute URI that 394 identifies the target of the reference resource. 396 o The response MUST include the Redirect-Ref header. This header 397 allows reference-aware WebDAV clients to recognize the resource as 398 a reference resource and understand the reason for the 399 redirection. 401 A reference-aware WebDAV client can, like a non-referencing client, 402 resubmit the request to the URI in the Location header in order to 403 operate on the target resource. Alternatively, it can resubmit the 404 request to the URI of the redirect reference resource with the 405 "Apply-To-Redirect-Ref: T" header in order to operate on the 406 reference resource itself. In this case, the request MUST be applied 407 to the reference resource itself, and a 3xx response MUST NOT be 408 returned. 410 As redirect references do not have bodies, GET and PUT requests with 411 "Apply-To-Redirect-Ref: T" MUST fail with status 403 (forbidden). 413 7. Operations on Collections That Contain Redirect Reference Resources 415 Consistent with the rules in Section 6, the response for each 416 redirect reference encountered while processing a collection MUST be 417 a 3xx (Redirection) unless a "Apply-To-Redirect-Ref: T" header is 418 included with the request. The overall response will therefore be a 419 207 (Multi-Status). For each DAV:response element representing a 420 redirect reference, the server MUST include an additional 421 DAV:location element, specifying the value of the "Location" header 422 that would be returned otherwise. The extension is defined in Section 423 14 below. 425 The Apply-To-Redirect-Ref header (defined in Section 11.2) MAY be 426 used with any request on a collection. If present, it will be 427 applied to all redirect reference resources encountered while 428 processing the collection. 430 7.1 LOCK on a Collection That Contains Redirect References 432 An attempt to lock (with Depth: infinity) a collection that contains 433 redirect references without specifying "Apply-To-Redirect-Ref: T" 434 will always fail. The Multi-Status response will contain a 3xx 435 response for each redirect reference. 437 Reference-aware clients can lock the collection by using 438 Apply-To-Redirect-Ref, and, if desired, lock the targets of the 439 redirect references individually. 441 Non-referencing clients must resort to locking each resource 442 individually. 444 7.2 Example: PROPFIND on a Collection with Redirect Reference Resources 446 Suppose a PROPFIND request with Depth: infinity is submitted to the 447 following collection, with the members shown here: 449 /MyCollection/ 450 (non-reference resource) diary.html 451 (redirect reference resource) nunavut 453 >> Request: 455 PROPFIND /MyCollection/ HTTP/1.1 456 Host: example.com 457 Depth: infinity 458 Apply-To-Redirect-Ref: F 459 Content-Type: text/xml 460 Content-Length: xxxx 462 463 464 465 466 467 468 469 >> Response: 471 HTTP/1.1 207 Multi-Status 472 Content-Type: text/xml 473 Content-Length: xxxx 475 476 477 478 /MyCollection/ 479 480 481 482 diary, interests, hobbies 483 484 HTTP/1.1 200 OK 485 486 487 488 /MyCollection/diary.html 489 490 491 492 diary, travel, family, history 493 494 HTTP/1.1 200 OK 495 496 497 498 /MyCollection/nunavut 499 HTTP/1.1 302 Found 500 501 http://example.ca/art/inuit/ 502 503 504 506 In this example the Depth header is set to infinity, and the 507 Apply-To-Redirect-Ref header is set to "F". The collection contains 508 one URI that identifies a redirect reference resource. The response 509 element for the redirect reference resource has a status of 302 510 (Found), and includes a DAV:location extension element to allow 511 clients to retrieve the properties of its target resource. (The 512 response element for the redirect reference resource does not include 513 the requested properties. The client can submit another PROPFIND 514 request to the URI in the DAV:location pseudo-property to retrieve 515 those properties.) 517 7.3 Example: PROPFIND with Apply-To-Redirect-Ref on a Collection with 518 Redirect Reference Resources 520 Suppose a PROPFIND request with "Apply-To-Redirect-Ref: T" and Depth: 521 infinity is submitted to the following collection, with the members 522 shown here: 524 /MyCollection/ 525 (non-reference resource) diary.html 526 (redirect reference resource) nunavut 528 >> Request: 530 PROPFIND /MyCollection/ HTTP/1.1 531 Host: example.com 532 Depth: infinity 533 Apply-To-Redirect-Ref: T 534 Content-Type: text/xml 535 Content-Length: xxxx 537 538 539 540 541 542 543 545 >> Response: 547 HTTP/1.1 207 Multi-Status 548 Content-Type: text/xml 549 Content-Length: xxxx 551 552 553 554 /MyCollection/ 555 556 557 558 559 HTTP/1.1 200 OK 560 561 562 563 HTTP/1.1 404 Not Found 564 566 567 568 /MyCollection/diary.html 569 570 571 572 573 HTTP/1.1 200 OK 574 575 576 577 HTTP/1.1 404 Not Found 578 579 580 581 /MyCollection/nunavut 582 583 584 585 586 http://example.ca/art/inuit/ 587 588 589 HTTP/1.1 200 OK 590 591 592 594 Since the "Apply-To-Redirect-Ref: T" header is present, the response 595 shows the properties of the redirect reference resource in the 596 collection rather than reporting a 302 status. 598 7.4 Example: COPY on a Collection That Contains a Redirect Reference 599 Resource 601 Suppose a COPY request is submitted to the following collection, with 602 the members shown: 604 /MyCollection/ 605 (non-reference resource) diary.html 606 (redirect reference resource) nunavut with target 607 /Someplace/nunavut.map 609 >> Request: 611 COPY /MyCollection/ HTTP/1.1 612 Host: example.com 613 Depth: infinity 614 Destination: http://example.com/OtherCollection/ 616 >> Response: 618 HTTP/1.1 207 Multi-Status 619 Content-Type: text/xml; charset="utf-8" 620 Content-Length: xxx 622 623 624 625 /MyCollection/nunavut 626 HTTP/1.1 302 Found 627 628 http://example.com//Someplace/nunavut.map 629 630 631 633 In this case, since /MyCollection/nunavut is a redirect reference 634 resource, the COPY operation was only a partial success. The 635 redirect reference resource was not copied, but a 302 response was 636 returned for it. So the resulting collection is as follows: 638 /OtherCollection/ 639 (non-reference resource) diary.html 641 7.5 Example: LOCK on a Collection That Contains a Redirect Reference 642 Resource 644 Suppose a LOCK request is submitted to the following collection, with 645 the members shown: 647 /MyCollection/ 648 (non-reference resource) diary.html 649 (redirect reference resource) nunavut 651 >> Request: 653 LOCK /MyCollection/ HTTP/1.1 654 Host: example.com 655 Apply-To-Redirect-Ref: F 656 Content-Type: text/xml 658 659 660 661 662 664 >> Response: 666 HTTP/1.1 207 Multi-Status 667 Content-Type: text/xml 668 Content-Length: nnnn 670 671 672 673 /MyCollection/ 674 HTTP/1.1 424 Failed Dependency 675 676 677 /MyCollection/diary.html 678 HTTP/1.1 424 Failed Dependency 679 680 681 /MyCollection/nunavut 682 HTTP/1.1 302 Found 683 684 http://example.ca/art/inuit/ 685 686 687 689 The server returns a 302 response code for the redirect reference 690 resource in the collection. Consequently, neither the collection nor 691 any of the resources identified by its internal member URIs were 692 locked. A referencing-aware client can submit a separate LOCK request 693 to the URI in the DAV:location element returned for the redirect 694 reference resource, and can resubmit the LOCK request with the 695 Apply-To-Redirect-Ref header to the collection. At that point both 696 the reference resource and its target resource will be locked (as 697 well as the collection and all the resources identified by its other 698 members). 700 8. Operations on Targets of Redirect Reference Resources 702 Operations on targets of redirect reference resources have no effect 703 on the reference resource. 705 9. Relative URIs in DAV:reftarget 707 The URI in the href in a DAV:reftarget property MAY be a relative 708 URI. In this case, the base URI to be used for resolving the relative 709 URI to absolute form is the URI used in the HTTP message to identify 710 the redirect reference resource to which the DAV:reftarget property 711 belongs. 713 When DAV:reftarget appears in the context of a Multi-Status response, 714 it is in a DAV:response element that contains a single DAV:href 715 element. The value of this DAV:href element serves as the base URI 716 for resolving a relative URI in DAV:reftarget. The value of DAV:href 717 may itself be relative, in which case it must be resolved first in 718 order to serve as the base URI for the relative URI in DAV:reftarget. 719 If the DAV:href element is relative, its base URI is constructed from 720 the scheme component "http", the value of the Host header in the 721 request, and the request-URI. 723 9.1 Example: Resolving a Relative URI in a Multi-Status Response 725 >> Request: 727 PROPFIND /geog/ HTTP/1.1 728 Host: example.com 729 Apply-To-Redirect-Ref: T 730 Depth: 1 731 Content-Type: text/xml 732 Content-Length: nnn 734 735 736 737 738 739 740 741 >> Response: 743 HTTP/1.1 207 Multi-Status 744 Content-Type: text/xml 745 Content-Length: nnn 747 748 749 750 /geog/ 751 752 753 754 755 HTTP/1.1 200 OK 756 757 758 759 HTTP/1.1 404 Not Found 760 761 762 763 /geog/stats.html 764 765 766 767 768 statistics/population/1997.html 769 770 771 HTTP/1.1 200 OK 772 773 774 776 In this example, the relative URI statistics/population/1997.html is 777 returned as the value of reftarget for the reference resource 778 identified by href /geog/stats.html. The href is itself a relative 779 URI, which resolves to http://example.com/geog/stats.html. This is 780 the base URI for resolving the relative URI in reftarget. The 781 absolute URI of reftarget is http://example.com/geog/statistics/ 782 population/1997.html. 784 10. Redirect References to Collections 786 In a Request-URI /segment1/segment2/segment3, any of the three 787 segments may identify a redirect reference resource. (See [RFC2396], 788 Section 3.3, for definitions of "path" and "segment".) If any 789 segment in a Request-URI identifies a redirect reference resource, 790 the response SHOULD be a 3xx. The value of the Location header in the 791 response is as follows: 793 The leftmost path segment of the request-URI that identifies a 794 redirect reference resource, together with all path segments and 795 separators to the left of it, is replaced by the value of the 796 redirect reference resource's DAV:reftarget property (resolved to an 797 absolute URI). The remainder of the request-URI is concatenated to 798 this path. 800 Note: If the DAV:reftarget property ends with a "/" and the remainder 801 of the Request-URI is non-empty (and therefore must begin with a "/ 802 "), the final "/" in the DAV:reftarget property is dropped before the 803 remainder of the Request-URI is appended. 805 Consider Request-URI /x/y/z.html. Suppose that /x/ is a redirect 806 reference resource whose target resource is collection /a/, which 807 contains redirect reference resource y whose target resource is 808 collection /b/, which contains redirect reference resource z.html 809 whose target resource is /c/d.html. 811 /x/y/z.html 812 | 813 | /x -> /a 814 | 815 v 816 /a/y/z.html 817 | 818 | /a/y -> /b 819 | 820 v 821 /b/z.html 822 | 823 | /b/z.html -> /c/d.html 824 | 825 v 826 /c/d.html 828 In this case the client must follow up three separate 3xx responses 829 before finally reaching the target resource. The server responds to 830 the initial request with a 3xx with Location: /a/y/z.html, and the 831 client resubmits the request to /a/y/z.html. The server responds to 832 this request with a 3xx with Location: /b/z.html, and the client 833 resubmits the request to /b/z.html. The server responds to this 834 request with a 3xx with Location: /c/d.html, and the client resubmits 835 the request to /c/d.html. This final request succeeds. 837 Note: the behavior described above may have a very serious impact 838 on the efficiency of mapping Request-URIs to resources in HTTP 839 request processing. Therefore servers MAY respond with a 404 840 status code if the cost of checking all leading path segments for 841 redirect references seems prohibitive. 843 11. Headers 845 11.1 Redirect-Ref Response Header 847 Redirect-Ref = "Redirect-Ref:" (absoluteURI | relativeURI) 848 ; see sections 3 and 5 of [RFC2396] 850 The Redirect-Ref header is used in all 3xx responses from redirect 851 reference resources. The value is the (possibly relative) URI of the 852 link target as specified during redirect reference resource creation. 854 11.2 Apply-To-Redirect-Ref Request Header 856 Apply-To-Redirect-Ref = "Apply-To-Redirect-Ref" ":" ("T" | "F") 858 The optional Apply-To-Redirect-Ref header can be used on any request 859 to a redirect reference resource. When it is present and set to "T", 860 the request MUST be applied to the reference resource itself, and a 861 3xx response MUST NOT be returned. 863 If the Apply-To-Redirect-Ref header is used on a request to any other 864 sort of resource besides a redirect reference resource, the server 865 MUST ignore it. 867 12. Redirect Reference Resource Properties 869 The properties defined below are REQUIRED on redirect reference 870 resources. 872 12.1 DAV:redirect-lifetime (protected) 874 This property provides information about the lifetime of a redirect. 875 It can either be DAV:permanent (HTTP status 301) or DAV:temporary 876 (HTTP status 302). Future protocols MAY define additional values. 878 879 880 882 12.2 DAV:reftarget (protected) 884 This property provides an efficient way for clients to discover the 885 URI of the target resource. This is a read-only property after its 886 initial creation. Its value can only be set in a MKREDIRECTREF 887 request. The value is a DAV:href element containing the URI of the 888 target resource. 890 892 13. XML Elements 894 13.1 redirectref XML Element 896 Name: redirectref 898 Namespace: DAV: 900 Purpose: Used as the value of the DAV:resourcetype property to 901 specify that the resource type is a redirect reference resource. 903 905 14. Extensions to the DAV:response XML Element for Multi-Status 906 Responses 908 As described in Section 7, the DAV:location element may be returned 909 in the DAV:response element of a 207 Multi-Status response, to allow 910 clients to resubmit their requests to the target resource of a 911 redirect reference resource. 913 Consequently, the definition of the DAV:response XML element changes 914 to the following: 916 918 920 15. Capability Discovery 922 Sections 9.1 and 15 of [RFC2518] describe the use of compliance 923 classes with the DAV header in responses to OPTIONS, to indicate 924 which parts of the WebDAV Distributed Authoring protocols the 925 resource supports. This specification defines an OPTIONAL extension 926 to [RFC2518]. It defines a new compliance class, called 927 redirectrefs, for use with the DAV header in responses to OPTIONS 928 requests. If a resource does support redirect references, its 929 response to an OPTIONS request may indicate that it does, by listing 930 the new redirectrefs compliance class in the DAV header and by 931 listing the MKREDIRECTREF method as one it supports. 933 When responding to an OPTIONS request, any type of resource can 934 include redirectrefs in the value of the DAV header. Doing so 935 indicates that the server permits a redirect reference resource at 936 the request URI. 938 15.1 Example: Discovery of Support for Redirect Reference Resources 940 >> Request: 942 OPTIONS /somecollection/someresource HTTP/1.1 943 Host: example.org 945 >> Response: 947 HTTP/1.1 200 OK 948 Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE 949 Allow: MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, MKREDIRECTREF 950 DAV: 1, 2, redirectrefs 952 The DAV header in the response indicates that the resource / 953 somecollection/someresource is level 1 and level 2 compliant, as 954 defined in [RFC2518]. In addition, /somecollection/someresource 955 supports redirect reference resources. The Allow header indicates 956 that MKREDIRECTREF requests can be submitted to /somecollection/ 957 someresource. 959 16. Security Considerations 961 This section is provided to make applications that implement this 962 protocol aware of the security implications of this protocol. 964 All of the security considerations of HTTP/1.1 and the WebDAV 965 Distributed Authoring Protocol specification also apply to this 966 protocol specification. In addition, redirect reference resources 967 introduce several new security concerns and increase the risk of some 968 existing threats. These issues are detailed below. 970 16.1 Privacy Concerns 972 By creating redirect reference resources on a trusted server, it is 973 possible for a hostile agent to induce users to send private 974 information to a target on a different server. This risk is 975 mitigated somewhat, since clients are required to notify the user of 976 the redirection for any request other than GET or HEAD. (See 977 [RFC2616], Section 10.3.3 302 Found.) 979 16.2 Redirect Loops 981 Although redirect loops were already possible in HTTP 1.1, the 982 introduction of the MKREDIRECTREF method creates a new avenue for 983 clients to create loops accidentally or maliciously. If the 984 reference resource and its target are on the same server, the server 985 may be able to detect MKREDIRECTREF requests that would create loops. 986 See also [RFC2616], Section 10.3 "Redirection 3xx." 988 16.3 Redirect Reference Resources and Denial of Service 990 Denial of service attacks were already possible by posting URLs that 991 were intended for limited use at heavily used Web sites. The 992 introduction of MKREDIRECTREF creates a new avenue for similar denial 993 of service attacks. Clients can now create redirect reference 994 resources at heavily used sites to target locations that were not 995 designed for heavy usage. 997 16.4 Revealing Private Locations 999 There are several ways that redirect reference resources may reveal 1000 information about collection structures. First, the DAV:reftarget 1001 property of every redirect reference resource contains the URI of the 1002 target resource. Anyone who has access to the reference resource can 1003 discover the collection path that leads to the target resource. The 1004 owner of the target resource may have wanted to limit knowledge of 1005 this collection structure. 1007 Sufficiently powerful access control mechanisms can control this risk 1008 to some extent. Property-level access control could prevent users 1009 from examining the DAV:reftarget property. (The Location header 1010 returned in responses to requests on redirect reference resources 1011 reveals the same information, however.) 1013 This risk is no greater than the similar risk posed by HTML links. 1015 17. Internationalization Considerations 1017 All internationalization considerations mentioned in [RFC2518] also 1018 apply to this document. 1020 18. IANA Considerations 1022 All IANA considerations mentioned in [RFC2518] also apply to this 1023 document. 1025 19. Contributors 1027 Many thanks to Jason Crawford, Jim Davis, Chuck Fay and Judith Slein 1028 who can take credit for big parts of the original design of this 1029 specification. 1031 20. Acknowledgements 1033 This document has benefited from thoughtful discussion by Jim Amsden, 1034 Peter Carlson, Steve Carter, Tyson Chihaya, Ken Coar, Ellis Cohen, 1035 Bruce Cragun, Spencer Dawkins, Mark Day, Rajiv Dulepet, David Durand, 1036 Lisa Dusseault, Stefan Eissing, Roy Fielding, Yaron Goland, Fred 1037 Hitt, Alex Hopmann, James Hunt, Marcus Jager, Chris Kaler, Manoj 1038 Kasichainula, Rohit Khare, Daniel LaLiberte, Steve Martin, Larry 1039 Masinter, Jeff McAffer, Joe Orton, Surendra Koduru Reddy, Juergen 1040 Reuter, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness, John 1041 Stracke, John Tigue, John Turner, Kevin Wiggen, and others. 1043 21 Normative References 1045 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1046 Requirement Levels", BCP 14, RFC 2119, March 1997. 1048 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 1049 Resource Identifiers (URI): Generic Syntax", RFC 2396, 1050 August 1998. 1052 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. 1053 Jensen, "HTTP Extensions for Distributed Authoring -- 1054 WEBDAV", RFC 2518, February 1999. 1056 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1057 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext 1058 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1060 [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C. and J. 1061 Whitehead, "Versioning Extensions to WebDAV (Web 1062 Distributed Authoring and Versioning)", RFC 3253, March 1063 2002. 1065 Authors' Addresses 1067 Jim Whitehead 1068 UC Santa Cruz, Dept. of Computer Science 1069 1156 High Street 1070 Santa Cruz, CA 95064 1071 US 1073 EMail: ejw@cse.ucsc.edu 1075 Geoff Clemm 1076 IBM 1077 20 Maguire Road 1078 Lexington, MA 02421 1079 US 1081 EMail: geoffrey.clemm@us.ibm.com 1083 Julian F. Reschke (editor) 1084 greenbytes GmbH 1085 Salzmannstrasse 152 1086 Muenster, NW 48159 1087 Germany 1089 Phone: +49 251 2807760 1090 Fax: +49 251 2807761 1091 EMail: julian.reschke@greenbytes.de 1092 URI: http://greenbytes.de/tech/webdav/ 1094 Appendix A. Changes to the WebDAV Document Type Definition 1096 1098 1099 1101 1103 1105 1107 1109 1111 Appendix B. Change Log (to be removed by RFC Editor before publication) 1113 B.1 Since draft-ietf-webdav-redirectref-protocol-02 1115 Julian Reschke takes editorial role (added to authors list). Cleanup 1116 XML indentation. Start adding all unresolved last call issues. Update 1117 some author's contact information. Update references, split into 1118 "normative" and "informational". Remove non-RFC2616 headers 1119 ("Public") from examples. Fixed width problems in artwork. Start 1120 resolving editorial issues. 1122 B.2 Since draft-ietf-webdav-redirectref-protocol-03 1124 Added Joe Orton and Juergen Reuter to Acknowledgements section. Close 1125 more editorial issues. Remove dependencies on BIND spec. 1127 B.3 Since draft-ietf-webdav-redirectref-protocol-04 1129 More editorial fixes. Clarify that MKRESOURCE can only be used to 1130 create redirect references (switch to new method in a future draft). 1131 Clarify that redirect references do not have bodies. 1133 B.4 Since draft-ietf-webdav-redirectref-protocol-05 1135 Close (accept) issue "lc-79-accesscontrol". Add issue 1136 "rfc2606-compliance". Close issues "lc-50-blindredirect", 1137 "lc-71-relative", "lc-74-terminology". Update contact info for Geoff 1138 Clemm. Moved some of the original authors names to new Contributors 1139 section. Add and close issue "9-MKRESOURCE-vs-relative-URI". Close 1140 issue "lc-72-trailingslash". Close issue "lc-60-ex". Update issue 1141 "lc-85-301" with proposal. Close issue "lc-06-reftarget-relative" 1142 (9-MKRESOURCE-vs-relative-URI was a duplicate of this one). Also 1143 remove section 9.1 (example for MKRESOURCE vs relative URIs). Add 1144 and resolve issue "11.2-apply-to-redirect-ref-syntax" (header now has 1145 values "T" and "F"). Also some cleanup for "rfc2606-compliance". 1146 Typo fixes. Add and resolve "15.1-options-response". 1148 B.5 Since draft-ietf-webdav-redirectref-protocol-06 1150 Resolve issues "lc-19-direct-ref", "lc-28-lang", "lc-29-lang", 1151 "lc-44-pseudo", "lc-53-s10", "lc-61-pseudo", "lc-63-move", 1152 "lc-80-i18n" and "rfc2606-compliance". Start work on index. Add new 1153 issue "old_clients". 1155 B.6 Since draft-ietf-webdav-redirectref-protocol-07 1157 Closed issue "lc-38-not-hierarchical". Cleaned up DTD fragments in 1158 appendix. Close (reject) issues "lc-55-iana" and "lc-41-no-webdav". 1160 Add issue "5_mkresource" and start work on MKREDIRECTREF (issue 1161 closed, but more work on MKREDIRECTREF needs to be done for updates 1162 and status codes other than 302). Start resolution of "lc-85-301", 1163 replacing "302" by more generic language. Update issue 1164 "lc-57-noautoupdate". Close issue "lc-37-integrity" (duplicate of 1165 "lc-57-autoupdate"). Started work on "lc-85-301". Add L. Dusseault 1166 and S. Eissing to Acknowledgments section. 1168 Appendix C. Resolved issues (to be removed by RFC Editor before 1169 publication) 1171 Issues that were either rejected or resolved in this version of this 1172 document. 1174 C.1 title 1176 Type: edit 1178 julian.reschke@greenbytes.de (2004-01-04): Expand "WebDAV" in 1179 document title. 1181 Resolution: Done (no change tracking). 1183 C.2 lc-38-not-hierarchical 1185 Type: change 1187 1190 yarong@Exchange.Microsoft.com (2000-02-11): Not Hierarchical: The 1191 first sentence of the second paragraph of the introduction of the 1192 redirect spec asserts that the URIs of WebDAV compliant resources 1193 match to collections. The WebDAV standard makes no such requirement. 1194 I therefore move that this sentence be stricken. 1196 Resolution (2003-11-19): State the more general HTTP rationale first 1197 (alternative names for the same resource), then introduce the 1198 collection hierarchy rationale, which applies only if you are in a 1199 WebDAV-compliant space. 1201 C.3 lc-37-integrity 1203 Type: change 1205 1207 yarong@Exchange.Microsoft.com (2000-02-11): Integrity: Intro, para 7 1208 "Servers are not required to enforce the integrity of redirect 1209 references." Integrity is not defined. Replace with something 1210 clearer. 1212 Resolution (2004-01-19): Remove that sentence. Issue will be resolved 1213 as part of the resolution of "lc-57-noautoupdate". 1215 C.4 5_mkresource 1217 Type: change 1219 julian.reschke@greenbytes.de (2004-01-04): Umbrella issue for all 1220 changes caused by replacing the generic MKRESOURCE method by 1221 MKREDIRECTREF. 1223 C.5 lc-41-no-webdav 1225 Type: change 1227 1230 yarong@Exchange.Microsoft.com (2000-02-11): Make redirect references 1231 independent of the rest of WebDAV. The creation method for redirect 1232 references shouldn't require an XML request body. 1234 Resolution (2004-01-04): MKRESOURCE will be replaced by a specific 1235 method that doesn't rely on any PROPPATCH semantics, however it will 1236 still use XML (see also BIND spec for similar marshalling). 1238 C.6 lc-24-properties 1240 Type: change 1242 1245 reuterj@ira.uka.de (2000-02-07): Section 5.1: Replace the sentence 1246 "The properties of the new resource are as specified by the 1247 DAV:propertyupdate request body, using PROPPATCH semantics" with the 1248 following: "The MKRESOURCE request MAY contain a DAV:propertyupdate 1249 request body to initialize resource properties. Herein, the semantics 1250 is the same as when sending a MKRESOURCE request without a request 1251 body, followed by a PROPPATCH with the DAV:propertyupdate request 1252 body." 1254 Resolution (2004-01-04): MKRESOURCE will be replaced by simpler/more 1255 specific method. 1257 C.7 lc-55-iana 1259 Type: change 1261 1264 yarong@Exchange.Microsoft.com (2000-02-11): Expand the IANA section 1265 to list all methods, headers, XML elements, MIME types, URL schemes, 1266 etc., defined by the spec. 1268 Resolution (2004-01-02): Rejected: this section is about registering 1269 new spaces of identifiers. See RFC2434. 1271 C.8 A_DTD_cleanup 1273 Type: change 1275 julian.reschke@greenbytes.de (2003-11-18): Cleanup DTD. 1277 Appendix D. Open issues (to be removed by RFC Editor prior to 1278 publication) 1280 D.1 old_clients 1282 Type: change 1284 1287 julian.reschke@greenbytes.de (2003-11-10): There are (at least) two 1288 major design goals, but unfortunately both are in direct 1289 contradiction: #1: Maximum consistency with HTTP/1.1 (RFC2616). This 1290 means that any request that addresses a redirect reference resource 1291 MUST result in a 3xx status code (obviously the whole point is that 1292 GET MUST result in a redirection, and if it does, it's hard to say 1293 why other methods such as PUT or DELETE should behave differently). 1294 Therefore, the redirect reference protocol introduces a new request 1295 header ("Apply-To-Redirect-Ref") through which a client can indicate 1296 that the request indeed should be applied to the redirect reference 1297 resource itself. #2: Maximum usability with existing clients. For 1298 instance, the Microsoft Webfolder client will not be able to DELETE a 1299 redirect reference resource unless the server deviates from #1. Right 1300 now I'm not sure about the best way to resolve this. Currently the 1301 spec chooses #1 (back when this decision was made, there was probably 1302 the assumption that existing clients would quickly be updated -- 1303 something that probably isn't true today). However this may result in 1304 implementers either just ignoring these rules, or adding special 1305 workarounds based on "User Agent" detection. 1307 D.2 lc-85-301 1309 Type: change 1311 ejw@cse.ucsc.edu (2000-01-03): Support creation of other than 302 1312 redirects, especially 301. 1314 julian.reschke@greenbytes.de (2003-10-13): HTTP seems to distinguish 1315 the following use cases: (a) permanent redirect (301), (b) temporary 1316 redirect (302 or 307), (c) redirect to a GET location after POST 1317 (303) and (d) agent-driven negotiation (300). Among these, (a) and 1318 (b) seem to be well understood, so we should support both. (c) 1319 doesn't seem to be applicable. (d) may become interesting when user 1320 agents start supporting it, so the spec should be flexible enough to 1321 support a feature extension for that. For now I propose that the 1322 client is able to specify the redirection type as a resource type, 1323 such as "DAV:permanent-redirect-reference" and 1324 "DAV:temporary-redirect-reference". This spec would only define the 1325 behaviour for these two resource types and would allow future 1326 extensions using new resource types and suggested response codes. 1328 Resolution (2004-01-19): Support creation of both permanent (301, 1329 optional) and temporary (302, required) redirects. Keep protocol 1330 extensible for other types. Make lifetime visible as protected 1331 property. 1333 D.3 lc-36-server 1335 Type: change 1337 1340 yarong@Exchange.Microsoft.com (2000-02-11): Servers: Replace "server" 1341 with "unrelated system" throughout. 1343 Resolution: Try replacing "server" with "host" in some contexts, 1344 rephrasing in passive voice in others. See also issue 40. 1346 D.4 lc-33-forwarding 1348 Type: change 1350 1353 yarong@Exchange.Microsoft.com (2000-02-11): Forwarding: Replace 1354 "forward" with "redirect" throughout. 1356 Resolution: Use "redirect" for the behavior redirect resources do 1357 exhibit. Use "forward" for the contrasting behavior (passing a method 1358 on to the target with no client action needed). Define these two 1359 terms. See also issue 40. 1361 D.5 3-terminology-redirectref 1363 Type: change 1365 1368 julian.reschke@greenbytes.de (2003-07-27): Consider global rename of 1369 "redirect reference resource" to "redirect resource". 1371 D.6 lc-58-update 1373 Type: change 1375 1378 yarong@Exchange.Microsoft.com (2000-02-11): There needs to be a way 1379 to update the target of a redirect reference. 1381 Resolution: Agreed. See also issues 6, 43. 1383 D.7 lc-48-s6 1385 Type: change 1387 1390 yarong@Exchange.Microsoft.com (2000-02-11): Replace all of section 6 1391 with just this: A redirect resource, upon receiving a request without 1392 an Apply-To-Redirect-Ref header, MUST respond with a 302 (Found) 1393 response. The 302 (Found) response MUST include a location header 1394 identifying the target and a Redirect-Ref header. If a redirect 1395 resource receives a request with an Apply-To-Redirect-Ref header then 1396 the redirect reference resource MUST apply the method to itself 1397 rather than blindly returning a 302 (Found) response. 1399 Resolution: Keep a summary along the lines of Yaron's proposal (don't 1400 use the word "blindly"). Keep the bullets detailing the headers to be 1401 returned. Delete the rest, including the examples. See also issue 28, 1402 29, 30, 31, 32. 1404 D.8 lc-57-noautoupdate 1406 Type: change 1408 1411 yarong@Exchange.Microsoft.com (2000-02-11): Add language to forbid 1412 servers from automatically updating redirect resources when their 1413 targets move. 1415 julian.reschke@greenbytes.de (2004-01-05): I don't think we can 1416 forbid that. This spec consists of (a) clarifications of how a server 1417 that supports redirects should behave for specific WebDAV methods, 1418 and (b) extensions to explicitly create them (or to apply a method to 1419 the redirect itself). As such, we shouldn't add any requirements that 1420 HTTP doesn't add. What we could do is (1) note why auto-update may be 1421 a bad idea, and possibly (2) define that redirects created by 1422 MKREDIRECTREF should not behave that way (or alternatively define 1423 more specific resource types). 1425 D.9 12.1-property-name 1427 Type: change 1429 julian.reschke@greenbytes.de (2003-10-06): Sync names for 1430 DAV:reftarget property and "Redirect-Ref" response headers. 1432 Index 1434 A 1435 Apply-To-Redirect-Ref header 19 1437 C 1438 Condition Names 1439 DAV:locked-update-allowed (pre) 8 1440 DAV:name-allowed (pre) 7 1441 DAV:new-redirectref (post) 8 1442 DAV:redirect-lifetime-supported (pre) 8 1443 parent-resource-must-be-non-null (pre) 7 1444 resource-must-be-null (pre) 7 1446 D 1447 DAV header 1448 compliance class 'redirectrefs' 20 1449 DAV:locked-update-allowed precondition 8 1450 DAV:name-allowed precondition 7 1451 DAV:new-redirectref postcondition 8 1452 DAV:parent-resource-must-be-non-null precondition 7 1453 DAV:redirect-lifetime property 19 1454 DAV:redirect-lifetime-supported precondition 8 1455 DAV:redirectref resource type 20 1456 DAV:reftarget property 20 1457 DAV:resource-must-be-null precondition 7 1459 H 1460 Headers 1461 Apply-To-Redirect-Ref 19 1462 Redirect-Ref 19 1464 M 1465 Methods 1466 MKREDIRECTREF 7 1467 MKREDIRECTREF method 7 1469 P 1470 Properties 1471 DAV:redirect-lifetime 19 1472 DAV:reftarget 20 1474 R 1475 Redirect-Ref header 19 1476 Resource Types 1477 DAV:redirectref 20 1479 Intellectual Property Statement 1481 The IETF takes no position regarding the validity or scope of any 1482 Intellectual Property Rights or other rights that might be claimed to 1483 pertain to the implementation or use of the technology described in 1484 this document or the extent to which any license under such rights 1485 might or might not be available; nor does it represent that it has 1486 made any independent effort to identify any such rights. Information 1487 on the IETF's procedures with respect to rights in IETF Documents can 1488 be found in BCP 78 and BCP 79. 1490 Copies of IPR disclosures made to the IETF Secretariat and any 1491 assurances of licenses to be made available, or the result of an 1492 attempt made to obtain a general license or permission for the use of 1493 such proprietary rights by implementers or users of this 1494 specification can be obtained from the IETF on-line IPR repository at 1495 http://www.ietf.org/ipr. 1497 The IETF invites any interested party to bring to its attention any 1498 copyrights, patents or patent applications, or other proprietary 1499 rights that may cover technology that may be required to implement 1500 this standard. Please address the information to the IETF at 1501 ietf-ipr@ietf.org. 1503 Disclaimer of Validity 1505 This document and the information contained herein are provided on an 1506 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1507 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1508 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1509 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1510 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1511 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1513 Copyright Statement 1515 Copyright (C) The Internet Society (2004). This document is subject 1516 to the rights, licenses and restrictions contained in BCP 78, and 1517 except as set forth therein, the authors retain all their rights. 1519 Acknowledgment 1521 Funding for the RFC Editor function is currently provided by the 1522 Internet Society.