idnits 2.17.1 draft-ietf-webdav-redirectref-protocol-09.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 3978, Section 5.1.a on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1446. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1423. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1430. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1436. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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 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: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == Mismatching filename: the document gives the document name as 'draft-ietf-webdav-redirectref-protocol-latest-09', but the file name used is 'draft-ietf-webdav-redirectref-protocol-09' == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 805 has weird spacing: '... the respon...' == Line 923 has weird spacing: '...ment of a 207...' == Line 924 has weird spacing: '...equests to th...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (October 5, 2004) is 7140 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: 8 errors (**), 0 flaws (~~), 7 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: April 5, 2005 G. Clemm 5 IBM 6 J. Reschke, Ed. 7 greenbytes 8 October 5, 2004 10 Web Distributed Authoring and Versioning (WebDAV) Redirect Reference 11 Resources 12 draft-ietf-webdav-redirectref-protocol-latest-09 14 Status of this Memo 16 This document is an Internet-Draft and is subject to all provisions 17 of section 3 of RFC 3667. By submitting this Internet-Draft, each 18 author represents that any applicable patent or other IPR claims of 19 which he or she is aware have been or will be disclosed, and any of 20 which he or she become aware will be disclosed, in accordance with 21 RFC 3668. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on April 5, 2005. 41 Copyright Notice 43 Copyright (C) The Internet Society (2004). 45 Abstract 47 This specification defines redirect reference resources. A redirect 48 reference resource is a resource whose default response is an 49 HTTP/1.1 3xx (Redirection) status code (see RFC2616, Section 10.3), 50 redirecting the client to a different resource, the target resource. 51 A redirect reference makes it possible to access the target resource 52 indirectly, through any URI mapped to the redirect reference 53 resource. There are no integrity guarantees associated with redirect 54 reference resources. 56 Editorial Note (To be removed by RFC Editor before publication) 58 Distribution of this document is unlimited. Please send comments to 59 the Distributed Authoring and Versioning (WebDAV) working group at 60 , which may be joined by sending a 61 message with subject "subscribe" to 62 . Discussions of the WEBDAV 63 working group are archived at 64 . 66 An issues list and XML and HTML versions of this draft are available 67 from 68 . 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 74 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 6 75 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6 76 4. Overview of Redirect Reference Resources . . . . . . . . . . 7 77 5. MKREDIRECTREF Method . . . . . . . . . . . . . . . . . . . . 8 78 5.1 Example: Creating a Redirect Reference Resource with 79 MKREDIRECTREF . . . . . . . . . . . . . . . . . . . . . . 9 80 6. Operations on Redirect Reference Resources . . . . . . . . . 10 81 7. Operations on Collections That Contain Redirect Reference 82 Resources . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 7.1 LOCK on a Collection That Contains Redirect References . . 11 84 7.2 Example: PROPFIND on a Collection with Redirect 85 Reference Resources . . . . . . . . . . . . . . . . . . . 11 86 7.3 Example: PROPFIND with Apply-To-Redirect-Ref on a 87 Collection with Redirect Reference Resources . . . . . . . 13 88 7.4 Example: COPY on a Collection That Contains a Redirect 89 Reference Resource . . . . . . . . . . . . . . . . . . . . 14 90 7.5 Example: LOCK on a Collection That Contains a Redirect 91 Reference Resource . . . . . . . . . . . . . . . . . . . . 15 92 8. Operations on Targets of Redirect Reference Resources . . . 17 93 9. Relative URIs in DAV:reftarget . . . . . . . . . . . . . . . 17 94 9.1 Example: Resolving a Relative URI in a Multi-Status 95 Response . . . . . . . . . . . . . . . . . . . . . . . . . 17 96 10. Redirect References to Collections . . . . . . . . . . . . . 18 97 11. Headers . . . . . . . . . . . . . . . . . . . . . . . . . . 20 98 11.1 Redirect-Ref Response Header . . . . . . . . . . . . . . 20 99 11.2 Apply-To-Redirect-Ref Request Header . . . . . . . . . . 20 100 12. Redirect Reference Resource Properties . . . . . . . . . . . 20 101 12.1 DAV:redirect-lifetime (protected) . . . . . . . . . . . 20 102 12.2 DAV:reftarget (protected) . . . . . . . . . . . . . . . 21 103 13. XML Elements . . . . . . . . . . . . . . . . . . . . . . . . 21 104 13.1 redirectref XML Element . . . . . . . . . . . . . . . . 21 105 14. Extensions to the DAV:response XML Element for 106 Multi-Status Responses . . . . . . . . . . . . . . . . . . . 21 107 15. Capability Discovery . . . . . . . . . . . . . . . . . . . . 21 108 15.1 Example: Discovery of Support for Redirect Reference 109 Resources . . . . . . . . . . . . . . . . . . . . . . . 22 110 16. Security Considerations . . . . . . . . . . . . . . . . . . 22 111 16.1 Privacy Concerns . . . . . . . . . . . . . . . . . . . . 22 112 16.2 Redirect Loops . . . . . . . . . . . . . . . . . . . . . 23 113 16.3 Redirect Reference Resources and Denial of Service . . . 23 114 16.4 Revealing Private Locations . . . . . . . . . . . . . . 23 115 17. Internationalization Considerations . . . . . . . . . . . . 23 116 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . 24 117 19. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 118 20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 119 21. Normative References . . . . . . . . . . . . . . . . . . . . 24 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 25 121 A. Changes to the WebDAV Document Type Definition . . . . . . . 25 122 B. Change Log (to be removed by RFC Editor before 123 publication) . . . . . . . . . . . . . . . . . . . . . . . . 26 124 B.1 Since draft-ietf-webdav-redirectref-protocol-02 . . . . . 26 125 B.2 Since draft-ietf-webdav-redirectref-protocol-03 . . . . . 26 126 B.3 Since draft-ietf-webdav-redirectref-protocol-04 . . . . . 26 127 B.4 Since draft-ietf-webdav-redirectref-protocol-05 . . . . . 26 128 B.5 Since draft-ietf-webdav-redirectref-protocol-06 . . . . . 26 129 B.6 Since draft-ietf-webdav-redirectref-protocol-07 . . . . . 26 130 B.7 Since draft-ietf-webdav-redirectref-protocol-08 . . . . . 27 131 C. Resolved issues (to be removed by RFC Editor before 132 publication) . . . . . . . . . . . . . . . . . . . . . . . . 27 133 C.1 lc-85-301 . . . . . . . . . . . . . . . . . . . . . . . . 27 134 C.2 specify_safeness . . . . . . . . . . . . . . . . . . . . . 28 135 D. Open issues (to be removed by RFC Editor prior to 136 publication) . . . . . . . . . . . . . . . . . . . . . . . . 28 137 D.1 edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 138 D.2 old_clients . . . . . . . . . . . . . . . . . . . . . . . 28 139 D.3 lc-36-server . . . . . . . . . . . . . . . . . . . . . . . 29 140 D.4 lc-33-forwarding . . . . . . . . . . . . . . . . . . . . . 29 141 D.5 3-terminology-redirectref . . . . . . . . . . . . . . . . 29 142 D.6 lc-58-update . . . . . . . . . . . . . . . . . . . . . . . 29 143 D.7 lc-48-s6 . . . . . . . . . . . . . . . . . . . . . . . . . 30 144 D.8 lc-57-noautoupdate . . . . . . . . . . . . . . . . . . . . 30 145 D.9 12.1-property-name . . . . . . . . . . . . . . . . . . . . 30 146 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 147 Intellectual Property and Copyright Statements . . . . . . . 33 149 1. Introduction 151 This specification extends the Web Distributed Authoring Protocol 152 (WebDAV) to enable clients to create new access paths to existing 153 resources. This capability is useful for several reasons: 155 WebDAV makes it possible to organize HTTP resources into hierarchies, 156 placing them into groupings, known as collections, which are more 157 easily browsed and manipulated than a single flat collection. 158 However, hierarchies require categorization decisions that locate 159 resources at a single location in the hierarchy, a drawback when a 160 resource has multiple valid categories. For example, in a hierarchy 161 of vehicle descriptions containing collections for cars and boats, a 162 description of a combination car/boat vehicle could belong in either 163 collection. Ideally, the description should be accessible from both. 164 Allowing clients to create new URIs that access the existing resource 165 lets them put that resource into multiple collections. 167 Hierarchies also make resource sharing more difficult, since 168 resources that have utility across many collections are still forced 169 into a single collection. For example, the mathematics department at 170 one university might create a collection of information on fractals 171 that contains bindings to some local resources, but also provides 172 access to some resources at other universities. For many reasons, it 173 may be undesirable to make physical copies of the shared resources on 174 the local server: to conserve disk space, to respect copyright 175 constraints, or to make any changes in the shared resources visible 176 automatically. Being able to create new access paths to existing 177 resources in other collections or even on other servers is useful for 178 this sort of case. 180 The redirect reference resources defined here provide a mechanism for 181 creating alternative access paths to existing resources. A redirect 182 reference resource is a resource in one collection whose purpose is 183 to forward requests to another resource (its target), possibly in a 184 different collection. In this way, it allows clients to submit 185 requests to the target resource from another collection. It 186 redirects most requests to the target resource using a HTTP status 187 code from the 3xx range (Redirection), thereby providing a form of 188 mediated access to the target resource. 190 A redirect reference is a resource with properties but no body of its 191 own. Properties of a redirect reference resource can contain such 192 information as who created the reference, when, and why. Since 193 redirect reference resources are implemented using HTTP 3xx 194 responses, it generally takes two round trips to submit a request to 195 the intended resource. Redirect references work equally well for 196 local resources and for resources that reside on a different server 197 from the reference. 199 The remainder of this document is structured as follows: Section 3 200 defines terms that will be used throughout the specification. 201 Section 4 provides an overview of redirect reference resources. 202 Section 5 discusses how to create a redirect reference resource. 203 Section 6 defines the semantics of existing methods when applied to 204 redirect reference resources, and Section 7 discusses their semantics 205 when applied to collections that contain redirect reference 206 resources. Sections 8 through 10 discuss several other issues raised 207 by the existence of redirect reference resources. Sections 11 208 through 14 define the new headers, properties, and XML elements 209 required to support redirect reference resources. Section 15 210 discusses capability discovery. Sections 16 through 18 present the 211 security, internationalization, and IANA concerns raised by this 212 specification. The remaining sections provide a variety of 213 supporting information. 215 2. Notational Conventions 217 Since this document describes a set of extensions to the WebDAV 218 Distributed Authoring Protocol [RFC2518], itself an extension to the 219 HTTP/1.1 protocol, the augmented BNF used here to describe protocol 220 elements is exactly the same as described in Section 2.1 of 221 [RFC2616]. Since this augmented BNF uses the basic production rules 222 provided in Section 2.2 of [RFC2616], these rules apply to this 223 document as well. 225 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 226 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 227 document are to be interpreted as described in [RFC2119]. 229 3. Terminology 231 The terminology used here follows and extends that in the WebDAV 232 Distributed Authoring Protocol specification [RFC2518]. Definitions 233 of the terms resource, Uniform Resource Identifier (URI), and Uniform 234 Resource Locator (URL) are provided in [RFC2396]. 236 Redirect Reference Resource 238 A resource created to redirect all requests made to it, using an 239 HTTP status code from the 3xx range, to a defined target resource. 241 Non-Reference Resource 243 A resource that is not a reference to another resource. 245 Target Resource 247 The resource to which requests are forwarded by a reference 248 resource. A target resource can be anything that can be 249 identified by an absolute URI (see [RFC2396], "absoluteURI"). 251 This document uses the terms "precondition", "postcondition" and 252 "protected property" as defined in [RFC3253]. Servers MUST report 253 pre-/postcondition failures as described in section 1.6 of this 254 document. 256 4. Overview of Redirect Reference Resources 258 For all operations submitted to a redirect reference resource, the 259 default response is a 302 (Found), accompanied by the Redirect-Ref 260 header (defined in Section 11.1 below) and the Location header set to 261 the URI of the target resource. With this information, the client 262 can resubmit the request to the URI of the target resource. 264 A redirect reference resource never automatically forwards requests 265 to its target resource. Redirect resources bring the same benefits 266 as links in HTML documents. They can be created and maintained 267 without the involvement or even knowledge of their target resource. 268 This reduces the cost of linking between resources." 270 If the client is aware that it is operating on a redirect reference 271 resource, it can resolve the reference by retrieving the reference 272 resource's DAV:reftarget property (defined in Section 12.2 below), 273 whose value contains the URI of the target resource. It can then 274 submit requests to the target resource. 276 A redirect reference resource is a new type of resource. To 277 distinguish redirect reference resources from non-reference 278 resources, a new value of the DAV:resourcetype property (defined in 279 [RFC2518]), DAV:redirectref, is defined in Section 13.1 below. 281 Since a redirect reference resource is a resource, methods can be 282 applied to the reference resource as well as to its target resource. 283 The Apply-To-Redirect-Ref request header (defined in Section 11.2 284 below) is provided so that referencing-aware clients can control 285 whether an operation is applied to the redirect reference resource or 286 standard HTTP/WebDAV behaviour (redirection with a 3xx status code) 287 should occur. The Apply-To-Redirect-Ref header can be used with most 288 requests to redirect reference resources. This header is 289 particularly useful with PROPFIND, to retrieve the reference 290 resource's own properties. 292 5. MKREDIRECTREF Method 294 The MKREDIRECTREF method requests the creation of a redirect 295 reference resource. 297 If a MKREDIRECTREF request fails, the server state preceding the 298 request MUST be restored. 300 Responses from a MKREDIRECTREF request MUST NOT be cached, as 301 MKREDIRECTREF has non-idempotent and non-safe semantics (see 302 [RFC2616], section 9.1).. 304 Marshalling: 306 The request body MUST be a DAV:mkredirectref XML element. 308 309 310 311 312 314 The DAV:href element is defined in [RFC2518] (Section 12.3) and 315 MUST contain either an absoluteURI or a relativeURI (see 316 [RFC2396], Section 3 and 5). 318 If no DAV:redirect-lifetime element is specified, the server MUST 319 behave as if a value of DAV:temporary was specified. 321 If the request succeeds, the server MUST return 201 (Created) 322 status. 324 If a response body for a successful request is included, it MUST 325 be a DAV:mkredirectref-response XML element. Note that this 326 document does not define any elements for the MKREDIRECTREF 327 response body, but the DAV:mkredirectref-response element is 328 defined to ensure interoperability between future extensions that 329 do define elements for the MKREDIRECTREF response body. 331 333 Preconditions: 335 (DAV:resource-must-be-null): A resource MUST NOT exist at the 336 request-URL. 338 (DAV:parent-resource-must-be-non-null): The request-URL minus the 339 last past segment MUST identify a collection. 341 (DAV:name-allowed): The last segment of the request URL is 342 available for use as a resource name. 344 (DAV:locked-update-allowed): If the collection identified by the 345 Request-URL minus the last path segment is write-locked, then the 346 appropriate token MUST be specified in an If request header. 348 (DAV:redirect-lifetime-supported): If the request body contains a 349 DAV:redirect-lifetime element, the server MUST support the 350 specified lifetime. Support for DAV:temporary is REQUIRED, while 351 support for DAV:permanent is OPTIONAL. 353 Postconditions: 355 (DAV:new-redirectref): a new redirect reference resource is 356 created whose DAV:reftarget property has the value specified in 357 the request body. 359 5.1 Example: Creating a Redirect Reference Resource with MKREDIRECTREF 361 >> Request: 363 MKREDIRECTREF /~whitehead/dav/spec08.ref HTTP/1.1 364 Host: www.example.com 365 Content-Type: text/xml; charset="utf-8" 366 Content-Length: xxx 368 369 370 371 /i-d/draft-webdav-protocol-08.txt 372 373 375 >> Response: 377 HTTP/1.1 201 Created 379 This request resulted in the creation of a new redirect reference 380 resource at http://www.example.com/~whitehead/dav/spec08.ref, which 381 points to the resource identified by the DAV:reftarget property. In 382 this example, the target resource is identified by the URI 383 http://www.example.com/i-d/draft-webdav-protocol-08.txt. The 384 redirect reference resource's DAV:resourcetype property is set to 385 DAV:redirectref and it's DAV:redirect-lifetime property has the value 386 DAV:temporary. 388 6. Operations on Redirect Reference Resources 390 Although non-referencing-aware clients cannot create reference 391 resources, they should be able to submit requests through the 392 reference resources created by reference-aware WebDAV clients. They 393 should be able to follow any references to their targets. To make 394 this possible, a server that receives any request made via a redirect 395 reference resource MUST return a 3xx range (Redirection) status code, 396 unless the request includes an Apply-To-Redirect-Ref header 397 specifying "T". The client and server MUST follow [RFC2616] Section 398 10.3, but with these additional rules: 400 o The Location response header MUST contain an absolute URI that 401 identifies the target of the reference resource. 403 o The response MUST include the Redirect-Ref header. This header 404 allows reference-aware WebDAV clients to recognize the resource as 405 a reference resource and understand the reason for the 406 redirection. 408 A reference-aware WebDAV client can, like a non-referencing client, 409 resubmit the request to the URI in the Location header in order to 410 operate on the target resource. Alternatively, it can resubmit the 411 request to the URI of the redirect reference resource with the 412 "Apply-To-Redirect-Ref: T" header in order to operate on the 413 reference resource itself. In this case, the request MUST be applied 414 to the reference resource itself, and a 3xx response MUST NOT be 415 returned. 417 As redirect references do not have bodies, GET and PUT requests with 418 "Apply-To-Redirect-Ref: T" MUST fail with status 403 (forbidden). 420 7. Operations on Collections That Contain Redirect Reference Resources 422 Consistent with the rules in Section 6, the response for each 423 redirect reference encountered while processing a collection MUST be 424 a 3xx (Redirection) unless a "Apply-To-Redirect-Ref: T" header is 425 included with the request. The overall response will therefore be a 426 207 (Multi-Status). For each DAV:response element representing a 427 redirect reference, the server MUST include an additional 428 DAV:location element, specifying the value of the "Location" header 429 that would be returned otherwise. The extension is defined in 430 Section 14 below. 432 The Apply-To-Redirect-Ref header (defined in Section 11.2) MAY be 433 used with any request on a collection. If present, it will be 434 applied to all redirect reference resources encountered while 435 processing the collection. 437 7.1 LOCK on a Collection That Contains Redirect References 439 An attempt to lock (with Depth: infinity) a collection that contains 440 redirect references without specifying "Apply-To-Redirect-Ref: T" 441 will always fail. The Multi-Status response will contain a 3xx 442 response for each redirect reference. 444 Reference-aware clients can lock the collection by using 445 Apply-To-Redirect-Ref, and, if desired, lock the targets of the 446 redirect references individually. 448 Non-referencing clients must resort to locking each resource 449 individually. 451 7.2 Example: PROPFIND on a Collection with Redirect Reference Resources 453 Suppose a PROPFIND request with Depth: infinity is submitted to the 454 following collection, with the members shown here: 456 /MyCollection/ 457 (non-reference resource) diary.html 458 (redirect reference resource) nunavut 460 >> Request: 462 PROPFIND /MyCollection/ HTTP/1.1 463 Host: example.com 464 Depth: infinity 465 Apply-To-Redirect-Ref: F 466 Content-Type: text/xml 467 Content-Length: xxxx 469 470 471 472 473 474 475 476 >> Response: 478 HTTP/1.1 207 Multi-Status 479 Content-Type: text/xml 480 Content-Length: xxxx 482 483 484 485 /MyCollection/ 486 487 488 489 diary, interests, hobbies 490 491 HTTP/1.1 200 OK 492 493 494 495 /MyCollection/diary.html 496 497 498 499 diary, travel, family, history 500 501 HTTP/1.1 200 OK 502 503 504 505 /MyCollection/nunavut 506 HTTP/1.1 302 Found 507 508 http://example.ca/art/inuit/ 509 510 511 513 In this example the Depth header is set to infinity, and the 514 Apply-To-Redirect-Ref header is set to "F". The collection contains 515 one URI that identifies a redirect reference resource. The response 516 element for the redirect reference resource has a status of 302 517 (Found), and includes a DAV:location extension element to allow 518 clients to retrieve the properties of its target resource. (The 519 response element for the redirect reference resource does not include 520 the requested properties. The client can submit another PROPFIND 521 request to the URI in the DAV:location pseudo-property to retrieve 522 those properties.) 524 7.3 Example: PROPFIND with Apply-To-Redirect-Ref on a Collection with 525 Redirect Reference Resources 527 Suppose a PROPFIND request with "Apply-To-Redirect-Ref: T" and Depth: 528 infinity is submitted to the following collection, with the members 529 shown here: 531 /MyCollection/ 532 (non-reference resource) diary.html 533 (redirect reference resource) nunavut 535 >> Request: 537 PROPFIND /MyCollection/ HTTP/1.1 538 Host: example.com 539 Depth: infinity 540 Apply-To-Redirect-Ref: T 541 Content-Type: text/xml 542 Content-Length: xxxx 544 545 546 547 548 549 550 551 553 >> Response: 555 HTTP/1.1 207 Multi-Status 556 Content-Type: text/xml 557 Content-Length: xxxx 559 560 561 562 /MyCollection/ 563 564 565 566 567 HTTP/1.1 200 OK 568 569 570 571 572 573 574 HTTP/1.1 404 Not Found 575 576 577 578 /MyCollection/diary.html 579 580 581 582 583 HTTP/1.1 200 OK 584 585 586 587 588 589 590 HTTP/1.1 404 Not Found 591 592 593 594 /MyCollection/nunavut 595 596 597 598 599 http://example.ca/art/inuit/ 600 601 602 603 HTTP/1.1 200 OK 604 605 606 608 Since the "Apply-To-Redirect-Ref: T" header is present, the response 609 shows the properties of the redirect reference resource in the 610 collection rather than reporting a 302 status. 612 7.4 Example: COPY on a Collection That Contains a Redirect Reference 613 Resource 615 Suppose a COPY request is submitted to the following collection, with 616 the members shown: 618 /MyCollection/ 619 (non-reference resource) diary.html 620 (redirect reference resource) nunavut with target 621 /Someplace/nunavut.map 623 >> Request: 625 COPY /MyCollection/ HTTP/1.1 626 Host: example.com 627 Depth: infinity 628 Destination: http://example.com/OtherCollection/ 630 >> Response: 632 HTTP/1.1 207 Multi-Status 633 Content-Type: text/xml; charset="utf-8" 634 Content-Length: xxx 636 637 638 639 /MyCollection/nunavut 640 HTTP/1.1 302 Found 641 642 http://example.com//Someplace/nunavut.map 643 644 645 647 In this case, since /MyCollection/nunavut is a redirect reference 648 resource, the COPY operation was only a partial success. The 649 redirect reference resource was not copied, but a 302 response was 650 returned for it. So the resulting collection is as follows: 652 /OtherCollection/ 653 (non-reference resource) diary.html 655 7.5 Example: LOCK on a Collection That Contains a Redirect Reference 656 Resource 658 Suppose a LOCK request is submitted to the following collection, with 659 the members shown: 661 /MyCollection/ 662 (non-reference resource) diary.html 663 (redirect reference resource) nunavut 665 >> Request: 667 LOCK /MyCollection/ HTTP/1.1 668 Host: example.com 669 Apply-To-Redirect-Ref: F 670 Content-Type: text/xml 672 673 674 675 676 678 >> Response: 680 HTTP/1.1 207 Multi-Status 681 Content-Type: text/xml 682 Content-Length: nnnn 684 685 686 687 /MyCollection/ 688 HTTP/1.1 424 Failed Dependency 689 690 691 /MyCollection/diary.html 692 HTTP/1.1 424 Failed Dependency 693 694 695 /MyCollection/nunavut 696 HTTP/1.1 302 Found 697 698 http://example.ca/art/inuit/ 699 700 701 703 The server returns a 302 response code for the redirect reference 704 resource in the collection. Consequently, neither the collection nor 705 any of the resources identified by its internal member URIs were 706 locked. A referencing-aware client can submit a separate LOCK 707 request to the URI in the DAV:location element returned for the 708 redirect reference resource, and can resubmit the LOCK request with 709 the Apply-To-Redirect-Ref header to the collection. At that point 710 both the reference resource and its target resource will be locked 711 (as well as the collection and all the resources identified by its 712 other members). 714 8. Operations on Targets of Redirect Reference Resources 716 Operations on targets of redirect reference resources have no effect 717 on the reference resource. 719 9. Relative URIs in DAV:reftarget 721 The URI in the href in a DAV:reftarget property MAY be a relative 722 URI. In this case, the base URI to be used for resolving the 723 relative URI to absolute form is the URI used in the HTTP message to 724 identify the redirect reference resource to which the DAV:reftarget 725 property belongs. 727 When DAV:reftarget appears in the context of a Multi-Status response, 728 it is in a DAV:response element that contains a single DAV:href 729 element. The value of this DAV:href element serves as the base URI 730 for resolving a relative URI in DAV:reftarget. The value of DAV:href 731 may itself be relative, in which case it must be resolved first in 732 order to serve as the base URI for the relative URI in DAV:reftarget. 733 If the DAV:href element is relative, its base URI is constructed from 734 the scheme component "http", the value of the Host header in the 735 request, and the request-URI. 737 9.1 Example: Resolving a Relative URI in a Multi-Status Response 739 >> Request: 741 PROPFIND /geog/ HTTP/1.1 742 Host: example.com 743 Apply-To-Redirect-Ref: T 744 Depth: 1 745 Content-Type: text/xml 746 Content-Length: nnn 748 749 750 751 752 753 754 755 >> Response: 757 HTTP/1.1 207 Multi-Status 758 Content-Type: text/xml 759 Content-Length: nnn 761 762 763 764 /geog/ 765 766 767 768 769 HTTP/1.1 200 OK 770 771 772 773 HTTP/1.1 404 Not Found 774 775 776 777 /geog/stats.html 778 779 780 781 782 statistics/population/1997.html 783 784 785 HTTP/1.1 200 OK 786 787 788 790 In this example, the relative URI statistics/population/1997.html is 791 returned as the value of reftarget for the reference resource 792 identified by href /geog/stats.html. The href is itself a relative 793 URI, which resolves to http://example.com/geog/stats.html. This is 794 the base URI for resolving the relative URI in reftarget. The 795 absolute URI of reftarget is 796 http://example.com/geog/statistics/population/1997.html. 798 10. Redirect References to Collections 800 In a Request-URI /segment1/segment2/segment3, any of the three 801 segments may identify a redirect reference resource. (See [RFC2396], 802 Section 3.3, for definitions of "path" and "segment".) If any 803 segment in a Request-URI identifies a redirect reference resource, 804 the response SHOULD be a 3xx. The value of the Location header in 805 the response is as follows: 807 The leftmost path segment of the request-URI that identifies a 808 redirect reference resource, together with all path segments and 809 separators to the left of it, is replaced by the value of the 810 redirect reference resource's DAV:reftarget property (resolved to an 811 absolute URI). The remainder of the request-URI is concatenated to 812 this path. 814 Note: If the DAV:reftarget property ends with a "/" and the remainder 815 of the Request-URI is non-empty (and therefore must begin with a 816 "/"), the final "/" in the DAV:reftarget property is dropped before 817 the remainder of the Request-URI is appended. 819 Consider Request-URI /x/y/z.html. Suppose that /x/ is a redirect 820 reference resource whose target resource is collection /a/, which 821 contains redirect reference resource y whose target resource is 822 collection /b/, which contains redirect reference resource z.html 823 whose target resource is /c/d.html. 825 /x/y/z.html 826 | 827 | /x -> /a 828 | 829 v 830 /a/y/z.html 831 | 832 | /a/y -> /b 833 | 834 v 835 /b/z.html 836 | 837 | /b/z.html -> /c/d.html 838 | 839 v 840 /c/d.html 842 In this case the client must follow up three separate 3xx responses 843 before finally reaching the target resource. The server responds to 844 the initial request with a 3xx with Location: /a/y/z.html, and the 845 client resubmits the request to /a/y/z.html. The server responds to 846 this request with a 3xx with Location: /b/z.html, and the client 847 resubmits the request to /b/z.html. The server responds to this 848 request with a 3xx with Location: /c/d.html, and the client resubmits 849 the request to /c/d.html. This final request succeeds. 851 Note: the behavior described above may have a very serious impact 852 on the efficiency of mapping Request-URIs to resources in HTTP 853 request processing. Therefore servers MAY respond with a 404 854 status code if the cost of checking all leading path segments for 855 redirect references seems prohibitive. 857 11. Headers 859 11.1 Redirect-Ref Response Header 861 Redirect-Ref = "Redirect-Ref:" (absoluteURI | relativeURI) 862 ; see sections 3 and 5 of [RFC2396] 864 The Redirect-Ref header is used in all 3xx responses from redirect 865 reference resources. The value is the (possibly relative) URI of the 866 link target as specified during redirect reference resource creation. 868 11.2 Apply-To-Redirect-Ref Request Header 870 Apply-To-Redirect-Ref = "Apply-To-Redirect-Ref" ":" ("T" | "F") 872 The optional Apply-To-Redirect-Ref header can be used on any request 873 to a redirect reference resource. When it is present and set to "T", 874 the request MUST be applied to the reference resource itself, and a 875 3xx response MUST NOT be returned. 877 If the Apply-To-Redirect-Ref header is used on a request to any other 878 sort of resource besides a redirect reference resource, the server 879 MUST ignore it. 881 12. Redirect Reference Resource Properties 883 The properties defined below are REQUIRED on redirect reference 884 resources. 886 12.1 DAV:redirect-lifetime (protected) 888 This property provides information about the lifetime of a redirect. 889 It can either be DAV:permanent (HTTP status 301) or DAV:temporary 890 (HTTP status 302). Future protocols MAY define additional values. 892 893 894 896 12.2 DAV:reftarget (protected) 898 This property provides an efficient way for clients to discover the 899 URI of the target resource. This is a read-only property after its 900 initial creation. Its value can only be set in a MKREDIRECTREF 901 request. The value is a DAV:href element containing the URI of the 902 target resource. 904 906 13. XML Elements 908 13.1 redirectref XML Element 910 Name: redirectref 912 Namespace: DAV: 914 Purpose: Used as the value of the DAV:resourcetype property to 915 specify that the resource type is a redirect reference resource. 917 919 14. Extensions to the DAV:response XML Element for Multi-Status 920 Responses 922 As described in Section 7, the DAV:location element may be returned 923 in the DAV:response element of a 207 Multi-Status response, to allow 924 clients to resubmit their requests to the target resource of a 925 redirect reference resource. 927 Consequently, the definition of the DAV:response XML element changes 928 to the following: 930 932 934 15. Capability Discovery 936 Sections 9.1 and 15 of [RFC2518] describe the use of compliance 937 classes with the DAV header in responses to OPTIONS, to indicate 938 which parts of the WebDAV Distributed Authoring protocols the 939 resource supports. This specification defines an OPTIONAL extension 940 to [RFC2518]. It defines a new compliance class, called 941 redirectrefs, for use with the DAV header in responses to OPTIONS 942 requests. If a resource does support redirect references, its 943 response to an OPTIONS request may indicate that it does, by listing 944 the new redirectrefs compliance class in the DAV header and by 945 listing the MKREDIRECTREF method as one it supports. 947 When responding to an OPTIONS request, any type of resource can 948 include redirectrefs in the value of the DAV header. Doing so 949 indicates that the server permits a redirect reference resource at 950 the request URI. 952 15.1 Example: Discovery of Support for Redirect Reference Resources 954 >> Request: 956 OPTIONS /somecollection/someresource HTTP/1.1 957 Host: example.org 959 >> Response: 961 HTTP/1.1 200 OK 962 Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE 963 Allow: MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, MKREDIRECTREF 964 DAV: 1, 2, redirectrefs 966 The DAV header in the response indicates that the resource 967 /somecollection/someresource is level 1 and level 2 compliant, as 968 defined in [RFC2518]. In addition, /somecollection/someresource 969 supports redirect reference resources. The Allow header indicates 970 that MKREDIRECTREF requests can be submitted to 971 /somecollection/someresource. 973 16. Security Considerations 975 This section is provided to make applications that implement this 976 protocol aware of the security implications of this protocol. 978 All of the security considerations of HTTP/1.1 and the WebDAV 979 Distributed Authoring Protocol specification also apply to this 980 protocol specification. In addition, redirect reference resources 981 introduce several new security concerns and increase the risk of some 982 existing threats. These issues are detailed below. 984 16.1 Privacy Concerns 986 By creating redirect reference resources on a trusted server, it is 987 possible for a hostile agent to induce users to send private 988 information to a target on a different server. This risk is 989 mitigated somewhat, since clients are required to notify the user of 990 the redirection for any request other than GET or HEAD. (See 991 [RFC2616], Section 10.3.3 302 Found.) 993 16.2 Redirect Loops 995 Although redirect loops were already possible in HTTP 1.1, the 996 introduction of the MKREDIRECTREF method creates a new avenue for 997 clients to create loops accidentally or maliciously. If the 998 reference resource and its target are on the same server, the server 999 may be able to detect MKREDIRECTREF requests that would create loops. 1000 See also [RFC2616], Section 10.3 "Redirection 3xx." 1002 16.3 Redirect Reference Resources and Denial of Service 1004 Denial of service attacks were already possible by posting URLs that 1005 were intended for limited use at heavily used Web sites. The 1006 introduction of MKREDIRECTREF creates a new avenue for similar denial 1007 of service attacks. Clients can now create redirect reference 1008 resources at heavily used sites to target locations that were not 1009 designed for heavy usage. 1011 16.4 Revealing Private Locations 1013 There are several ways that redirect reference resources may reveal 1014 information about collection structures. First, the DAV:reftarget 1015 property of every redirect reference resource contains the URI of the 1016 target resource. Anyone who has access to the reference resource can 1017 discover the collection path that leads to the target resource. The 1018 owner of the target resource may have wanted to limit knowledge of 1019 this collection structure. 1021 Sufficiently powerful access control mechanisms can control this risk 1022 to some extent. Property-level access control could prevent users 1023 from examining the DAV:reftarget property. (The Location header 1024 returned in responses to requests on redirect reference resources 1025 reveals the same information, however.) 1027 This risk is no greater than the similar risk posed by HTML links. 1029 17. Internationalization Considerations 1031 All internationalization considerations mentioned in [RFC2518] also 1032 apply to this document. 1034 18. IANA Considerations 1036 All IANA considerations mentioned in [RFC2518] also apply to this 1037 document. 1039 19. Contributors 1041 Many thanks to Jason Crawford, Jim Davis, Chuck Fay and Judith Slein 1042 who can take credit for big parts of the original design of this 1043 specification. 1045 20. Acknowledgements 1047 This document has benefited from thoughtful discussion by Jim Amsden, 1048 Peter Carlson, Steve Carter, Tyson Chihaya, Ken Coar, Ellis Cohen, 1049 Bruce Cragun, Spencer Dawkins, Mark Day, Rajiv Dulepet, David Durand, 1050 Lisa Dusseault, Stefan Eissing, Roy Fielding, Yaron Goland, Fred 1051 Hitt, Alex Hopmann, James Hunt, Marcus Jager, Chris Kaler, Manoj 1052 Kasichainula, Rohit Khare, Daniel LaLiberte, Steve Martin, Larry 1053 Masinter, Jeff McAffer, Joe Orton, Surendra Koduru Reddy, Juergen 1054 Reuter, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness, John 1055 Stracke, John Tigue, John Turner, Kevin Wiggen, and others. 1057 21 Normative References 1059 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1060 Requirement Levels", BCP 14, RFC 2119, March 1997. 1062 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 1063 Resource Identifiers (URI): Generic Syntax", RFC 2396, 1064 August 1998. 1066 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. 1067 Jensen, "HTTP Extensions for Distributed Authoring -- 1068 WEBDAV", RFC 2518, February 1999. 1070 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1071 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext 1072 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1074 [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C. and J. 1075 Whitehead, "Versioning Extensions to WebDAV (Web 1076 Distributed Authoring and Versioning)", RFC 3253, March 1077 2002. 1079 Authors' Addresses 1081 Jim Whitehead 1082 UC Santa Cruz, Dept. of Computer Science 1083 1156 High Street 1084 Santa Cruz, CA 95064 1085 US 1087 EMail: ejw@cse.ucsc.edu 1089 Geoff Clemm 1090 IBM 1091 20 Maguire Road 1092 Lexington, MA 02421 1093 US 1095 EMail: geoffrey.clemm@us.ibm.com 1097 Julian F. Reschke (editor) 1098 greenbytes GmbH 1099 Salzmannstrasse 152 1100 Muenster, NW 48159 1101 Germany 1103 Phone: +49 251 2807760 1104 Fax: +49 251 2807761 1105 EMail: julian.reschke@greenbytes.de 1106 URI: http://greenbytes.de/tech/webdav/ 1108 Appendix A. Changes to the WebDAV Document Type Definition 1110 1112 1113 1115 1117 1119 1121 1123 1125 Appendix B. Change Log (to be removed by RFC Editor before publication) 1127 B.1 Since draft-ietf-webdav-redirectref-protocol-02 1129 Julian Reschke takes editorial role (added to authors list). Cleanup 1130 XML indentation. Start adding all unresolved last call issues. 1131 Update some author's contact information. Update references, split 1132 into "normative" and "informational". Remove non-RFC2616 headers 1133 ("Public") from examples. Fixed width problems in artwork. Start 1134 resolving editorial issues. 1136 B.2 Since draft-ietf-webdav-redirectref-protocol-03 1138 Added Joe Orton and Juergen Reuter to Acknowledgements section. 1139 Close more editorial issues. Remove dependencies on BIND spec. 1141 B.3 Since draft-ietf-webdav-redirectref-protocol-04 1143 More editorial fixes. Clarify that MKRESOURCE can only be used to 1144 create redirect references (switch to new method in a future draft). 1145 Clarify that redirect references do not have bodies. 1147 B.4 Since draft-ietf-webdav-redirectref-protocol-05 1149 Close (accept) issue "lc-79-accesscontrol". Add issue 1150 "rfc2606-compliance". Close issues "lc-50-blindredirect", 1151 "lc-71-relative", "lc-74-terminology". Update contact info for Geoff 1152 Clemm. Moved some of the original authors names to new Contributors 1153 section. Add and close issue "9-MKRESOURCE-vs-relative-URI". Close 1154 issue "lc-72-trailingslash". Close issue "lc-60-ex". Update issue 1155 "lc-85-301" with proposal. Close issue "lc-06-reftarget-relative" 1156 (9-MKRESOURCE-vs-relative-URI was a duplicate of this one). Also 1157 remove section 9.1 (example for MKRESOURCE vs relative URIs). Add 1158 and resolve issue "11.2-apply-to-redirect-ref-syntax" (header now has 1159 values "T" and "F"). Also some cleanup for "rfc2606-compliance". 1160 Typo fixes. Add and resolve "15.1-options-response". 1162 B.5 Since draft-ietf-webdav-redirectref-protocol-06 1164 Resolve issues "lc-19-direct-ref", "lc-28-lang", "lc-29-lang", 1165 "lc-44-pseudo", "lc-53-s10", "lc-61-pseudo", "lc-63-move", 1166 "lc-80-i18n" and "rfc2606-compliance". Start work on index. Add new 1167 issue "old_clients". 1169 B.6 Since draft-ietf-webdav-redirectref-protocol-07 1171 Closed issue "lc-38-not-hierarchical". Cleaned up DTD fragments in 1172 appendix. Close (reject) issues "lc-55-iana" and "lc-41-no-webdav". 1174 Add issue "5_mkresource" and start work on MKREDIRECTREF (issue 1175 closed, but more work on MKREDIRECTREF needs to be done for updates 1176 and status codes other than 302). Start resolution of "lc-85-301", 1177 replacing "302" by more generic language. Update issue 1178 "lc-57-noautoupdate". Close issue "lc-37-integrity" (duplicate of 1179 "lc-57-autoupdate"). Started work on "lc-85-301". Add L. Dusseault 1180 and S. Eissing to Acknowledgments section. 1182 B.7 Since draft-ietf-webdav-redirectref-protocol-08 1184 Fix index entries for conditions. Open and resolve issue 1185 "specify_safeness". Rewrite editorial section and parts of intro. 1186 Add more clarifications for issue "lc-85-301" and close it. 1188 Appendix C. Resolved issues (to be removed by RFC Editor before 1189 publication) 1191 Issues that were either rejected or resolved in this version of this 1192 document. 1194 C.1 lc-85-301 1196 Type: change 1198 ejw@cse.ucsc.edu (2000-01-03): Support creation of other than 302 1199 redirects, especially 301. 1201 julian.reschke@greenbytes.de (2003-10-13): HTTP seems to distinguish 1202 the following use cases: (a) permanent redirect (301), (b) temporary 1203 redirect (302 or 307), (c) redirect to a GET location after POST 1204 (303) and (d) agent-driven negotiation (300). Among these, (a) and 1205 (b) seem to be well understood, so we should support both. (c) 1206 doesn't seem to be applicable. (d) may become interesting when user 1207 agents start supporting it, so the spec should be flexible enough to 1208 support a feature extension for that. For now I propose that the 1209 client is able to specify the redirection type as a resource type, 1210 such as "DAV:permanent-redirect-reference" and 1211 "DAV:temporary-redirect-reference". This spec would only define the 1212 behaviour for these two resource types and would allow future 1213 extensions using new resource types and suggested response codes. 1215 Resolution (2004-10-05): Support creation of both permanent (301, 1216 optional) and temporary (302, required) redirects. Keep protocol 1217 extensible for other types. Make lifetime visible as protected 1218 property. 1220 C.2 specify_safeness 1222 Type: edit 1224 1227 julian.reschke@greenbytes.de (2004-09-19): Specify safeness and 1228 idempotence of new methods. 1230 Resolution (2004-09-20): Done. 1232 Appendix D. Open issues (to be removed by RFC Editor prior to 1233 publication) 1235 D.1 edit 1237 Type: edit 1239 julian.reschke@greenbytes.de (2004-10-03): Umbrella issue for 1240 editorial changes. 1242 D.2 old_clients 1244 Type: change 1246 1249 julian.reschke@greenbytes.de (2003-11-10): There are (at least) two 1250 major design goals, but unfortunately both are in direct 1251 contradiction: #1: Maximum consistency with HTTP/1.1 (RFC2616). This 1252 means that any request that addresses a redirect reference resource 1253 MUST result in a 3xx status code (obviously the whole point is that 1254 GET MUST result in a redirection, and if it does, it's hard to say 1255 why other methods such as PUT or DELETE should behave differently). 1256 Therefore, the redirect reference protocol introduces a new request 1257 header ("Apply-To-Redirect-Ref") through which a client can indicate 1258 that the request indeed should be applied to the redirect reference 1259 resource itself. #2: Maximum usability with existing clients. For 1260 instance, the Microsoft Webfolder client will not be able to DELETE a 1261 redirect reference resource unless the server deviates from #1. 1262 Right now I'm not sure about the best way to resolve this. Currently 1263 the spec chooses #1 (back when this decision was made, there was 1264 probably the assumption that existing clients would quickly be 1265 updated -- something that probably isn't true today). However this 1266 may result in implementers either just ignoring these rules, or 1267 adding special workarounds based on "User Agent" detection. 1269 D.3 lc-36-server 1271 Type: change 1273 1276 yarong@Exchange.Microsoft.com (2000-02-11): Servers: Replace "server" 1277 with "unrelated system" throughout. 1279 Resolution: Try replacing "server" with "host" in some contexts, 1280 rephrasing in passive voice in others. See also issue 40. 1282 D.4 lc-33-forwarding 1284 Type: change 1286 1289 yarong@Exchange.Microsoft.com (2000-02-11): Forwarding: Replace 1290 "forward" with "redirect" throughout. 1292 Resolution: Use "redirect" for the behavior redirect resources do 1293 exhibit. Use "forward" for the contrasting behavior (passing a 1294 method on to the target with no client action needed). Define these 1295 two terms. See also issue 40. 1297 D.5 3-terminology-redirectref 1299 Type: change 1301 1304 julian.reschke@greenbytes.de (2003-07-27): Consider global rename of 1305 "redirect reference resource" to "redirect resource". 1307 D.6 lc-58-update 1309 Type: change 1311 1314 yarong@Exchange.Microsoft.com (2000-02-11): There needs to be a way 1315 to update the target of a redirect reference. 1317 Resolution: Agreed. See also issues 6, 43. 1319 D.7 lc-48-s6 1321 Type: change 1323 1326 yarong@Exchange.Microsoft.com (2000-02-11): Replace all of section 6 1327 with just this: A redirect resource, upon receiving a request without 1328 an Apply-To-Redirect-Ref header, MUST respond with a 302 (Found) 1329 response. The 302 (Found) response MUST include a location header 1330 identifying the target and a Redirect-Ref header. If a redirect 1331 resource receives a request with an Apply-To-Redirect-Ref header then 1332 the redirect reference resource MUST apply the method to itself 1333 rather than blindly returning a 302 (Found) response. 1335 Resolution: Keep a summary along the lines of Yaron's proposal (don't 1336 use the word "blindly"). Keep the bullets detailing the headers to 1337 be returned. Delete the rest, including the examples. See also 1338 issue 28, 29, 30, 31, 32. 1340 D.8 lc-57-noautoupdate 1342 Type: change 1344 1347 yarong@Exchange.Microsoft.com (2000-02-11): Add language to forbid 1348 servers from automatically updating redirect resources when their 1349 targets move. 1351 julian.reschke@greenbytes.de (2004-01-05): I don't think we can 1352 forbid that. This spec consists of (a) clarifications of how a 1353 server that supports redirects should behave for specific WebDAV 1354 methods, and (b) extensions to explicitly create them (or to apply a 1355 method to the redirect itself). As such, we shouldn't add any 1356 requirements that HTTP doesn't add. What we could do is (1) note why 1357 auto-update may be a bad idea, and possibly (2) define that redirects 1358 created by MKREDIRECTREF should not behave that way (or alternatively 1359 define more specific resource types). 1361 D.9 12.1-property-name 1363 Type: change 1364 julian.reschke@greenbytes.de (2003-10-06): Sync names for 1365 DAV:reftarget property and "Redirect-Ref" response headers. 1367 Index 1369 A 1370 Apply-To-Redirect-Ref header 20 1372 C 1373 Condition Names 1374 DAV:locked-update-allowed (pre) 9 1375 DAV:name-allowed (pre) 9 1376 DAV:new-redirectref (post) 9 1377 DAV:parent-resource-must-be-non-null (pre) 8 1378 DAV:redirect-lifetime-supported (pre) 9 1379 DAV:resource-must-be-null (pre) 8 1381 D 1382 DAV header 1383 compliance class 'redirectrefs' 21 1384 DAV:locked-update-allowed precondition 9 1385 DAV:name-allowed precondition 9 1386 DAV:new-redirectref postcondition 9 1387 DAV:parent-resource-must-be-non-null precondition 8 1388 DAV:redirect-lifetime property 20 1389 DAV:redirect-lifetime-supported precondition 9 1390 DAV:redirectref resource type 21 1391 DAV:reftarget property 21 1392 DAV:resource-must-be-null precondition 8 1394 H 1395 Headers 1396 Apply-To-Redirect-Ref 20 1397 Redirect-Ref 20 1399 M 1400 Methods 1401 MKREDIRECTREF 8 1402 MKREDIRECTREF method 8 1404 P 1405 Properties 1406 DAV:redirect-lifetime 20 1407 DAV:reftarget 21 1409 R 1410 Redirect-Ref header 20 1411 Resource Types 1412 DAV:redirectref 21 1414 Intellectual Property Statement 1416 The IETF takes no position regarding the validity or scope of any 1417 Intellectual Property Rights or other rights that might be claimed to 1418 pertain to the implementation or use of the technology described in 1419 this document or the extent to which any license under such rights 1420 might or might not be available; nor does it represent that it has 1421 made any independent effort to identify any such rights. Information 1422 on the procedures with respect to rights in RFC documents can be 1423 found in BCP 78 and BCP 79. 1425 Copies of IPR disclosures made to the IETF Secretariat and any 1426 assurances of licenses to be made available, or the result of an 1427 attempt made to obtain a general license or permission for the use of 1428 such proprietary rights by implementers or users of this 1429 specification can be obtained from the IETF on-line IPR repository at 1430 http://www.ietf.org/ipr. 1432 The IETF invites any interested party to bring to its attention any 1433 copyrights, patents or patent applications, or other proprietary 1434 rights that may cover technology that may be required to implement 1435 this standard. Please address the information to the IETF at 1436 ietf-ipr@ietf.org. 1438 Disclaimer of Validity 1440 This document and the information contained herein are provided on an 1441 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1442 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1443 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1444 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1445 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1446 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1448 Copyright Statement 1450 Copyright (C) The Internet Society (2004). This document is subject 1451 to the rights, licenses and restrictions contained in BCP 78, and 1452 except as set forth therein, the authors retain all their rights. 1454 Acknowledgment 1456 Funding for the RFC Editor function is currently provided by the 1457 Internet Society.