diff options
Diffstat (limited to 'doc/rfc/rfc4437.txt')
| -rw-r--r-- | doc/rfc/rfc4437.txt | 1403 |
1 files changed, 1403 insertions, 0 deletions
diff --git a/doc/rfc/rfc4437.txt b/doc/rfc/rfc4437.txt new file mode 100644 index 0000000..0beed3b --- /dev/null +++ b/doc/rfc/rfc4437.txt @@ -0,0 +1,1403 @@ + + + + + + +Network Working Group J. Whitehead +Request for Comments: 4437 U.C. Santa Cruz +Category: Experimental G. Clemm + IBM + J. Reschke, Ed. + greenbytes + March 2006 + + + Web Distributed Authoring and Versioning (WebDAV) + Redirect Reference Resources + + +Status of This Memo + + This memo defines an Experimental Protocol for the Internet + community. It does not specify an Internet standard of any kind. + Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This specification defines an extension to Web Distributed Authoring + and Versioning (WebDAV) to allow clients to author HTTP redirect + reference resources whose default response is an HTTP/1.1 3xx + (Redirection) status code. A redirect reference makes it possible to + access the target resourced indirectly through any URI mapped to the + redirect reference resource. This specification does not address + remapping of trees of resources or regular expression based + redirections. There are no integrity guarantees associated with + redirect reference resources. Other mechanisms can also be used to + achieve the same functionality as this specification. This + specification allows operators to experiment with this mechanism and + develop experience on what is the best approach to the problem. + +Table of Contents + + 1. Introduction ....................................................3 + 2. Notational Conventions ..........................................4 + 3. Terminology .....................................................4 + 4. Overview of Redirect Reference Resources ........................5 + 5. Operations on Redirect Reference Resources ......................6 + 6. MKREDIRECTREF Method ............................................7 + + + + +Whitehead, et al. Experimental [Page 1] + +RFC 4437 WebDAV Redirect Reference Resources March 2006 + + + 6.1. Example: Creating a Redirect Reference Resource + with MKREDIRECTREF .........................................8 + 7. UPDATEREDIRECTREF Method ........................................9 + 7.1. Example: Updating a Redirect Reference Resource with + UPDATEREDIRECTREF .........................................10 + 8. Operations on Collections That Contain Redirect + Reference Resources ............................................11 + 8.1. Example: PROPFIND on a Collection with Redirect + Reference .................................................11 + 8.2. Example: PROPFIND with Apply-To-Redirect-Ref on a + Collection with Redirect Reference Resources ..............13 + 9. Operations on Targets of Redirect Reference Resources ..........15 + 10. Relative References in DAV:reftarget ..........................15 + 10.1. Example: Resolving a Relative Reference in a + Multi-Status Response.....................................16 + 11. Redirect References to Collections ............................17 + 12. Headers .......................................................18 + 12.1. Redirect-Ref Response Header .............................18 + 12.2. Apply-To-Redirect-Ref Request Header .....................19 + 13. Redirect Reference Resource Properties ........................19 + 13.1. DAV:redirect-lifetime (protected) ........................19 + 13.2. DAV:reftarget (protected) ................................19 + 14. XML Elements ..................................................19 + 14.1. redirectref XML Element ..................................19 + 15. Extensions to the DAV:response XML Element for Multi-Status + Responses .....................................................20 + 16. Capability Discovery ..........................................20 + 16.1. Example: Discovery of Support for Redirect + Reference Resources ......................................20 + 17. Security Considerations .......................................21 + 17.1. Privacy Concerns .........................................21 + 17.2. Redirect Loops ...........................................21 + 17.3. Redirect Reference Resources and Denial of Service .......21 + 17.4. Revealing Private Locations ..............................22 + 18. Internationalization Considerations ...........................22 + 19. IANA Considerations ...........................................22 + 19.1. HTTP headers .............................................22 + 19.1.1. Redirect-Ref ......................................22 + 19.1.2. Apply-To-Redirect-Ref .............................23 + 20. Contributors ..................................................23 + 21. Acknowledgements ..............................................23 + 22. Normative References ..........................................23 + + + + + + + + + +Whitehead, et al. Experimental [Page 2] + +RFC 4437 WebDAV Redirect Reference Resources March 2006 + + +1. Introduction + + This specification extends the Web Distributed Authoring Protocol + (WebDAV) to enable clients to create new access paths to existing + resources. This capability is useful for several reasons. + + WebDAV makes it possible to organize HTTP resources into hierarchies, + placing them into groupings, known as collections, that are more + easily browsed and manipulated than a single flat collection. + However, hierarchies require categorization decisions that locate + resources at a single location in the hierarchy, a drawback when a + resource has multiple valid categories. For example, in a hierarchy + of vehicle descriptions containing collections for cars and boats, a + description of a combination car/boat vehicle could belong in either + collection. Ideally, the description should be accessible from both. + Allowing clients to create new URIs that access the existing resource + lets them put that resource into multiple collections. + + Hierarchies also make resource sharing more difficult, since + resources that have utility across many collections are still forced + into a single collection. For example, the mathematics department at + one university might create a collection of information on fractals + that contains bindings to some local resources, but also provides + access to some resources at other universities. For many reasons, it + may be undesirable to make physical copies of the shared resources: + to conserve disk space, to respect copyright constraints, or to make + any changes in the shared resources visible automatically. Being + able to create new access paths to existing resources in other + collections or even on other unrelated systems is useful for this + sort of case. + + The redirect reference resources defined here provide a mechanism for + creating alternative access paths to existing resources. A redirect + reference resource is a resource in one collection whose purpose is + to redirect requests to another resource (its target), possibly in a + different collection. In this way, it allows clients to submit + requests to the target resource from another collection. It + redirects most requests to the target resource using an HTTP status + code from the 3xx range (Redirection), thereby providing a form of + mediated access to the target resource. + + + + + + + + + + + +Whitehead, et al. Experimental [Page 3] + +RFC 4437 WebDAV Redirect Reference Resources March 2006 + + + A redirect reference is a resource with properties but with no body + of its own. Properties of a redirect reference resource can contain + information such as who created the reference, when, and why. Since + redirect reference resources are implemented using HTTP 3xx + responses, it generally takes two round trips to submit a request to + the intended resource. Redirect references work equally well for + local resources and for resources that reside on a different system + from the reference. + + The remainder of this document is structured as follows: Section 3 + defines terms that will be used throughout the specification. + Section 4 provides an overview of redirect reference resources. + Section 5 defines the semantics of existing methods when applied to + redirect reference resources. Section 6 discusses how to create a + redirect reference resource, and Section 7 discusses updating + redirect references. Section 8 discusses their semantics when + applied to collections that contain redirect reference resources. + Sections 9 through 11 discuss several other issues raised by the + existence of redirect reference resources. Sections 12 through 15 + define the new headers, properties, and XML elements required to + support redirect reference resources. Section 16 discusses + capability discovery. Sections 17 through 19 present the security, + internationalization, and IANA concerns raised by this specification. + The remaining sections provide a variety of supporting information. + +2. Notational Conventions + + Since this document describes a set of extensions to the WebDAV + Distributed Authoring Protocol [RFC2518], itself an extension to the + HTTP/1.1 protocol, the augmented BNF used here to describe protocol + elements is exactly the same as described in Section 2.1 of + [RFC2616]. Since this augmented BNF uses the basic production rules + provided in Section 2.2 of [RFC2616], these rules apply to this + document as well. + + In this document, the key words "MUST", "MUST NOT", "REQUIRED", + "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", + and "OPTIONAL" are to be interpreted as described in [RFC2119]. + +3. Terminology + + The terminology used here follows and extends that in the WebDAV + Distributed Authoring Protocol specification [RFC2518]. Definitions + of the terms resource, Uniform Resource Identifier (URI), and Uniform + Resource Locator (URL) are provided in [RFC3986]. + + + + + + +Whitehead, et al. Experimental [Page 4] + +RFC 4437 WebDAV Redirect Reference Resources March 2006 + + + Redirect Reference Resource + + A resource created to redirect all requests made to it, using an + HTTP status code from the 3xx range, to a defined target resource. + + Non-Reference Resource + + A resource that is not a reference to another resource. + + Target Resource + + The resource to which requests are redirected by a redirect + reference resource. A target resource can be anything that can be + identified by an absolute URI (see [RFC3986], "absolute-URI"). + + This document uses the terms "precondition", "postcondition", and + "protected property" as defined in [RFC3253]. Servers MUST report + pre-/postcondition failures as described in Section 1.6 of this + document. + +4. Overview of Redirect Reference Resources + + For all operations submitted to a redirect reference resource, the + default response is a 302 (Found), accompanied by the Redirect-Ref + header (defined in Section 12.1, below) and the Location header + ([RFC2616], Section 14.30) set to the URI of the target resource. + With this information, the client can resubmit the request to the URI + of the target resource. + + A redirect reference resource never automatically forwards requests + to its target resource. Redirect resources bring the same benefits + as links in HTML documents. They can be created and maintained + without the involvement or even knowledge of their target resource. + This reduces the cost of linking between resources. + + If the client is aware that it is operating on a redirect reference + resource, it can resolve the reference by retrieving the reference + resource's DAV:reftarget property (defined in Section 13.2, below), + whose value contains the URI of the target resource. It can then + submit requests to the target resource. + + A redirect reference resource is a new type of resource. To + distinguish redirect reference resources from non-reference + resources, a new value of the DAV:resourcetype property (defined in + [RFC2518]), DAV:redirectref, is defined in Section 14.1, below. + + Since a redirect reference resource is a resource, methods can be + applied to the reference resource as well as to its target resource. + + + +Whitehead, et al. Experimental [Page 5] + +RFC 4437 WebDAV Redirect Reference Resources March 2006 + + + The Apply-To-Redirect-Ref request header (defined in Section 12.2, + below) is provided so that referencing-aware clients can control + whether an operation is applied to the redirect reference resource or + standard HTTP/WebDAV behaviour (redirection with a 3xx status code) + should occur. The Apply-To-Redirect-Ref header can be used with most + requests to redirect reference resources. This header is + particularly useful with PROPFIND, to retrieve the reference + resource's own properties. + + Implementation Note: Operations on the target of a redirect reference + usually do not affect the redirect reference itself. However, + clients should not rely on this behaviour (for instance, some servers + may update redirect references as a result of namespace operations on + the reference's target). + +5. Operations on Redirect Reference Resources + + Although non-referencing-aware clients cannot create reference + resources, they should be able to submit requests through the + reference resources created by reference-aware WebDAV clients. They + should be able to follow any references to their targets. To make + this possible, a server that receives any request made via a redirect + reference resource MUST return a 3xx range (Redirection) status code, + unless the request includes an Apply-To-Redirect-Ref header + specifying "T". The client and server MUST follow [RFC2616], Section + 10.3, but with these additional rules: + + o The Location response header MUST contain a URI (see [RFC3986], + Section 3) that identifies the target of the reference resource. + + o The response MUST include the Redirect-Ref header. This header + allows reference-aware WebDAV clients to recognize the resource as + a reference resource and to understand the reason for the + redirection. + + A reference-aware WebDAV client can, like a non-referencing client, + resubmit the request to the URI in the Location header in order to + operate on the target resource. Alternatively, it can resubmit the + request to the URI of the redirect reference resource with the + "Apply-To-Redirect-Ref: T" header in order to operate on the + reference resource itself. In this case, the request MUST be applied + to the reference resource itself, and a 3xx response MUST NOT be + returned. + + As redirect references do not have bodies, GET and PUT requests with + "Apply-To-Redirect-Ref: T" MUST fail with status 403 (forbidden). + + + + + +Whitehead, et al. Experimental [Page 6] + +RFC 4437 WebDAV Redirect Reference Resources March 2006 + + +6. MKREDIRECTREF Method + + The MKREDIRECTREF method requests the creation of a redirect + reference resource. + + If a MKREDIRECTREF request fails, the server state preceding the + request MUST be restored. + + Responses from a MKREDIRECTREF request MUST NOT be cached, as + MKREDIRECTREF has non-idempotent and non-safe semantics (see + [RFC2616], Section 9.1). + + Marshalling + + The request body MUST be a DAV:mkredirectref XML element. + + <!ELEMENT mkredirectref (reftarget, redirect-lifetime?)> + <!ELEMENT reftarget (href)> + <!ELEMENT redirect-lifetime (permanent | temporary)> + <!ELEMENT permanent EMPTY> + <!ELEMENT temporary EMPTY> + + The DAV:href element is defined in [RFC2518] (Section 12.3) and + MUST contain either a URI or a relative-ref (see [RFC3986], + Sections 3 and 4.2). + + If no DAV:redirect-lifetime element is specified, the server MUST + behave as if a value of DAV:temporary was specified. + + If the request succeeds, the server MUST return 201 (Created) + status. + + If a response body for a successful request is included, it MUST + be a DAV:mkredirectref-response XML element. Note that this + document does not define any elements for the MKREDIRECTREF + response body, but the DAV:mkredirectref-response element is + defined to ensure interoperability between future extensions that + do define elements for the response body. + + <!ELEMENT mkredirectref-response ANY> + + Preconditions + + (DAV:resource-must-be-null): A resource MUST NOT exist at the + Request-URI. + + (DAV:parent-resource-must-be-non-null): The Request-URI minus the + last past segment MUST identify a collection. + + + +Whitehead, et al. Experimental [Page 7] + +RFC 4437 WebDAV Redirect Reference Resources March 2006 + + + (DAV:name-allowed): The last segment of the Request-URI is + available for use as a resource name. + + (DAV:locked-update-allowed): If the collection identified by the + Request-URI minus the last path segment is write-locked, then the + appropriate token MUST be specified in an If request header. + + (DAV:redirect-lifetime-supported): If the request body contains a + DAV:redirect-lifetime element, the server MUST support the + specified lifetime. Support for DAV:temporary is REQUIRED, while + support for DAV:permanent is OPTIONAL. + + (DAV:legal-reftarget): The specified is a legal URI or relative- + ref. + + Postconditions + + (DAV:new-redirectref): a new redirect reference resource is + created whose DAV:reftarget property has the value specified in + the request body. + +6.1. Example: Creating a Redirect Reference Resource with MKREDIRECTREF + + >> Request: + + MKREDIRECTREF /~whitehead/dav/spec08.ref HTTP/1.1 + Host: www.example.com + Content-Type: text/xml; charset="utf-8" + Content-Length: xxx + + <?xml version="1.0" encoding="utf-8" ?> + <D:mkredirectref xmlns:D="DAV:"> + <D:reftarget> + <D:href>/i-d/draft-webdav-protocol-08.txt</D:href> + </D:reftarget> + </D:mkredirectref> + + >> Response: + + HTTP/1.1 201 Created + + + + + + + + + + + +Whitehead, et al. Experimental [Page 8] + +RFC 4437 WebDAV Redirect Reference Resources March 2006 + + + This request resulted in the creation of a new redirect reference + resource at http://www.example.com/~whitehead/dav/spec08.ref, which + points to the resource identified by the DAV:reftarget property. In + this example, the target resource is identified by the URI + http://www.example.com/i-d/draft-webdav-protocol-08.txt. The + redirect reference resource's DAV:resourcetype property is set to + DAV:redirectref, and its DAV:redirect-lifetime property has the value + DAV:temporary. + +7. UPDATEREDIRECTREF Method + + The UPDATEREDIRECTREF method requests the update of a redirect + reference resource. + + If a UPDATEREDIRECTREF request fails, the server state preceding the + request MUST be restored. + + Responses from a UPDATEREDIRECTREF request MUST NOT be cached, as + UPDATEREDIRECTREF has non-safe semantics (see [RFC2616], Section + 9.1). + + Marshalling + + The request body MUST be a DAV:updateredirectref XML element. + + <!ELEMENT updateredirectref (reftarget?, redirect-lifetime?)> + + See Section 6 for a definition of DAV:reftarget and DAV:redirect- + lifetime. + + If no DAV:reftarget element is specified, the server MUST NOT + change the target of the redirect reference. + + If no DAV:redirect-lifetime element is specified, the server MUST + NOT change the lifetime of the redirect reference. + + If a response body for a successful request is included, it MUST + be a DAV:updateredirectref-response XML element. Note that this + document does not define any elements for the UPDATEREDIRECTREF + response body, but the DAV:updateredirectref-response element is + defined to ensure interoperability between future extensions that + do define elements for the response body. + + <!ELEMENT updateredirectref-response ANY> + + + + + + + +Whitehead, et al. Experimental [Page 9] + +RFC 4437 WebDAV Redirect Reference Resources March 2006 + + + Preconditions + + (DAV:locked-update-allowed): if the resource is write-locked, then + the appropriate token MUST be specified in an If request header. + + (DAV:must-be-redirectref): the resource identified by the + Request-URI must be a redirect reference resource as defined by + this specification. + + (DAV:redirect-lifetime-supported): see Section 6. + + (DAV:redirect-lifetime-update-supported): servers MAY support + changing the DAV:redirect-lifetime property; if they don't, this + condition code can be used to signal failure. + + (DAV:legal-reftarget): see Section 6. + + Postconditions + + (DAV:redirectref-updated): the DAV:reftarget and DAV:redirect- + lifetime properties of the redirect reference have been updated + accordingly. + +7.1. Example: Updating a Redirect Reference Resource with + UPDATEREDIRECTREF + + >> Request: + + UPDATEREDIRECTREF /~whitehead/dav/spec08.ref HTTP/1.1 + Host: www.example.com + Apply-To-Redirect-Ref: T + Content-Type: text/xml; charset="utf-8" + Content-Length: xxx + + <?xml version="1.0" encoding="utf-8" ?> + <D:updateredirectref xmlns:D="DAV:"> + <D:reftarget> + <D:href>/i-d/draft-webdav-protocol-08b.txt</D:href> + </D:reftarget> + </D:updateredirectref> + + >> Response: + + HTTP/1.1 200 OK + + This request has updated the redirect reference's DAV:reftarget + property to "/i-d/draft-webdav-protocol-08b.txt" and has not changed + the DAV:redirect-lifetime value. Note that the "Apply-To-Redirect- + + + +Whitehead, et al. Experimental [Page 10] + +RFC 4437 WebDAV Redirect Reference Resources March 2006 + + + Ref" request header must be used; otherwise, the request would result + in a redirect (3xx) response status. + +8. Operations on Collections That Contain Redirect Reference Resources + + According to [RFC2518], Section 9.2, methods that have defined + interactions with the "Depth" request header should apply all other + request headers to each resource in scope. However, applying this + principle to the "Apply-To-Redirect-Ref" header uniformly would make + it impractical to implement this specification on top of existing + servers and also would result in unexpected server behaviour for + clients that do not take the existence of redirect references into + account. On the other hand, the definition of the "Depth" header + allows alternate behaviours to be explicitly defined. + + For this reason, this specification defines the interaction between + "Depth" and "Apply-To-Redirect-Ref" request headers on a case-by-case + basis and also provides a default for methods not mentioned here that + do not specify the behaviour themselves. + + +-------------+-----------------+------------------+-----------+ + | method name | defined in | supported depths | behaviour | + +-------------+-----------------+------------------+-----------+ + | COPY | [RFC2518], 8.9 | 0, infinity | "T" | + | DELETE | [RFC2518], 8.7 | infinity | "T" | + | LOCK | [RFC2518], 8.11 | 0, infinity | "T" | + | MOVE | [RFC2518], 8.10 | 0, infinity | "T" | + | PROPFIND | [RFC2518], 8.2 | 0, 1, infinity | inherit | + | REPORT | [RFC3253], 3.6 | 0, 1, infinity | inherit | + | default | | | "T" | + +-------------+-----------------+------------------+-----------+ + + When the behaviour is defined to be "inherit", the method should + follow RFC2518's default behaviour for "Depth" operations, which + means applying the value given for "Apply-To-Redirect-Ref" to each + resource in scope. On the other hand, when it is defined to be "T", + the method should behave as if a "Apply-To-Redirect-Ref: T" header + was specified for each operation on child resources. The latter + ensures that "Depth: infinity" operations will not fail unexpectedly + just because there was a redirect reference resource in scope. + +8.1. Example: PROPFIND on a Collection with Redirect Reference + Resources + + Suppose a PROPFIND request with Depth: infinity is submitted to the + following collection, with the members shown here: + + + + + +Whitehead, et al. Experimental [Page 11] + +RFC 4437 WebDAV Redirect Reference Resources March 2006 + + + /MyCollection/ + (non-reference resource) diary.html + (redirect reference resource) nunavut + + >> Request: + + PROPFIND /MyCollection/ HTTP/1.1 + Host: example.com + Depth: infinity + Apply-To-Redirect-Ref: F + Content-Type: text/xml + Content-Length: xxxx + + <?xml version="1.0" ?> + <D:propfind xmlns:D="DAV: "> + <D:prop xmlns:J="http://example.com/jsprops/"> + <D:resourcetype/> + <J:keywords/> + </D:prop> + </D:propfind> + + >> Response: + + HTTP/1.1 207 Multi-Status + Content-Type: text/xml + Content-Length: xxxx + + <?xml version="1.0" ?> + <D:multistatus xmlns:D="DAV:" xmlns:J="http://example.com/jsprops/"> + <D:response> + <D:href>/MyCollection/</D:href> + <D:propstat> + <D:prop> + <D:resourcetype><D:collection/></D:resourcetype> + <J:keywords>diary, interests, hobbies</J:keywords> + </D:prop> + <D:status>HTTP/1.1 200 OK</D:status> + </D:propstat> + </D:response> + <D:response> + <D:href>/MyCollection/diary.html</D:href> + <D:propstat> + <D:prop> + <D:resourcetype/> + <J:keywords>diary, travel, family, history</J:keywords> + </D:prop> + <D:status>HTTP/1.1 200 OK</D:status> + </D:propstat> + + + +Whitehead, et al. Experimental [Page 12] + +RFC 4437 WebDAV Redirect Reference Resources March 2006 + + + </D:response> + <D:response> + <D:href>/MyCollection/nunavut</D:href> + <D:status>HTTP/1.1 302 Found</D:status> + <D:location> + <D:href>http://example.ca/art/inuit/</D:href> + </D:location> + </D:response> + </D:multistatus> + + In this example, the Depth header is set to infinity, and the Apply- + To-Redirect-Ref header is set to "F". The collection contains one + URI that identifies a redirect reference resource. The response + element for the redirect reference resource has a status of 302 + (Found) and includes a DAV:location extension element to allow + clients to retrieve the properties of its target resource. (The + response element for the redirect reference resource does not include + the requested properties. The client can submit another PROPFIND + request to the URI in the DAV:location pseudo-property to retrieve + those properties.) + +8.2. Example: PROPFIND with Apply-To-Redirect-Ref on a Collection with + Redirect Reference Resources + + Suppose a PROPFIND request with "Apply-To-Redirect-Ref: T" and Depth: + infinity is submitted to the following collection, with the members + shown here: + + /MyCollection/ + (non-reference resource) diary.html + (redirect reference resource) nunavut + + >> Request: + + PROPFIND /MyCollection/ HTTP/1.1 + Host: example.com + Depth: infinity + Apply-To-Redirect-Ref: T + Content-Type: text/xml + Content-Length: xxxx + + + + + + + + + + + +Whitehead, et al. Experimental [Page 13] + +RFC 4437 WebDAV Redirect Reference Resources March 2006 + + + <?xml version="1.0" ?> + <D:propfind xmlns:D="DAV:"> + <D:prop> + <D:resourcetype/> + <D:reftarget/> + <D:redirect-lifetime/> + </D:prop> + </D:propfind> + + >> Response: + + HTTP/1.1 207 Multi-Status + Content-Type: text/xml + Content-Length: xxxx + + <?xml version="1.0" ?> + <D:multistatus xmlns:D="DAV:"> + <D:response> + <D:href>/MyCollection/</D:href> + <D:propstat> + <D:prop> + <D:resourcetype><D:collection/></D:resourcetype> + </D:prop> + <D:status>HTTP/1.1 200 OK</D:status> + </D:propstat> + <D:propstat> + <D:prop> + <D:reftarget/> + <D:redirect-lifetime/> + </D:prop> + <D:status>HTTP/1.1 404 Not Found</D:status> + </D:propstat> + </D:response> + <D:response> + <D:href>/MyCollection/diary.html</D:href> + <D:propstat> + <D:prop> + <D:resourcetype/> + </D:prop> + <D:status>HTTP/1.1 200 OK</D:status> + </D:propstat> + <D:propstat> + <D:prop> + <D:reftarget/> + <D:redirect-lifetime/> + </D:prop> + <D:status>HTTP/1.1 404 Not Found</D:status> + </D:propstat> + + + +Whitehead, et al. Experimental [Page 14] + +RFC 4437 WebDAV Redirect Reference Resources March 2006 + + + </D:response> + <D:response> + <D:href>/MyCollection/nunavut</D:href> + <D:propstat> + <D:prop> + <D:resourcetype><D:redirectref/></D:resourcetype> + <D:reftarget> + <D:href>http://example.ca/art/inuit/</D:href> + </D:reftarget> + <D:redirect-lifetime><D:temporary/></D:redirect-lifetime> + </D:prop> + <D:status>HTTP/1.1 200 OK</D:status> + </D:propstat> + </D:response> + </D:multistatus> + + Since the "Apply-To-Redirect-Ref: T" header is present, the response + shows the properties of the redirect reference resource in the + collection rather than reporting a 302 status. + +9. Operations on Targets of Redirect Reference Resources + + Operations on targets of redirect reference resources have no effect + on the reference resource. + +10. Relative References in DAV:reftarget + + The URI in the href in a DAV:reftarget property MAY be a relative + reference. In this case, the base URI to be used for resolving it to + absolute form is the URI used in the HTTP message to identify the + redirect reference resource to which the DAV:reftarget property + belongs. + + When DAV:reftarget appears in the context of a Multi-Status response, + it is in a DAV:response element that contains a single DAV:href + element. The value of this DAV:href element serves as the base URI + for resolving a relative reference in DAV:reftarget. The value of + DAV:href may itself be relative, in which case it must be resolved + first in order to serve as the base URI for the relative reference in + DAV:reftarget. If the DAV:href element is relative, its base URI is + constructed from the scheme component "http", the value of the Host + header in the request, and the Request-URI. + + + + + + + + + +Whitehead, et al. Experimental [Page 15] + +RFC 4437 WebDAV Redirect Reference Resources March 2006 + + +10.1. Example: Resolving a Relative Reference in a Multi-Status + Response + + >> Request: + + PROPFIND /geog/ HTTP/1.1 + Host: example.com + Apply-To-Redirect-Ref: T + Depth: 1 + Content-Type: text/xml + Content-Length: nnn + + <?xml version="1.0" ?> + <D:propfind xmlns:D="DAV:"> + <D:prop> + <D:resourcetype/> + <D:reftarget/> + </D:prop> + </D:propfind> + + >> Response: + + HTTP/1.1 207 Multi-Status + Content-Type: text/xml + Content-Length: nnn + + <?xml version="1/0" ?> + <D:multistatus xmlns:D="DAV:"> + <D:response> + <D:href>/geog/</D:href> + <D:propstat> + <D:prop> + <D:resourcetype><D:collection/></D:resourcetype> + </D:prop> + <D:status>HTTP/1.1 200 OK</D:status> + </D:propstat> + <D:propstat> + <D:prop><D:reftarget/></D:prop> + <D:status>HTTP/1.1 404 Not Found</D:status> + </D:propstat> + </D:response> + <D:response> + <D:href>/geog/stats.html</D:href> + <D:propstat> + <D:prop> + <D:resourcetype><D:redirectref/></D:resourcetype> + <D:reftarget> + <D:href>statistics/population/1997.html</D:href> + + + +Whitehead, et al. Experimental [Page 16] + +RFC 4437 WebDAV Redirect Reference Resources March 2006 + + + </D:reftarget> + </D:prop> + <D:status>HTTP/1.1 200 OK</D:status> + </D:propstat> + </D:response> + </D:multistatus> + + In this example, the relative reference + "statistics/population/1997.html" is returned as the value of the + DAV:reftarget property for the reference resource identified by href + /geog/stats.html. The href is itself a relative reference, which + resolves to http://example.com/geog/stats.html. This is the base URI + for resolving the relative reference in reftarget. The absolute URI + of reftarget is + http://example.com/geog/statistics/population/1997.html. + +11. Redirect References to Collections + + In a Request-URI /segment1/segment2/segment3, any of the three + segments may identify a redirect reference resource. (See [RFC3986], + Section 3.3, for definitions of "path" and "segment".) If any + segment in a Request-URI identifies a redirect reference resource, + the response SHOULD be a 3xx. The value of the Location header in + the response is as follows: + + The leftmost path segment of the Request-URI that identifies a + redirect reference resource, together with all path segments and + separators to the left of it, is replaced by the value of the + redirect reference resource's DAV:reftarget property (resolved to an + absolute URI). The remainder of the Request-URI is concatenated to + this path. + + Note: If the DAV:reftarget property ends with a "/" and the remainder + of the Request-URI is non-empty (and therefore must begin with a + "/"), the final "/" in the DAV:reftarget property is dropped before + the remainder of the Request-URI is appended. + + Consider Request-URI /x/y/z.html. Suppose that /x/ is a redirect + reference resource, whose target resource is collection /a/, which + contains redirect reference resource y whose target resource is + collection /b/, which contains redirect reference resource z.html, + whose target resource is /c/d.html. + + + + + + + + + +Whitehead, et al. Experimental [Page 17] + +RFC 4437 WebDAV Redirect Reference Resources March 2006 + + + /x/y/z.html + | + | /x -> /a + | + v + /a/y/z.html + | + | /a/y -> /b + | + v + /b/z.html + | + | /b/z.html -> /c/d.html + | + v + /c/d.html + + In this case, the client must follow up three separate 3xx responses + before finally reaching the target resource. The server responds to + the initial request with a 3xx with Location: /a/y/z.html, and the + client resubmits the request to /a/y/z.html. The server responds to + this request with a 3xx with Location: /b/z.html, and the client + resubmits the request to /b/z.html. The server responds to this + request with a 3xx with Location: /c/d.html, and the client resubmits + the request to /c/d.html. This final request succeeds. + + Note: The behaviour described above may have a very serious impact + on the efficiency of mapping Request-URIs to resources in HTTP + request processing. Therefore, servers MAY respond with a 404 + status code if the cost of checking all leading path segments for + redirect references seems prohibitive. + +12. Headers + +12.1. Redirect-Ref Response Header + + Redirect-Ref = "Redirect-Ref:" (URI | relative-ref) + ; URI: see [RFC3986], Section 3 + ; relative-ref: see [RFC3986], Section 4.2 + + The Redirect-Ref header is used in all 3xx responses from redirect + reference resources. The value is the link target as specified + during redirect reference resource creation. + + + + + + + + +Whitehead, et al. Experimental [Page 18] + +RFC 4437 WebDAV Redirect Reference Resources March 2006 + + +12.2. Apply-To-Redirect-Ref Request Header + + Apply-To-Redirect-Ref = "Apply-To-Redirect-Ref" ":" ("T" | "F") + + The optional Apply-To-Redirect-Ref header can be used on any request + to a redirect reference resource. When it is present and set to "T", + the request MUST be applied to the reference resource itself, and a + 3xx response MUST NOT be returned. + + If the Apply-To-Redirect-Ref header is used on a request to any other + sort of resource besides a redirect reference resource, the server + MUST ignore it. + +13. Redirect Reference Resource Properties + + The properties defined below are REQUIRED on redirect reference + resources. A PROPFIND/allprop request SHOULD NOT return any of the + properties defined in this document. + +13.1. DAV:redirect-lifetime (protected) + + This property provides information about the lifetime of a redirect. + It can be either DAV:permanent (HTTP status 301) or DAV:temporary + (HTTP status 302). Future protocols may define additional values. + + <!ELEMENT redirect-lifetime (permanent | temporary)> + <!ELEMENT permanent EMPTY> + <!ELEMENT temporary EMPTY> + +13.2. DAV:reftarget (protected) + + This property provides an efficient way for clients to discover the + URI of the target resource. This is a read-only property after its + initial creation. Its value can only be set in a MKREDIRECTREF + request. The value is a DAV:href element containing the URI of the + target resource. + + <!ELEMENT reftarget href > + +14. XML Elements + +14.1. redirectref XML Element + + Name: redirectref + + Namespace: DAV: + + + + + +Whitehead, et al. Experimental [Page 19] + +RFC 4437 WebDAV Redirect Reference Resources March 2006 + + + Purpose: Used as the value of the DAV:resourcetype property to + specify that the resource type is a redirect reference resource. + + <!ELEMENT redirectref EMPTY > + +15. Extensions to the DAV:response XML Element for Multi-Status + Responses + + As described in Section 8, the DAV:location element may be returned + in the DAV:response element of a 207 Multi-Status response, to allow + clients to resubmit their requests to the target resource of a + redirect reference resource. + + Consequently, the definition of the DAV:response XML element changes + to the following: + + <!ELEMENT response (href, ((href*, status)|(propstat+)), + responsedescription?, location?) > + <!ELEMENT location (href) > + +16. Capability Discovery + + Sections 9.1 and 15 of [RFC2518] describe the use of compliance + classes with the DAV header in responses to OPTIONS, to indicate + which parts of the WebDAV Distributed Authoring protocols the + resource supports. This specification defines an OPTIONAL extension + to [RFC2518]. It defines a new compliance class, called + redirectrefs, for use with the DAV header in responses to OPTIONS + requests. If a resource does support redirect references, its + response to an OPTIONS request may indicate that it does, by listing + the new redirectrefs compliance class in the DAV header and by + listing the MKREDIRECTREF method as one it supports. + + When responding to an OPTIONS request, any type of resource can + include redirectrefs in the value of the DAV header. Doing so + indicates that the server permits a redirect reference resource at + the Request-URI. + +16.1. Example: Discovery of Support for Redirect Reference Resources + + >> Request: + + OPTIONS /somecollection/someresource HTTP/1.1 + Host: example.org + + + + + + + +Whitehead, et al. Experimental [Page 20] + +RFC 4437 WebDAV Redirect Reference Resources March 2006 + + + >> Response: + + HTTP/1.1 200 OK + Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE + Allow: MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, MKREDIRECTREF + DAV: 1, 2, redirectrefs + + The DAV header in the response indicates that the resource + /somecollection/someresource is level 1 and level 2 compliant, as + defined in [RFC2518]. In addition, /somecollection/someresource + supports redirect reference resources. The Allow header indicates + that MKREDIRECTREF requests can be submitted to + /somecollection/someresource. + +17. Security Considerations + + This section is provided to make applications that implement this + protocol aware of the security implications of this protocol. + + All of the security considerations of HTTP/1.1 and the WebDAV + Distributed Authoring Protocol specification also apply to this + protocol specification. In addition, redirect reference resources + introduce several new security concerns and increase the risk of some + existing threats. These issues are detailed below. + +17.1. Privacy Concerns + + By creating redirect reference resources on a trusted server, it is + possible for a hostile agent to induce users to send private + information to a target on an unrelated system. This risk is + mitigated somewhat, since clients are required to notify the user of + the redirection for any request other than GET or HEAD. (See + [RFC2616], Section 10.3.3, 302 Found.) + +17.2. Redirect Loops + + Although redirect loops were already possible in HTTP 1.1, the + introduction of the MKREDIRECTREF method creates a new avenue for + clients to create loops accidentally or maliciously. If the + reference resource and its target are on the same server, the server + may be able to detect MKREDIRECTREF requests that would create loops. + See also [RFC2616], Section 10.3, "Redirection 3xx." + +17.3. Redirect Reference Resources and Denial of Service + + Denial of service attacks were already possible by posting URLs that + were intended for limited use at heavily used Web sites. The + introduction of MKREDIRECTREF creates a new avenue for similar denial + + + +Whitehead, et al. Experimental [Page 21] + +RFC 4437 WebDAV Redirect Reference Resources March 2006 + + + of service attacks. Clients can now create redirect reference + resources at heavily used sites to target locations that were not + designed for heavy usage. + +17.4. Revealing Private Locations + + There are several ways that redirect reference resources may reveal + information about collection structures. First, the DAV:reftarget + property of every redirect reference resource contains the URI of the + target resource. Anyone who has access to the reference resource can + discover the collection path that leads to the target resource. The + owner of the target resource may have wanted to limit knowledge of + this collection structure. + + Sufficiently powerful access control mechanisms can control this risk + to some extent. Property-level access control could prevent users + from examining the DAV:reftarget property. (The Location header + returned in responses to requests on redirect reference resources + reveals the same information, however.) + + This risk is no greater than the similar risk posed by HTML links. + +18. Internationalization Considerations + + All internationalization considerations mentioned in [RFC2518] also + apply to this document. + +19. IANA Considerations + + All IANA considerations mentioned in [RFC2518] also apply to this + document. + +19.1. HTTP headers + + This document specifies the two new HTTP headers listed below. + +19.1.1. Redirect-Ref + + Header field name: Redirect-Ref + + Applicable protocol: http + + Status: standard + + Author/Change controller: IETF + + Specification document: this specification (Section 12.1) + + + + +Whitehead, et al. Experimental [Page 22] + +RFC 4437 WebDAV Redirect Reference Resources March 2006 + + +19.1.2 Apply-To-Redirect-Ref + + Header field name: Apply-To-Redirect-Ref + + Applicable protocol: http + + Status: standard + + Author/Change controller: IETF + + Specification document: this specification (Section 12.2) + +20. Contributors + + Many thanks to Jason Crawford, Jim Davis, Chuck Fay, and Judith + Slein, who can take credit for big parts of the original design of + this specification. + +21. Acknowledgements + + This document has benefited from thoughtful discussion by Jim Amsden, + Peter Carlson, Steve Carter, Tyson Chihaya, Ken Coar, Ellis Cohen, + Bruce Cragun, Spencer Dawkins, Mark Day, Rajiv Dulepet, David Durand, + Lisa Dusseault, Stefan Eissing, Roy Fielding, Yaron Goland, Fred + Hitt, Alex Hopmann, James Hunt, Marcus Jager, Chris Kaler, Manoj + Kasichainula, Rohit Khare, Daniel LaLiberte, Steve Martin, Larry + Masinter, Jeff McAffer, Joe Orton, Surendra Koduru Reddy, Juergen + Reuter, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness, John + Stracke, John Tigue, John Turner, Kevin Wiggen, and others. + +22. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. + Jensen, "HTTP Extensions for Distributed Authoring -- + WEBDAV", RFC 2518, February 1999. + + [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., + Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext + Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. + + [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J. + Whitehead, "Versioning Extensions to WebDAV (Web + Distributed Authoring and Versioning)", RFC 3253, March + 2002. + + + + +Whitehead, et al. Experimental [Page 23] + +RFC 4437 WebDAV Redirect Reference Resources March 2006 + + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, RFC + 3986, January 2005. + +Authors' Addresses + + Jim Whitehead + UC Santa Cruz, Dept. of Computer Science + 1156 High Street + Santa Cruz, CA 95064 + US + + EMail: ejw@cse.ucsc.edu + + + Geoff Clemm + IBM + 20 Maguire Road + Lexington, MA 02421 + US + + EMail: geoffrey.clemm@us.ibm.com + + + Julian F. Reschke (editor) + greenbytes GmbH + Hafenweg 16 + Muenster, NW 48155 + Germany + + Phone: +49 251 2807760 + Fax: +49 251 2807761 + EMail: julian.reschke@greenbytes.de + URI: http://greenbytes.de/tech/webdav/ + + + + + + + + + + + + + + + + + +Whitehead, et al. Experimental [Page 24] + +RFC 4437 WebDAV Redirect Reference Resources March 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Whitehead, et al. Experimental [Page 25] + |