draft-ietf-webdav-redirectref-protocol-00.txt   draft-ietf-webdav-redirectref-protocol-01.txt 
WEBDAV Working Group J. Slein, Xerox WEBDAV Working Group J. Slein, Xerox
INTERNET DRAFT E.J. Whitehead Jr., UC Irvine INTERNET DRAFT E.J. Whitehead Jr., UC Irvine
<draft-ietf-webdav-redirectref-protocol-00.txt> J. Davis, CourseNet <draft-ietf-webdav-redirectref-protocol-01.txt> J. Davis, CourseNet
G. Clemm, Rational G. Clemm, Rational
C. Fay, FileNet C. Fay, FileNet
J. Crawford, IBM J. Crawford, IBM
T. Chihaya, DataChannel T. Chihaya, DataChannel
August 20, 1999 October 15, 1999
Expires February 20, 2000 Expires April 15, 2000
WebDAV Redirect Reference Resources WebDAV Redirect Reference Resources
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. Internet-Drafts are working provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working its working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
skipping to change at line 52 skipping to change at line 52
The WebDAV Distributed Authoring Protocol provides basic support for The WebDAV Distributed Authoring Protocol provides basic support for
collections, offering the ability to create and list unordered collections, offering the ability to create and list unordered
collections. collections.
This specification is one of a group of three specifications that This specification is one of a group of three specifications that
supplement the WebDAV Distributed Authoring Protocol to increase the supplement the WebDAV Distributed Authoring Protocol to increase the
power of WebDAV collections. This specification defines redirect power of WebDAV collections. This specification defines redirect
reference resources, one mechanism for allowing a single resource to reference resources, one mechanism for allowing a single resource to
appear in more than one collection. A redirect reference resource is a appear in more than one collection. A redirect reference resource is a
resource in one collection that responds to most requests by redirecting resource in one collection that responds to most requests by redirecting
the request (using an HTTP 1.1 302 Moved Temporarily response) to a the request (using an HTTP 1.1 302 Found response) to a different
different resource, possibly in a different collection. [B] defines resource, possibly in a different collection. "WebDAV Bindings"[B]
bindings, another approach to allowing a single resource to be accessed defines bindings, another approach to allowing a single resource to be
from multiple collections. [OC] provides ordered collections. accessed from multiple collections. "WebDAV Ordered Collections
Protocol"[OC] provides ordered collections.
Table of Contents Table of Contents
1 Notational Conventions.......................................3 1 Notational Conventions.......................................3
2 Introduction.................................................3
3 Terminology..................................................4 2 Introduction.................................................3
3 Terminology..................................................5
4 Overview of Redirect Reference Resources.....................5 4 Overview of Redirect Reference Resources.....................5
5 MKREF Method.................................................5 5 Creating a Redirect Reference Resource.......................6
5.1 Overview of MKREF............................................5 5.1 MKRESOURCE...................................................6
5.2 Status Codes.................................................6 5.2 Status Codes.................................................8
5.3 Example: MKREF...............................................6 5.3 Example: Creating a Redirect Reference Resource with
6 Listing the Redirect Reference Resources in a Collection.....6 MKRESOURCE...................................................8
6.1 Example: PROPFIND on a Collection with Redirect Reference 6 Operations on Redirect Reference Resources...................8
Resources....................................................7 6.1 Example: GET on a Redirect Reference Resource................9
6.2 Example: PROPFIND with Passthrough: F on a Collection with 6.2 Example: PUT on a Redirect Reference Resource with
Redirect Reference Resources.................................9 "Passthrough: F"............................................10
7 Copying Redirect Reference Resources........................10 6.3 Example: PROPPATCH on a Redirect Reference Resource.........10
7.1 Example: COPY on a Redirect Reference Resource..............11 7 Operations on Collections That Contain Redirect Reference
7.2 Example: COPY on a Collection That Contains a Redirect Resources...................................................11
Reference Resource..........................................11 7.1 MOVE and DELETE on Collections That Contain Redirect
8 Deleting and Moving Redirect Reference Resources............12 References..................................................12
9 Locking Redirect Reference Resources........................12 7.2 LOCK on a Collection That Contains Redirect References......12
9.1 Example: LOCK on a Redirect Reference Resource..............14 7.3 Example: PROPFIND on a Collection with Redirect Reference
9.2 Example: LOCK on a Collection That Contains a Redirect Resources...................................................12
Reference Resource, with Passthrough: T.....................15 7.4 Example: PROPFIND with Passthrough: F on a Collection with
10 Other Operations on Redirect Reference Resources............16 Redirect Reference Resources................................13
10.1 Example: GET on a Redirect Reference Resource...............17 7.5 Example: COPY on a Collection That Contains a Redirect
10.2 Example: PUT on a Redirect Reference Resource with Reference Resource..........................................15
"Passthrough: F"............................................18 7.6 Example: LOCK on a Collection That Contains a Redirect
10.3 Example: PROPPATCH on a Redirect Reference Resource.........18 Reference Resource, with Passthrough: T.....................16
11 Operations on Targets of Redirect Reference Resources.......19 8 Operations on Targets of Redirect Reference Resources.......17
12 Relative URIs in Ref-Target and DAV:reftarget...............19 9 Relative URIs in DAV:reftarget..............................17
12.1 Example: Resolving a Relative URI in Ref-Target.............19 9.1 Example: Resolving a Relative URI in a MKRESOURCE Request...18
12.2 Example: Resolving a Relative URI in DAV:reftarget..........20 9.2 Example: Resolving a Relative URI in a Multi-Status Response.18
13 Redirect References to Collections..........................21 10 Redirect References to Collections..........................19
14 Headers.....................................................21 11 Status Codes................................................20
14.1 Ref-Target Entity Header....................................21 11.1 509 Dangling References Forbidden...........................20
14.2 Resource-Type Entity Header.................................22 12 Headers.....................................................20
14.3 Passthrough Request Header..................................22 12.1 Redirect-Ref Response Header................................20
15 Properties..................................................22 12.2 Passthrough Request Header..................................20
15.1 reftarget Property..........................................22 13 Properties..................................................21
15.2 location Pseudo-Property....................................23 13.1 reftarget Property..........................................21
16 XML Elements................................................23 13.2 location Pseudo-Property....................................21
16.1 redirectref XML Element.....................................23 14 XML Elements................................................21
17 Extensions to the DAV:response XML Element for Multi-Status 14.1 redirectref XML Element.....................................21
Responses...................................................23 15 Extensions to the DAV:response XML Element for Multi-Status
18 Capability Discovery........................................23 Responses...................................................22
18.1 Example: Discovery of Support for Redirect Reference 16 Capability Discovery........................................22
Resources...................................................24 16.1 Example: Discovery of Support for Redirect Reference
19 Security Considerations.....................................24 Resources...................................................22
19.1 Privacy Concerns............................................24 17 Security Considerations.....................................23
19.2 Redirect Loops..............................................25 17.1 Privacy Concerns............................................23
19.3 Redirect Reference Resources and Denial of Service..........25 17.2 Redirect Loops..............................................23
19.4 Private Locations May Be Revealed...........................25 17.3 Redirect Reference Resources and Denial of Service..........23
20 Internationalization Considerations.........................25 17.4 Private Locations May Be Revealed...........................23
21 IANA Considerations.........................................26 18 Internationalization Considerations.........................24
22 Copyright...................................................26 19 IANA Considerations.........................................24
23 Intellectual Property.......................................26 20 Copyright...................................................24
24 Acknowledgements............................................26 21 Intellectual Property.......................................24
25 References..................................................26
26 Authors' Addresses..........................................27 22 Acknowledgements............................................25
27 Appendices..................................................28 23 References..................................................25
27.1 Appendix 1: Extensions to the WebDAV Document Type 24 Authors' Addresses..........................................25
Definition..................................................28 25 Appendices..................................................26
25.1 Appendix 1: Extensions to the WebDAV Document Type
Definition..................................................26
1 Notational Conventions 1 Notational Conventions
Since this document describes a set of extensions to the HTTP/1.1 Since this document describes a set of extensions to the WebDAV
protocol, the augmented BNF used here to describe protocol elements is Distributed Authoring Protocol [WebDAV], itself an extension to the
exactly the same as described in Section 2.1 of [HTTP]. Since this HTTP/1.1 protocol, the augmented BNF used here to describe protocol
augmented BNF uses the basic production rules provided in Section 2.2 of elements is exactly the same as described in Section 2.1 of [HTTP].
[HTTP], these rules apply to this document as well. Since this augmented BNF uses the basic production rules provided in
Section 2.2 of [HTTP], these rules apply to this document as well.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2 Introduction 2 Introduction
The simple collections that the WebDAV Distributed Authoring Protocol The simple collections that the WebDAV Distributed Authoring Protocol
specification supports are powerful enough to be widely useful. They specification supports are powerful enough to be widely useful. They
provide for the hierarchical organization of resources, with mechanisms provide for the hierarchical organization of resources, with mechanisms
for creating and deleting collections, copying and moving them, locking for creating and deleting collections, copying and moving them, locking
them, adding members to them and removing members from them, and getting them, adding members to them and removing members from them, and getting
listings of their members. Delete, copy, move, list, and lock listings of their members. Delete, copy, move, list, and lock
operations can be applied recursively, so that a client can operate on operations can be applied recursively, so that a client can operate on
whole hierarchies with a single request. whole hierarchies with a single request.
This specification is one of a family of three specifications that build This specification is one of a family of three specifications that build
on the infrastructure defined in [HTTP] and [WebDAV] to extend the on the infrastructure defined in [HTTP] and [WebDAV] to extend the
capabilities of collections. The companion specification [OC] defines capabilities of collections. The companion specification "WebDAV
protocol extensions to support ordered collections. The present Ordered Collections Protocol"[OC] defines protocol extensions to support
specification and the companion specification [B] define mechanisms for ordered collections. The present specification and the companion
allowing the same resource to appear in multiple collections. This specification "WebDAV Bindings"[B] define mechanisms for allowing the
capability is useful for several reasons: same resource to appear in multiple collections. This capability is
useful for several reasons:
Organizing resources into hierarchies places them into smaller Organizing resources into hierarchies places them into smaller
groupings, known as collections, which are more easily browsed and groupings, known as collections, which are more easily browsed and
manipulated than a flat namespace. However, hierarchies require manipulated than a flat namespace. However, hierarchies require
categorization decisions that locate resources at a single location in categorization decisions that locate resources at a single location in
the hierarchy, a drawback when a resource has multiple valid categories. the hierarchy, a drawback when a resource has multiple valid categories.
For example, in a hierarchy of vehicle descriptions containing For example, in a hierarchy of vehicle descriptions containing
collections for cars and boats, a description of a combination car/boat collections for cars and boats, a description of a combination car/boat
vehicle could belong in either collection. Ideally, the description vehicle could belong in either collection. Ideally, the description
should be accessible from both. should be accessible from both.
skipping to change at line 189 skipping to change at line 194
space, the BIND method also has the effect of adding the resource to a space, the BIND method also has the effect of adding the resource to a
collection. As new URIs are associated with the resource, it appears in collection. As new URIs are associated with the resource, it appears in
additional collections. additional collections.
The redirect reference resources defined here are a different mechanism The redirect reference resources defined here are a different mechanism
for allowing a single resource to appear in multiple collections. A for allowing a single resource to appear in multiple collections. A
redirect reference resource is a resource in one collection whose redirect reference resource is a resource in one collection whose
purpose is to forward requests to another resource (its target), usually purpose is to forward requests to another resource (its target), usually
in a different collection. In this way, it allows clients to submit in a different collection. In this way, it allows clients to submit
requests to the target resource from another collection. It redirects requests to the target resource from another collection. It redirects
most requests to the target resource using the HTTP 302 (Moved most requests to the target resource using the HTTP 302 (Found) status
Temporarily) status code, thereby providing a form of mediated access to code, thereby providing a form of mediated access to the target
the target resource. resource.
These two approaches to allowing clients to add a single resource to These two approaches to allowing clients to add a single resource to
multiple collections have very different characteristics: multiple collections have very different characteristics:
A redirect reference is a resource, and so can have properties of its A redirect reference is a resource, and so can have properties of its
own. Such information as who created the reference, when, and why can own. Such information as who created the reference, when, and why can
be stored on the redirect reference resource. Since redirect references be stored on the redirect reference resource. Since redirect references
are implemented using HTTP 302 responses, it generally takes two round are implemented using HTTP 302 responses, it generally takes two round
trips to submit a request to the intended resource. Servers are not trips to submit a request to the intended resource. Servers are not
required to enforce the integrity of redirect references. Redirect required to enforce the integrity of redirect references. Redirect
skipping to change at line 214 skipping to change at line 219
By contrast, a BIND request does not create a new resource, but simply By contrast, a BIND request does not create a new resource, but simply
makes available a new URI for submitting requests to an existing makes available a new URI for submitting requests to an existing
resource. The new URI can be used like any other URI to submit a resource. The new URI can be used like any other URI to submit a
request to a resource. Only one round trip is needed to submit a request to a resource. Only one round trip is needed to submit a
request to the intended target. Servers are required to enforce the request to the intended target. Servers are required to enforce the
integrity of the relationships between the new URIs clients create and integrity of the relationships between the new URIs clients create and
the resources associated with them. Consequently, it is unlikely that the resources associated with them. Consequently, it is unlikely that
servers will support BIND requests that cross server boundaries. servers will support BIND requests that cross server boundaries.
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
discusses how to create a redirect reference resource. Section 6
defines the semantics of existing methods when applied to redirect
reference resources, and Section 7 discusses their semantics when
applied to collections that contain redirect reference resources.
Sections 8 through 10 discuss several other issues raised by the
existence of redirect reference resources. Sections 11 through 15
define the new status codes, 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.
3 Terminology 3 Terminology
The terminology used here follows and extends that in the WebDAV The terminology used here follows and extends that in the WebDAV
Distributed Authoring Protocol specification [WebDAV]. Definitions of Distributed Authoring Protocol specification [WebDAV]. Definitions of
the terms resource, Uniform Resource Identifier (URI), and Uniform the terms resource, Uniform Resource Identifier (URI), and Uniform
Resource Locator (URL) are provided in [URI]. Resource Locator (URL) are provided in [URI].
Reference Resource Reference Resource
A resource whose purpose is to forward requests to another A resource whose purpose is to forward requests to another
resource. Reference resources are an alternative mechanism to resource. Reference resources are an alternative mechanism to
bindings (defined in [B]) for allowing clients to create multiple bindings (defined in [B]) for allowing clients to create multiple
URIs that can be used to submit requests to the same resource. URIs that can be used to submit requests to the same resource.
Redirect Reference Resource Redirect Reference Resource
A resource that forwards requests to another resource using the A resource that allows clients to forward requests to another
HTTP 1.1 302 (Moved Temporarily) response mechanism. The client resource using the HTTP 1.1 302 (Found) response mechanism. The
is aware that this type of reference resource is mediating between client is aware that this type of reference resource is mediating
it and the target resource. between it and the target resource.
Direct Reference Resource
Direct Reference Resources are out of scope for this
specification, but are defined here for contrast with redirect
reference resources. A direct reference resource automatically
forwards requests to another resource, in a way that is
transparent to the client.
Non-Reference Resource Non-Reference Resource
A resource that is not a reference to another resource. A resource that is not a reference to another resource.
Target Resource Target Resource
The resource to which requests are forwarded by a reference The resource to which requests are forwarded by a reference
resource. resource.
4 Overview of Redirect Reference Resources 4 Overview of Redirect Reference Resources
For most operations submitted to a redirect reference resource, the For all operations submitted to a redirect reference resource, the
response is a 302 (Moved Temporarily), accompanied by the Resource-Type default response is a 302 (Found), accompanied by the Redirect-Ref
header (defined in Section 14.2 below) set to "DAV:redirectref" and the header (defined in Section 12.1 below) and the Location header set to
Location header set to the URI of the target resource. With this the URI of the target resource. With this information, the client can
information, the client can resubmit the request to the URI of the resubmit the request to the URI of the target resource.
target resource. The methods COPY (for collections containing redirect
reference resources), DELETE, MOVE, and LOCK, for reasons that will be A redirect reference resource never automatically forwards requests to
explained, are exceptions to this general behavior. These exceptional its target resource. It is this characteristic that distinguishes
operations are applied to the reference resource itself and do not redirect reference resource from direct reference resources and from
result in a 302 response. bindings. It is also what insures that redirect reference resources
will be simple to implement and that cross-server references will be
possible. If the redirect reference resource were required to forward
requests automatically, the server would need proxy capabilities in
order to support cross-server references.
If the client is aware that it is operating on a redirect reference If the client is aware that it is operating on a redirect reference
resource, it can resolve the reference by retrieving the reference resource, it can resolve the reference by retrieving the reference
resource's DAV:reftarget property (defined in Section 15.1 below), whose resource's DAV:reftarget property (defined in Section 13.1 below), whose
value contains the URI of the target resource. It can then submit value contains the URI of the target resource. It can then submit
requests to the target resource. requests to the target resource.
A redirect reference resource is a new type of resource. To distinguish A redirect reference resource is a new type of resource. To distinguish
redirect reference resources from non-reference resources, a new value redirect reference resources from non-reference resources, a new value
of the DAV:resourcetype property (defined in [WebDAV]), DAV:redirectref, of the DAV:resourcetype property (defined in [WebDAV]), DAV:redirectref,
is defined in Section 16.1 below. is defined in Section 14.1 below.
Since a redirect reference resource is a resource, it is possible to Since a redirect reference resource is a resource, it is possible to
apply methods to the reference resource rather than to its target apply methods to the reference resource rather than to its target
resource. The Passthrough request header (defined in Section 14.3 resource. The Passthrough request header (defined in Section 12.2
below) is provided so that referencing-aware clients can control whether below) is provided so that referencing-aware clients can control whether
an operation is applied to the redirect reference resource or to its an operation is applied to the redirect reference resource or to its
target resource. The Passthrough header can be used with most requests target resource. The Passthrough header can be used with most requests
to redirect reference resources. This header is particularly useful to redirect reference resources. This header is particularly useful
with PROPFIND, to retrieve the reference resource's own properties. with PROPFIND, to retrieve the reference resource's own properties.
5 MKREF Method 5 Creating a Redirect Reference Resource
5.1 Overview of MKREF The MKRESOURCE method is used to create new redirect reference
resources. The values of two properties must be set in the body of the
MKRESOURCE request. The value of DAV:resourcetype MUST be set to
DAV:redirectref, a new value of DAV:resourcetype defined in Section
14.1. The value of DAV:reftarget MUST be set to the URI of the target
resource.
The MKREF method creates a redirect reference resource identified by the Used in this way, the MKRESOURCE method creates a redirect reference
Request-URI, whose target is identified by the REQUIRED Ref-Target resource whose target is identified by the DAV:reftarget property. It
header. MKREF sets the value of the REQUIRED DAV:reftarget property to creates a new binding between the new redirect reference resource and
the value of the Ref-Target header. the last path segment of the Request-URI. The new binding is added to
its parent collection, identified by the Request-URI minus its trailing
slash (if present) and final segment.
The MKREF method creates a new binding between the new redirect 5.1 MKRESOURCE
reference resource and the last path segment of the Request-URI. The The MKRESOURCE method requests the creation of a resource and
new binding is added to its parent collection, identified by the initialization of its properties. It allows resources other than
Request-URI minus its trailing slash (if present) and final segment. standard data containers and collections to be created and their
properties initialized in one atomic operation.
MKREF requests MAY include an entity body. This specification does not Preconditions:
define the action to be taken if a request entity body is present, but
allows it for extensibility.
By default, if the Request-URI of the MKREF request identifies an If the Overwrite header is not present or is set to 'F', a resource MUST
existing resource, the request MUST fail with a 405 (Method Not Allowed) NOT exist at the Request-URI.
response code. This default behavior can be overridden using the
Overwrite header defined in Section 9.6 of [WebDAV].
5.2 Status Codes Marshalling:
201 (Created): The redirect reference resource was successfully created. The location of the new resource to be created is specified by the
Request-URI. The Overwrite header MAY be specified. The request body
of the MKRESOURCE method is the same as the request body for PROPPATCH,
that is, it MUST contain the DAV:propertyupdate XML element defined in
Section 12.13 of [WebDAV].
400 (Bad Request): The client set an invalid value for the Ref-Target Semantics:
header.
405 (Method Not Allowed): A resource already exists at the Request-URI. Creation of the resource and initialization of its properties MUST both
occur, or neither occurs. Property initialization is carried out using
PROPPATCH semantics. The type of resource to create is specified by the
DAV:resourcetype property. If the DAV:resourcetype property is not
specified, the resource created will be a standard data container.
409 (Conflict): Several conditions may produce this response. There may If the Overwrite header is set to 'T' and MKRESOURCE is applied to an
be no resource at the location specified in Ref-Target, on a server that existing resource, the existing resource is deleted using DELETE
prohibits dangling reference resources. The request may be attempting semantics prior to MKRESOURCE processing. If deletion or resource
to create the reference resource in a collection that does not exist. creation cannot be completed, the entire operation fails and the
existing resource MUST be left unaffected. Since existing resources are
deleted, MKRESOURCE cannot be used to change the DAV:resourcetype of a
resource.
412 (Precondition Failed): The Overwrite header is "F" or absent, and a Postconditions:
resource already exists at the request-URI.
5.3 Example: MKREF After the successful execution of MKRESOURCE, a new resource exists.
The body of the new resource is empty, while the initial values of the
properties of the new resource are those specified in the property
update directives in the request body.
Response Marshalling:
Results from a MKRESOURCE request SHOULD NOT be cached, as MKRESOURCE
has non-idempotent semantics.
The following status codes can be expected in responses to MKRESOURCE:
201 (Created): The new resource was successfully created.
207 (Multi-Status): This response is generated if (1) the deletion of a
resource other than the one identified by the Request-URI could not be
completed, in which case the response is as defined in Section 8.6.2 of
[WebDAV], or (2) an error was encountered while initializing the
properties of the resource, in which case the response is as defined in
Section 8.2.1 of [WebDAV].
403 (Forbidden): The server does not allow the creation of the requested
resource type at the requested location, or the parent collection of the
Request-URI exists but cannot accept members.
409 (Conflict): A resource cannot be created at the Request-URI until
one or more intermediate collections have been created.
412 (Precondition Failed): The Overwrite header is not present or is set
to 'F', and a resource exists at the Request-URI.
423 (Locked): A locked resource exists at the Request-URI and the lock
token was not passed in with the request.
507 (Insufficient Storage): The server does not have sufficient space to
record the state of the resource.
5.2 Status Codes
In addition to the common status codes returned by MKRESOURCE, the
following special case can arise when creating a redirect reference
resource:
509 (Dangling References Forbidden): Some servers may have a policy that
forbids dangling references. These servers will respond with 509 if
there is no resource at the location specified in the DAV:reftarget
property.
5.3 Example: Creating a Redirect Reference Resource with MKRESOURCE
>> Request: >> Request:
MKREF /~whitehead/dav/spec08.ref HTTP/1.1 MKRESOURCE /~whitehead/dav/spec08.ref HTTP/1.1
Host: www.ics.uci.edu Host: www.ics.uci.edu
Ref-Target: </i-d/draft-webdav-protocol-08.txt> Content-Type: text/xml; charset="utf-8"
Content-Length: xxx
<?xml version="1.0" encoding="utf-8" ?>
<D:propertyupdate xmlns:D="DAV:">
<D:set>
<D:prop>
<D:resourcetype><D:redirectref/></D:resourcetype>
<D:reftarget>
<D:href>/i-d/draft-webdav-protocol-08.txt</D:href>
</D:reftarget>
</D:prop>
</D:set>
</D:propertyupdate>
>> Response: >> Response:
HTTP/1.1 201 Created HTTP/1.1 201 Created
This request resulted in the creation of a new redirect reference This request resulted in the creation of a new redirect reference
resource at www.ics.uci.edu/~whitehead/dav/spec08.ref, which points to resource at www.ics.uci.edu/~whitehead/dav/spec08.ref, which points to
the resource identified by the Ref-Target header. In this example, the the resource identified by the DAV:reftarget property. In this example,
target resource of the referential resource is identified by the URI the target resource is identified by the URI http://www.ics.uci.edu/i-
http://www.ics.uci.edu/~whitehead/dav/i-d/draft-webdav-protocol-08.txt. d/draft-webdav-protocol-08.txt. The redirect reference resource's
The referential resource's DAV:resourcetype property is set to DAV:resourcetype property is set to DAV:redirectref.
DAV:redirectref. Its DAV:reftarget property is set to the value of the
Ref-Target header, "/i-d/draft-webdav-protocol-08.txt".
6 Listing the Redirect Reference Resources in a Collection 6 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 302 (Found) status code, unless the request
includes a Passthrough header with a value of "F". The client and server
MUST follow [HTTP] Section 10.3.3 "302 Found," but with these additional
rules:
o The Location response header MUST contain the absolute target URI 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 understand the reason for the redirection.
A reference-aware WebDAV client can act on this response in one of two
ways. It 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 Passthrough header set to "F" in
order to operate on the reference resource itself. If the Passthrough
header is present with a value of "F", the request MUST be applied to
the reference resource itself, and a 302 response MUST NOT be returned.
A reference-aware client may know before submitting its request that the
Request-URI identifies a redirect reference resource. In this case, if
the client wants to apply the method to the reference resource, it can
save the round trip caused by the 302 response by using "Passthrough: F"
in its initial request to the URI.
A few methods need additional explanation:
"Passthrough: F" can be used with GET or HEAD to retrieve the entity
headers of a redirect reference resource. When "Passthrough: F" is used
with GET or HEAD, the Redirect-Ref entity header MUST be returned, along
with all HTTP headers that make sense for reference resources (for
example, Cache-Control, Age, ETag, Expires, and Last-Modified).
"Passthrough: F" can be used with PUT to replace the redirect reference
resource with a non-reference resource.
Clients MUST NOT use "Passthrough: F" with POST. Since a reference
resource cannot accept another entity as its subordinate, an attempt to
POST to a reference resource with "Passthrough: F" will also fail. If a
server receives a POST request with "Passthrough: F" on a redirect
reference resource, it MUST fail the request with a 400 (Bad Request)
status code.
Since MKCOL and MKRESOURCE fail when applied to existing resources, if
the client attempts to resubmit the request to the target resource, the
request MUST fail (unless the reference resource is a dangling
reference). Similarly, if the client attempts to resubmit the request
to the reference resource with "Passthrough: F", the request MUST fail.
Since ORDERPATCH applies only to collections, an ORDERPATCH request with
a Passthrough header with the value "F" on a redirect reference resource
MUST fail.
6.1 Example: GET on a Redirect Reference Resource
>> Request:
GET /bar.html HTTP/1.1
Host: www.foo.com
>> Response:
HTTP/1.1 302 Found
Location: http://www.svr.com/Internet/xxspec08.html
Redirect-Ref:
Since /bar.html is a redirect reference resource and the Passthrough
header is not included in the request, the response is a 302 (Found).
The Redirect-Ref header informs a reference-aware client that this is
not an ordinary HTTP 1.1 redirect, but is a redirect reference resource.
The URI of the target resource is provided in the Location header so
that the client can resubmit the request to the target resource.
6.2 Example: PUT on a Redirect Reference Resource with "Passthrough: F"
>> Request:
PUT /bar.html HTTP/1.1
Host: www.foo.com
Passthrough: F
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
. . . some content . . .
>> Response:
HTTP/1.1 200 OK
Although /bar.html is a redirect reference resource, the presence of the
"Passthrough: F" header prevents a 302 response, and instead causes the
request to be applied to the reference resource. The result in this
case is that the reference resource is replaced by a non-reference
resource having the content submitted with the request.
6.3 Example: PROPPATCH on a Redirect Reference Resource
>> Request:
PROPPATCH /bar.html HTTP/1.1
Host: www.foo.com
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
<?xml version="1.0" encoding="utf-8" ?>
<D:propertyupdate xmlns:D="DAV:"
xmlns:Z="http://www.w3.com/standards/z39.50/">
<D:set>
<D:prop>
<Z:authors>
<Z:Author>Jim Whitehead</Z:Author>
<Z:Author>Roy Fielding</Z:Author>
</Z:authors>
</D:prop>
</D:set>
<D:remove>
<D:prop><Z:Copyright-Owner/></D:prop>
</D:remove>
</D:propertyupdate>
>> Response:
HTTP/1.1 302 Found
Location: http://www.svr.com/Internet/xxspec08.html
Redirect-Ref:
Since /bar.html is a redirect reference resource and the Passthrough
header is not included in the request, the response is a 302 (Found).
The Redirect-Ref header informs a reference-aware client that this is
not an ordinary HTTP 1.1 redirect, but is a redirect reference resource.
The URI of the target resource is provided in the Location header so
that the client can resubmit the request to the target resource.
7 Operations on Collections That Contain Redirect Reference Resources
A URI of a redirect reference resource can be an internal member URI of A URI of a redirect reference resource can be an internal member URI of
a collection just as the URI of a non-reference resource can. A listing a collection just as the URI of a non-reference resource can. Any
operation on a collection with Depth: 1 or Depth: infinity applies to
redirect reference resources in the collection just as it applies to any
other resources in the collection. The methods that can accept a Depth
header are PROPFIND, COPY, MOVE, DELETE, and LOCK.
of the internal member URIs of a collection shows all of the URIs that Consistent with the rules in Section 6, the response for each redirect
are internal members of the collection, whether they identify redirect reference encountered while processing a collection MUST be a 302
reference resources or non-reference resources. That is, a WebDAV (Found) unless a Passthrough header with the value "F" is included with
PROPFIND request on a collection resource with the Depth header set to 1 the request. The overall response will therefore be a 207 (Multi-
or infinity MUST return a response XML element for each member URI in Status). Since a Location header and Redirect-Ref header cannot be
the collection, whether it identifies a non-reference resource or a returned for each redirect reference encountered, the same information
redirect reference resource. must be provided using properties in the response elements for those
resources. The DAV:location pseudo-property and the DAV:resourcetype
property MUST be included with the 302 status code. This necessitates
an extension to the syntax of the DAV:response element that was defined
in [WebDAV]. The extension is defined in Section 15 below.
For each redirect reference resource, the response element MUST contain A referencing-aware client can tell from the DAV:resourcetype property
a 302 (Moved Temporarily) status code unless a Passthrough header with
the value "F" is included with the PROPFIND request. The DAV:location
pseudo-property and the DAV:resourcetype property MUST be included with
the 302 status code, extending the syntax of the DAV:response element
that was defined in [WebDAV] as described in Section 17 below. A
referencing-aware client can tell from the DAV:resourcetype property
that the collection contains a redirect reference resource. The that the collection contains a redirect reference resource. The
DAV:location pseudo-property contains the absolute URI of the target DAV:location pseudo-property contains the absolute URI of the target
resource. A referencing-aware client can either use the URI value of resource. A referencing-aware client can either use the URI value of
the DAV:location pseudo-property to retrieve the properties of the the DAV:location pseudo-property to resubmit its request to the target
target resource, or it can submit a PROPFIND to the redirect reference resource, or it can submit the request to the redirect reference
resource with "Passthrough: F" to retrieve its properties. It is resource with "Passthrough: F".
recommended that future editors of [WebDAV] define the DAV:location
pseudo-property in [WebDAV], so that non-referencing clients will also
be able to use the response to retrieve the properties of the target
resource.
If the Depth header is set to infinity in the PROPFIND request, the It is recommended that future editors of [WebDAV] define the
server MUST NOT follow redirect reference resources into any collections DAV:location pseudo-property in [WebDAV], so that non-referencing
to which they may refer. clients will also be able to use the response to operate on the target
resource. (This will also enable clients to operate on traditional
HTTP/1.1 302 responses in Multi-Status responses.) Until then, non-
The Passthrough header (defined in Section 14.3) MAY be used with a referencing clients will not be able to process 302 responses from
PROPFIND request on a collection. redirect reference resources encountered while processing a collection.
6.1 Example: PROPFIND on a Collection with Redirect Reference Resources The Passthrough header (defined in Section 12.2) MAY be used with any
request on a collection. If present, it will be applied to all redirect
reference resources encountered while processing the collection.
7.1 MOVE and DELETE on Collections That Contain Redirect References
DELETE removes the binding that corresponds to the Request-URI. MOVE
removes that binding and creates a new binding to the same resource. In
cases where DELETE and MOVE are applied to a collection, these
operations affect all the descendents of the collection, but they do so
indirectly. There is no need to visit each descendent in order to
process the request. Consequently, even if there are redirect reference
resources in a tree that is being deleted or moved, there will be no 302
responses from the redirect reference resources.
7.2 LOCK on a Collection That Contains Redirect References
LOCK poses special problems because it is atomic. An attempt to lock
(with Depth: infinity) a collection that contains redirect references
will always fail. The Multi-Status response will contain a 302 response
for each redirect reference.
Reference-aware clients can lock the collection by using Passthrough: F,
and, if desired, lock the targets of the redirect references
individually.
Non-referencing clients must resort to locking each resource
individually.
7.3 Example: PROPFIND on a Collection with Redirect Reference Resources
Suppose a PROPFIND request with Depth = infinity is submitted to the Suppose a PROPFIND request with Depth = infinity is submitted to the
following collection, with the members shown here: following collection, with the members shown here:
http://www.svr.com/MyCollection/ http://www.svr.com/MyCollection/
(non-reference resource) diary.html (non-reference resource) diary.html
(redirect reference resource) nunavut (redirect reference resource) nunavut
>> Request: >> Request:
skipping to change at line 429 skipping to change at line 705
<D:propstat> <D:propstat>
<D:prop> <D:prop>
<D:resourcetype/> <D:resourcetype/>
<J:keywords>diary, travel, family, history</J:keywords> <J:keywords>diary, travel, family, history</J:keywords>
</D:prop> </D:prop>
<D:status>HTTP/1.1 200 OK</D:status> <D:status>HTTP/1.1 200 OK</D:status>
</D:propstat> </D:propstat>
</D:response> </D:response>
<D:response> <D:response>
<D:href>http://www.svr.com/MyCollection/nunavut</D:href> <D:href>http://www.svr.com/MyCollection/nunavut</D:href>
<D:status>HTTP/1.1 302 Moved Temporarily</D:status> <D:status>HTTP/1.1 302 Found</D:status>
<D:prop> <D:prop>
<D:location> <D:location>
<D:href>http://www.inac.gc.ca/art/inuit/</D:href> <D:href>http://www.inac.gc.ca/art/inuit/</D:href>
</D:location> </D:location>
<D:resourcetype><D:redirectref/></D:resourcetype> <D:resourcetype><D:redirectref/></D:resourcetype>
</D:prop> </D:prop>
</D:response> </D:response>
</D:multistatus> </D:multistatus>
In this example the Depth header is set to infinity, and the Passthrough In this example the Depth header is set to infinity, and the Passthrough
header is not used. The collection contains one URI that identifies a header is not used. The collection contains one URI that identifies a
redirect reference resource. The response element for the redirect redirect reference resource. The response element for the redirect
reference resource has a status of 302 (Moved Temporarily), and includes reference resource has a status of 302 (Found), and includes a DAV:prop
a DAV:prop element with the DAV:location pseudo-property and the element with the DAV:location pseudo-property and the DAV:resourcetype
DAV:resourcetype property to allow clients to retrieve the properties of property to allow clients to retrieve the properties of its target
its target resource. (The response element for the redirect reference resource. (The response element for the redirect reference resource
resource does not include the requested properties. The client can does not include the requested properties. The client can submit
submit another PROPFIND request to the URI in the DAV:location pseudo- another PROPFIND request to the URI in the DAV:location pseudo-property
property to retrieve those properties.) to retrieve those properties.)
7.4 Example: PROPFIND with Passthrough: F on a Collection with Redirect
6.2 Example: PROPFIND with Passthrough: F on a Collection with Redirect
Reference Resources Reference Resources
Suppose a PROPFIND request with Passthrough = F and Depth = infinity is Suppose a PROPFIND request with Passthrough = F and Depth = infinity is
submitted to the following collection, with the members shown here: submitted to the following collection, with the members shown here:
/MyCollection/ /MyCollection/
(non-reference resource) diary.html (non-reference resource) diary.html
(redirect reference resource) nunavut (redirect reference resource) nunavut
>> Request: >> Request:
skipping to change at line 531 skipping to change at line 808
</D:propstat> </D:propstat>
</D:response> </D:response>
</D:multistatus> </D:multistatus>
Since the Passthrough header has the value "F", the response shows the Since the Passthrough header has the value "F", the response shows the
properties of the redirect reference resource in the collection rather properties of the redirect reference resource in the collection rather
than the properties of its target. The value of the Passthrough header than the properties of its target. The value of the Passthrough header
also prevents a 302 response from being returned for the redirect also prevents a 302 response from being returned for the redirect
reference resource. reference resource.
7 Copying Redirect Reference Resources 7.5 Example: COPY on a Collection That Contains a Redirect Reference
A client's intent in performing a COPY operation is to create a new
resource that is similar to the original resource and behaves like the
original resource, and that can be modified without affecting the
original resource. For a COPY request to a redirect reference resource,
the expectation would be a 302 response that the client could use to
copy the target resource. This would yield an independent resource that
could be modified without affecting the original resource. For COPY
requests to collections that contain redirect reference resources, the
situation is less clear. There is tension between two expectations. On
the one hand, the client may expect the new copy of the collection to
behave like the old one (which implies having reference resources where
the old one had reference resources). On the other hand, the client may
expect that it will be possible to modify the resources in the new
collection without affecting the resources in the old collection (which
implies having copies of the target resources where the original
collection had reference resources).
For a COPY request on an individual reference resource, the response
MUST be a 302 (Moved Temporarily) status code, with the URI of the
target resource in the Location header, and "Resource-Type:
DAV:redirectref" to distinguish the response from an ordinary HTTP
redirect. This is the normal behavior for redirect reference resources,
allowing the client to resubmit the request to the target resource
identified in the Location header. This also yields intuitively correct
behavior for a COPY request to an individual reference resource.
Reference-aware clients can use the Passthrough header with the value
"F" to copy the redirect reference resource itself.
For COPY on a collection containing redirect reference resources,
different semantics may be desirable in different scenarios.
Consequently, this specification makes a fairly arbitrary choice to take
the simplest path. When a COPY request is submitted to a collection
containing redirect reference resources, the server MUST copy the
redirect reference resources to the new collection rather than returning
302 status codes for them. This will result in a new collection that
behaves like the old one, and avoids responding with multiple 302 status
codes, each of which the client would have to process separately.
Reference-aware clients can force the server to respond with 302 status
codes rather than copying the reference resources by using the
Passthrough header with the value "T".
7.1 Example: COPY on a Redirect Reference Resource
>> Request:
COPY /MyCollection/tuva HTTP/1.1
Host: www.svr.com
Destination: http://www.svr.com/OtherCollection/tuva.html
>> Response:
HTTP/1.1 302 Moved Temporarily
Location: http://www.svr.com/Asia/History/tuva.html
Resource-Type: DAV:redirectref
In this example, the request-URI identifies a redirect reference
resource whose target resource is identified by
http://www.svr.com/Asia/History/tuva.html. In this case, the server
responded with a 302, and provided the URL of the target resource in the
Location header. The Resource-Type header indicates to a reference-
aware client that this is not an HTTP 1.1 redirect, but a reference to
the resource identified by the Location header. The client can now
resubmit the COPY request to the target resource, producing the desired
result: a duplicate of the original target resource that can be modified
independently of the original.
7.2 Example: COPY on a Collection That Contains a Redirect Reference
Resource Resource
Suppose a COPY request is submitted to the following collection, with Suppose a COPY request is submitted to the following collection, with
the members shown: the members shown:
/MyCollection/ /MyCollection/
(non-reference resource) diary.html (non-reference resource) diary.html
(redirect reference resource) nunavut with target (redirect reference resource) nunavut with target
/Someplace/nunavut.map /Someplace/nunavut.map
>> Request: >> Request:
COPY /MyCollection/ HTTP/1.1 COPY /MyCollection/ HTTP/1.1
Host: www.svr.com Host: www.svr.com
Destination: http://www.svr.com/OtherCollection/ Destination: http://www.svr.com/OtherCollection/
>> Response: >> Response:
HTTP/1.1 201 Created HTTP/1.1 207 Multi-Status
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>http://www.svr.com/MyCollection/nunavut</D:href>
<D:status>HTTP/1.1 302 Found</D:status>
<D:prop>
<D:location>
<D:href>
http://www.svr.com//Someplace/nunavut.map
</D:href>
</D:location>
<D:resourcetype><D:redirectref/></D:resourcetype>
</D:prop>
</D:response>
</D:multistatus>
In this case, since /MyCollection/nunavut is a redirect reference In this case, since /MyCollection/nunavut is a redirect reference
resource, the reference resource itself, and not its target resource, resource, the COPY operation was only a partial success. The redirect
was copied into the new collection. So the resulting collection is as reference resource was not copied, but a 302 response was returned for
follows: it. So the resulting collection is as follows:
/OtherCollection/ /OtherCollection/
(non-reference resource) diary.html (non-reference resource) diary.html
(redirect reference resource) nunavut with target
/Someplace/nunavut.map
8 Deleting and Moving Redirect Reference Resources
The DELETE method is used to delete bindings to redirect reference
resources. DELETE MUST affect bindings to the reference resource itself,
unless "Passthrough: T" is used, in which case it generates a 302 (Moved
Temporarily) response. Similarly, when a DELETE on a collection
encounters a redirect reference resource in the subtree under that
collection, it MUST delete bindings to the reference resource, unless
"Passthrough: T" is used, in which case it generates a 302 (Moved
Temporarily) response. Whether deleting an individual resource or a
collection, DELETE on a redirect reference resource does not affect the
target of the reference resource.
A MOVE operation on a redirect reference resource MUST move the
reference resource to a different location, and MUST NOT change the
location of its target resource, unless "Passthrough: T" is used, in
which case a 302 (Moved Temporarily) response is generated. The
DAV:reftarget property is unchanged after a MOVE. Similarly, when a
MOVE on a collection encounters a redirect reference resource in the
subtree under that collection, it MUST move the reference resource, and
not its target, unless "Passthrough: T" is used, in which case a 302
(Moved Temporarily) response is generated.
DELETE and MOVE differ from other methods in that they do not alter the
resource that is being deleted or moved, but rather the collection that
contains its binding. They change the membership of that collection.
When a redirect reference resource is added to a collection, the aim is
to make it look as if the target resource were a member of that
collection. When the reference resource is removed from that
collection, the aim is to change the membership of that collection.
Membership of the target resource in any other collections, either
internally or by reference, should not be affected. Consequently,
DELETE and MOVE do not follow the normal rules of behavior for reference
resources. Instead, they are applied by default to the reference
resource itself, not to its target resource, and by default do not
result in 302 status codes.
9 Locking Redirect Reference Resources
The semantics of LOCK described here resulted from balancing a set of
incompatible considerations:
o Ideally, a LOCK on a redirect reference resource should lock both the
reference resource and its target resource. The owner of an
exclusive write lock, for example, would be surprised if anyone else
could modify the content of the target resource while he held the
lock. He would also be surprised if anyone else could delete the
reference to it, or replace the reference resource with one pointing
to a different target resource.
o Non-referencing clients should be able to use redirect reference
resources without encountering surprising results.
o The basic characteristics of redirect reference resources should be
honored. Redirect reference resources should be simple for servers
to implement. In particular, a server should never have to resolve a
redirect reference. A server should not have to provide proxy
capabilities in order to implement redirect references.
o There should be consistency between the behavior of LOCK on a single
redirect reference resource and the behavior of LOCK on a collection
that contains redirect reference resources.
o The behavior of all requests to redirect reference resources should
be as consistent as possible. In the absence of a Passthrough header,
all methods should return a 302 when sent to a redirect reference
resource.
o LOCK semantics for redirect reference resources should be consistent
with the LOCK semantics defined in [WebDAV].
We have compromised the intuitive locking behavior and support for non-
referencing clients in order to preserve various sorts of consistency.
The behavior of LOCK for redirect reference resources was determined by
what is possible for the case of locking collections that contain
redirect reference resources.
The default behavior for any operation on a redirect reference resource
is that a 302 (Moved Temporarily) response will be returned, unless the
Passthrough header with a value of "F" is used. However, this policy
has unacceptable consequences when locking a collection that contains
redirect reference resources. Since [WebDAV] requires LOCK on a
collection to be an atomic operation, if a 302 response is received for
any member of the collection, the entire LOCK must fail. This would
make it impossible to lock any collection that contained a redirect
reference resource.
To avoid this result, a LOCK with Depth > 0 on a collection MUST lock
any redirect reference resources it encounters, and not return 302
responses for them, unless the Passthrough header with a value of "T" is
used. Use of the Passthrough header with a value of "T" in a LOCK
request on a collection will cause the entire lock to fail if a redirect
reference resource is encountered.
This gives part of the expected default lock behavior without forcing
the server to resolve the redirect reference or become a proxy server in
cases where the target resides on a different server.
There will be no hint in any response code that there are redirect
reference resources whose targets need to be locked. The client will
most likely not lock any target resources until it attempts an operation
on the target resource and gets a 302 response. It is possible that a
non-referencing client may never realize that the reference resource's
target has not been locked.
Clearly, a LOCK with Depth = infinity on a collection MUST NOT follow
any redirect reference resources whose targets are collections into the
target collections; it MUST NOT cause any resources in those target
collections to be locked.
The behavior of LOCK for individual redirect reference resources is
designed to be consistent with LOCK behavior for collections that
contain redirect reference resources. By default a LOCK on a redirect
reference resource MUST lock only the reference resource, not its target
resource, and it MUST NOT return a 302 response. A reference-aware
client can use the Passthrough header with a value of "T" to get a 302
response with the URI of the target resource in the Location header.
UNLOCK behaves as specified in [WebDAV], unlocking all resources
included in the lock identified by the Lock-Token header.
9.1 Example: LOCK on a Redirect Reference Resource 7.6 Example: LOCK on a Collection That Contains a Redirect Reference
>> Request:
LOCK /MyCollection/tuva HTTP/1.1
Host: www.svr.com
Content-Type: text/xml
Content-Length: nnnn
Authorizaton: Digest username="jas",
realm=jas@webdav.sb.aol.com, nonce=". . . ",
uri="/MyCollection/tuva",
response=". . . ", opaque=". . . "
<?xml version="1.0" ?>
<D:lockinfo xmlns:D="DAV:">
<D:lockscope><D:exclusive/></D:lockscope>
<D:locktype><D:write/></D:locktype>
<D:owner>
<D:href>http://www.svr.com/~jas/contact.html</D:href>
</D:owner>
</D:lockinfo>
>> Response:
HTTP/1.1 200 OK
Content-Type: text/xml
Content-Length: nnnn
<?xml version="1.0" ?>
<D:prop xmlns:D="DAV:">
<D:lockdiscovery>
<D:activelock>
<D:lockscope><D:exclusive/></D:lockscope>
<D:locktype><D:write/></D:locktype>
<D:depth>0</D:depth>
<D:owner>
<D:href>http://www.svr.com/~jas/contact.html</D:href>
</D:owner>
<D:locktoken>
opaquelocktoken:e71dfae-5dec-22d6-fea5-00a0c91e6be4
</D:locktoken>
</D:activelock>
</D:lockdiscovery>
</D:prop>
The request and response look exactly as specified in [WebDAV]. In this
example, the request-URI, http://www.svr.com/MyCollection/tuva,
identifies a redirect reference resource, which was successfully locked.
The target resource of the redirect reference resource is not locked.
9.2 Example: LOCK on a Collection That Contains a Redirect Reference
Resource, with Passthrough: T Resource, with Passthrough: T
Suppose a LOCK request is submitted to the following collection, with Suppose a LOCK request is submitted to the following collection, with
the members shown: the members shown:
/MyCollection/ /MyCollection/
(non-reference resource) diary.html (non-reference resource) diary.html
(redirect reference resource) nunavut (redirect reference resource) nunavut
>> Request: >> Request:
skipping to change at line 850 skipping to change at line 908
<D:prop><D:lockdiscovery/></D:prop> <D:prop><D:lockdiscovery/></D:prop>
<D:status>HTTP/1.1 424 Failed Dependency</D:status> <D:status>HTTP/1.1 424 Failed Dependency</D:status>
</D:propstat> </D:propstat>
</D:response> </D:response>
<D:response> <D:response>
<D:href>http://www.svr.com/MyCollection/diary.html</D:href> <D:href>http://www.svr.com/MyCollection/diary.html</D:href>
<D:status>HTTP/1.1 424 Failed Dependency</D:status> <D:status>HTTP/1.1 424 Failed Dependency</D:status>
</D:response> </D:response>
<D:response> <D:response>
<D:href>http://www.svr.com/MyCollection/nunavut</D:href> <D:href>http://www.svr.com/MyCollection/nunavut</D:href>
<D:status>HTTP/1.1 302 Moved Temporarily</D:status> <D:status>HTTP/1.1 302 Found</D:status>
<D:prop> <D:prop>
<D:location> <D:location>
<D:href>http://www.inac.gc.ca/art/inuit/</D:href> <D:href>http://www.inac.gc.ca/art/inuit/</D:href>
</D:location> </D:location>
<D:resourcetype><D:redirectref/></D:resourcetype> <D:resourcetype><D:redirectref/></D:resourcetype>
</D:prop> </D:prop>
</D:response> </D:response>
</D:multistatus> </D:multistatus>
The "Passthrough: T" header caused the server to return a 302 response The "Passthrough: T" header caused the server to return a 302 response
code for the redirect reference resource in the collection. code for the redirect reference resource in the collection.
Consequently, neither the collection nor any of the resources identified Consequently, neither the collection nor any of the resources identified
by its internal member URIs were locked. A referencing-aware client can by its internal member URIs were locked. A referencing-aware client can
submit a separate LOCK request to the URI in the DAV:location pseudo- submit a separate LOCK request to the URI in the DAV:location pseudo-
property returned for the redirect reference resource, and can resubmit property returned for the redirect reference resource, and can resubmit
the LOCK request with "Passthrough: F" to the collection. At that point the LOCK request with "Passthrough: F" to the collection. At that point
both the reference resource and its target resource will be locked (as both the reference resource and its target resource will be locked (as
well as the collection and all the resources identified by its other well as the collection and all the resources identified by its other
members). members).
10 Other Operations on Redirect Reference Resources 8 Operations on Targets of 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 a GET, HEAD, PUT, POST, OPTIONS, PROPFIND,
PROPPATCH, MKCOL, MKREF, BIND, or ORDERPATCH request made via a redirect
reference resource MUST return a 302 (Moved Temporarily) status code.
The client and server MUST follow [HTTP] Section 10.3.3 "302 Moved
Temporarily," but with these additional rules:
o The Location response header MUST contain the absolute target URI of Operations on targets of redirect reference resources have no effect on
the reference resource. the reference resource.
o The response MUST include the Resource-Type header. This header 9 Relative URIs in DAV:reftarget
allows reference-aware WebDAV clients to recognize the resource as a
reference resource and understand the reason for the redirection.
A reference-aware WebDAV client can act on this response in one of two
ways. It 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 Passthrough header set to "F" in
order to operate on the reference resource itself. If the Passthrough
header is present with a value of "F", the request MUST be applied to
the reference resource itself, and a 302 response MUST NOT be returned.
If a reference-aware client knows before submitting its request that the
request-URI identifies a redirect reference resource, and if the client
wants to apply the method to the reference resource, it can save the
round trip caused by the 302 response by using "Passthrough: F" in its
initial request to the URI.
"Passthrough: F" can be used with GET or HEAD to retrieve the entity
headers of a redirect reference resource. When "Passthrough: F" is used
with GET or HEAD, the referencing entity headers (Ref-Type and Ref-
Target) MUST be returned, along with all HTTP headers that make sense
for reference resources (for example, Cache-Control, Age, ETag, Expires,
and Last-Modified).
"Passthrough: F" can be used with PUT to replace the redirect reference
resource with a non-reference resource. It can be used with OPTIONS to
retrieve the capabilities of a redirect reference resource.
Clients MUST NOT, however, use "Passthrough: F" with POST. Since a
reference resource cannot accept another entity as its subordinate, an
attempt to POST to a reference resource with "Passthrough: F" will also
fail. If a server receives a POST request with "Passthrough: F" on a
redirect reference resource, it MUST fail the request with a 400 (Bad
Request) status code.
Since MKCOL fails when applied to existing resources, if the client
attempts to resubmit the request to the target resource, the request
MUST fail (unless the reference resource is a dangling reference).
Similarly, if the client attempts to resubmit the request to the
reference resource with "Passthrough: F", the request MUST fail.
Since ORDERPATCH applies only to collections, an ORDERPATCH request with
a Passthrough header with the value "F" on a redirect reference resource
MUST fail.
10.1 Example: GET on a Redirect Reference Resource
>> Request:
GET /bar.html HTTP/1.1 The URI in the href in a DAV:reftarget property MAY be a relative URI.
Host: www.foo.com In this case, the base URI to be used for resolving the relative URI to
absolute form is the URI used in the HTTP message to identify the
redirect reference resource to which the DAV:reftarget property belongs.
>> Response: When DAV:reftarget occurs in the body of a MKRESOURCE request, the base
URI is constructed as follows: Its scheme component is "http", its
authority component is the value of the Host header in the request, and
its path component is the Request-URI in the request. See Section 5 of
[URI] for a discussion of relative URI references and how to resolve
them.
HTTP/1.1 302 Moved Temporarily When DAV:reftarget appears in the context of a Multi-Status response, it
Location: http://www.svr.com/Internet/xxspec08.html
Resource-Type: DAV:redirectref
Since /bar.html is a redirect reference resource and the Passthrough is in a DAV:response element that contains a single DAV:href element.
header is not included in the request, the response is a 302 (Moved The value of this DAV:href element serves as the base URI for resolving
Temporarily). The Resource-Type header informs a reference-aware client a relative URI in DAV:reftarget. The value of DAV:href may itself be
that this is not an ordinary HTTP 1.1 redirect, but is a redirect relative, in which case it must be resolved first in order to serve as
reference resource. The URI of the target resource is provided in the the base URI for the relative URI in DAV:reftarget. If the DAV:href
Location header so that the client can resubmit the request to the element is relative, its base URI is constructed from the scheme
target resource. component "http", the value of the Host header in the request, and the
request-URI.
10.2 Example: PUT on a Redirect Reference Resource with "Passthrough: F" 9.1 Example: Resolving a Relative URI in a MKRESOURCE Request
>> Request: >> Request:
PUT /bar.html HTTP/1.1 MKRESOURCE /north/inuvik HTTP/1.1
Host: www.foo.com Host: www.somehost.edu
Passthrough: F
Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx
. . . some content . . .
>> Response:
HTTP/1.1 200 OK
Although /bar.html is a redirect reference resource, the presence of the
"Passthrough: F" header prevents a 302 response, and instead causes the
request to be applied to the reference resource. The result in this
case is that the reference resource is replaced by a non-reference
resource having the content submitted with the request.
10.3 Example: PROPPATCH on a Redirect Reference Resource
Request:
PROPPATCH /bar.html HTTP/1.1
Host: www.foo.com
Content-Type: text/xml; charset="utf-8" Content-Type: text/xml; charset="utf-8"
Content-Length: xxxx Content-Length: xxx
<?xml version="1.0" encoding="utf-8" ?> <?xml version="1.0" encoding="utf-8" ?>
<D:propertyupdate xmlns:D="DAV:" <D:propertyupdate xmlns:D="DAV:">
xmlns:Z="http://www.w3.com/standards/z39.50/">
<D:set> <D:set>
<D:prop> <D:prop>
<Z:authors> <D:resourcetype><D:redirectref/></D:resourcetype>
<Z:Author>Jim Whitehead</Z:Author> <D:reftarget>
<Z:Author>Roy Fielding</Z:Author> <D:href>mapcollection/inuvik.gif</D:href>
</Z:authors> </D:reftarget>
</D:prop> </D:prop>
</D:set> </D:set>
<D:remove>
<D:prop><Z:Copyright-Owner/></D:prop>
</D:remove>
</D:propertyupdate> </D:propertyupdate>
Response:
HTTP/1.1 302 Moved Temporarily
Location: http://www.svr.com/Internet/xxspec08.html
Resource-Type: DAV:redirectref
Since /bar.html is a redirect reference resource and the Passthrough
header is not included in the request, the response is a 302 (Moved
Temporarily). The Resource-Type header informs a reference-aware client
that this is not an ordinary HTTP 1.1 redirect, but is a redirect
reference resource. The URI of the target resource is provided in the
Location header so that the client can resubmit the request to the
target resource.
11 Operations on Targets of Redirect Reference Resources
Operations on targets of redirect reference resources have no effect on
the reference resource.
12 Relative URIs in Ref-Target and DAV:reftarget
The URI in a Ref-Target header MAY be a relative URI. Similarly, the
href in a DAV:reftarget property MAY be a relative URI. In both cases,
the base URI to be used for resolving the relative URI to absolute form
is the URI used in the HTTP message to identify the redirect reference
resource to which the Ref-Target entity header or DAV:reftarget property
belongs.
In the case of a Ref-Target header, the base URI is constructed as
follows: Its scheme component is "http", its authority component is the
value of the Host header in the request, and its path component is the
request-URI in the request. See Section 5 of [URI] for a discussion of
relative URI references and how to resolve them.
The DAV:reftarget property appears in the protocol in the context of a
Multi-Status response, 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 URI 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 URI 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.
12.1 Example: Resolving a Relative URI in Ref-Target
>> Request:
MKREF /north/inuvik HTTP/1.1
Host: www.somehost.edu
Ref-Target: <mapcollection/inuvik.gif>
>> Response: >> Response:
HTTP/1.1 201 Created HTTP/1.1 201 Created
In this example, the base URI is http://www.somehost.edu/north/inuvik. In this example, the base URI is http://www.somehost.edu/north/inuvik.
Then, following the rules in [URI] Section 5, the relative URI in Ref- Then, following the rules in [URI] Section 5, the relative URI in
Target resolves to the absolute URI DAV:reftarget resolves to the absolute URI
http://www.somehost.edu/north/mapcollection/inuvik.gif. http://www.somehost.edu/north/mapcollection/inuvik.gif.
12.2 Example: Resolving a Relative URI in DAV:reftarget 9.2 Example: Resolving a Relative URI in a Multi-Status Response
>> Request: >> Request:
PROPFIND /geog/ HTTP/1.1 PROPFIND /geog/ HTTP/1.1
Host: www.xxsvr.com Host: www.xxsvr.com
Passthrough: F Passthrough: F
Depth: 1 Depth: 1
Content-Type: text/xml Content-Type: text/xml
Content-Length: nnn Content-Length: nnn
skipping to change at line 1122 skipping to change at line 1049
</D:response> </D:response>
</D:multistatus> </D:multistatus>
In this example, the relative URI statistics/population/1997.html is In this example, the relative URI statistics/population/1997.html is
returned as the value of reftarget for the reference resource identified returned as the value of reftarget for the reference resource identified
by href /geog/stats.html. The href is itself a relative URI, which by href /geog/stats.html. The href is itself a relative URI, which
resolves to http://www.xxsrv.com/geog/stats.html. This is the base URI resolves to http://www.xxsrv.com/geog/stats.html. This is the base URI
for resolving the relative URI in reftarget. The absolute URI of for resolving the relative URI in reftarget. The absolute URI of
reftarget is http://www.xxsrv.com/geog/statistics/population/1997.html. reftarget is http://www.xxsrv.com/geog/statistics/population/1997.html.
13 Redirect References to Collections 10 Redirect References to Collections
In a Request-URI /segment1/segment2/segment3, any of the three segments In a Request-URI /segment1/segment2/segment3, any of the three segments
may identify a redirect reference resource. (See [URI], Section 3.3, may identify a redirect reference resource. (See [URI], Section 3.3,
for definitions of "path" and "segment".) If any segment in a Request- for definitions of "path" and "segment".) If any segment in a Request-
URI identifies a redirect reference resource, the response is a 302. URI identifies a redirect reference resource, the response is a 302.
The value of the Location header in the 302 response is as follows: The value of the Location header in the 302 response is as follows:
The leftmost path segment of the request-URI that identifies a redirect The leftmost path segment of the request-URI that identifies a redirect
reference resource, together with all path segments and separators to reference resource, together with all path segments and separators to
the left of it, is replaced by the value of the redirect reference the left of it, is replaced by the value of the redirect reference
skipping to change at line 1160 skipping to change at line 1088
In this case the client must follow up three separate 302 responses In this case the client must follow up three separate 302 responses
before finally reaching the target resource. The server responds to the before finally reaching the target resource. The server responds to the
initial request with a 302 with Location: /a/y/z.html, and the client initial request with a 302 with Location: /a/y/z.html, and the client
resubmits the request to /a/y/z.html. The server responds to this resubmits the request to /a/y/z.html. The server responds to this
request with a 302 with Location: /b/z.html, and the client resubmits request with a 302 with Location: /b/z.html, and the client resubmits
the request to /b/z.html. The server responds to this request with a the request to /b/z.html. The server responds to this request with a
302 with Location: /c/d.html, and the client resubmits the request to 302 with Location: /c/d.html, and the client resubmits the request to
/c/d.html. This final request succeeds. /c/d.html. This final request succeeds.
14 Headers 11 Status Codes
14.1 Ref-Target Entity Header
Ref-Target = "Ref-Target" ":" Generic-Coded-url 11.1 509 Dangling References Forbidden
Generic-Coded-url = "<" (absoluteURI | relativeURI) ">" The server has a policy forbidding dangling references, and the request
absoluteURI is defined in Section 3 of [URI]. would have created a dangling reference. For example, if there is no
relativeURI is defined in Section 5 of [URI]. resource at the location specified by the DAV:reftarget property of a
MKRESOURCE request, the request would create a dangling reference.
The Ref-Target header is defined primarily for use with MKREF requests 12 Headers
to identify the target resource of the new redirect reference resource
being created.
14.2 Resource-Type Entity Header 12.1 Redirect-Ref Response Header
Resource-Type = "Resource-Type" ":" ("DAV:redirectref" | Redirect-Ref = "Redirect-Ref:"
ext-resource-type)
ext-resource-type = coded-URL
The Resource-Type header is defined primarily for use in 302 responses, The Redirect-Ref header is used in all 302 responses from redirect
to allow reference-aware clients to distinguish between HTTP 1.1 reference resources. Its presence informs reference-aware clients that
redirects and 302 responses for redirect reference resources. The the response is not a plain HTTP/1.1 redirect, but is a response from a
possible values of this header are DAV:redirectref, and ext-resource- redirect reference resource.
type. The ext-resource-type production is provided for extensibility.
14.3 Passthrough Request Header 12.2 Passthrough Request Header
Passthrough = "Passthrough" ":" ("T" | "F") Passthrough = "Passthrough" ":" ("T" | "F")
The optional Passthrough header can be used on any request to a redirect The optional Passthrough header can be used on any request to a redirect
reference resource. If the Passthrough header has the value "F", the reference resource. If the Passthrough header has the value "F", the
request MUST be applied to the reference resource itself, and a 302 request MUST be applied to the reference resource itself, and a 302
response MUST NOT be returned. If the Passthrough header has the value response MUST NOT be returned. If the Passthrough header has the value
"T", a 302 response MUST be returned, with the URI of the target "T", a 302 response MUST be returned, with the URI of the target
resource in the Location header and the Resource-Type header with a resource in the Location header and the Redirect-Ref header.
value "DAV:redirectref".
If the Passthrough header is used on a request to any other sort of If the Passthrough header is used on a request to any other sort of
resource besides a reference resource, the server SHOULD ignore it. If resource besides a reference resource, the server SHOULD ignore it. If
the Passthrough header with the value "F" appears in a POST or the Passthrough header with the value "F" appears in a POST or
ORDERPATCH request to a reference resource, the server MUST respond with ORDERPATCH request to a reference resource, the server MUST respond with
a 400 (Bad Request). a 400 (Bad Request).
15 Properties 13 Properties
15.1 reftarget Property 13.1 reftarget Property
Name: reftarget Name: reftarget
Namespace: DAV: Namespace: DAV:
Purpose: A property of redirect reference resources that provides an Purpose: A property of redirect reference resources that provides an
efficient way for clients to discover the URI of the target efficient way for clients to discover the URI of the target
resource. This is a read-only property, whose value can resource. This is a read-only property after its initial
only be set by using the Ref-Target header with a MKREF creation. Its value can only be set in a MKRESOURCE request.
request.
Value: href containing the URI of the target resource. This value Value: href containing the URI of the target resource. This value
MAY be a relative URI. The reftarget property can occur in MAY be a relative URI. The reftarget property can occur in
the entity bodies of responses to PROPFIND requests. the entity bodies of MKRESOURCE requests and of responses to
PROPFIND requests.
<!ELEMENT reftarget href > <!ELEMENT reftarget href >
15.2 location Pseudo-Property 13.2 location Pseudo-Property
Name: location Name: location
Namespace: DAV: Namespace: DAV:
Purpose: For use with 302 (Moved Temporarily) response codes in Purpose: For use with 302 (Found) response codes in Multi-Status
Multi-Status responses. It contains the absolute URI of the responses. It contains the absolute URI of the temporary
temporary location of the resource. In the context of location of the resource. In the context of redirect
redirect reference resources, this value is the absolute URI reference resources, this value is the absolute URI of the
of the target resource. It is analogous to the Location target resource. It is analogous to the Location header in
header in HTTP 302 responses defined in [HTTP] Section HTTP 302 responses defined in [HTTP] Section 10.3.3 "302
10.3.3 "302 Moved Temporarily." Including the location Found." Including the location pseudo-property in a Multi-
pseudo-property in a Multi-Status response requires an Status response requires an extension to the syntax of the
extension to the syntax of the DAV:response element defined DAV:response element defined in [WebDAV], which is defined
in [WebDAV], which is defined in Section 17 below. This in Section 15 below. This pseudo-property is not expected
pseudo-property is not expected to be stored on the to be stored on the reference resource. It is modeled as a
reference resource. It is modeled as a property only so that property only so that it can be returned inside a DAV:prop
it can be returned inside a DAV:prop element in a Multi- element in a Multi-Status response.
Status response.
Value: href containing the absolute URI of the target resource. Value: href containing the absolute URI of the target resource.
<!ELEMENT location href > <!ELEMENT location href >
16 XML Elements 14 XML Elements
16.1 redirectref XML Element 14.1 redirectref XML Element
Name: redirectref Name: redirectref
Namespace: DAV: Namespace: DAV:
Purpose: Used as the value of the DAV:resourcetype property to Purpose: Used as the value of the DAV:resourcetype property to
specify that the resource type is a redirect reference specify that the resource type is a redirect reference
resource. resource.
<!ELEMENT redirectref EMPTY > <!ELEMENT redirectref EMPTY >
17 Extensions to the DAV:response XML Element for Multi-Status Responses 15 Extensions to the DAV:response XML Element for Multi-Status Responses
As described in Sections 6 and 9, the DAV:location pseudo-property and As described in Sections 7 and 0, the DAV:location pseudo-property and
the DAV:reftype property may be returned in the DAV:response element of the DAV:reftype property may be returned in the DAV:response element of
a 207 Multi-Status response, to allow clients to resubmit their requests a 207 Multi-Status response, to allow clients to resubmit their requests
to the target resource of a redirect reference resource. to the target resource of a redirect reference resource.
Whenever these properties are included in a Multi-Status response, they Whenever these properties are included in a Multi-Status response, they
are placed in a DAV:prop element associated with the href to which they are placed in a DAV:prop element associated with the href to which they
apply. This structure provides a framework for future extensions by apply. This structure provides a framework for future extensions by
other standards that may need to include additional properties in their other standards that may need to include additional properties in their
responses. responses.
Consequently, the definition of the DAV:response XML element changes to Consequently, the definition of the DAV:response XML element changes to
the following: the following:
<!ELEMENT response (href, ((href*, status, prop?) | (propstat+)), <!ELEMENT response (href, ((href*, status, prop?) | (propstat+)),
responsedescription?) > responsedescription?) >
18 Capability Discovery 16 Capability Discovery
Sections 9.1 and 15 of [WebDAV] describe the use of compliance classes Sections 9.1 and 15 of [WebDAV] describe the use of compliance classes
with the DAV header in responses to OPTIONS, to indicate which parts of with the DAV header in responses to OPTIONS, to indicate which parts of
the Web Distributed Authoring protocols the resource supports. This the Web Distributed Authoring protocols the resource supports. This
specification defines an OPTIONAL extension to [WebDAV]. It defines a specification defines an OPTIONAL extension to [WebDAV]. It defines a
new compliance class, called redirectrefs, for use with the DAV header new compliance class, called redirectrefs, for use with the DAV header
in responses to OPTIONS requests. If a resource does support redirect in responses to OPTIONS requests. If a resource does support redirect
references, its response to an OPTIONS request MUST indicate that it references, its response to an OPTIONS request MUST indicate that it
does, by listing the new MKREF method as one it supports, and by listing does, by listing the new redirectrefs compliance class in the DAV
the new redirectrefs compliance class in the DAV header. header. It MUST also list the MKRESOURCE method as one it supports.
When responding to an OPTIONS request, any type of resource can include When responding to an OPTIONS request, any type of resource can include
redirectrefs in the value of the DAV header. Doing so indicates that redirectrefs in the value of the DAV header. Doing so indicates that
the server permits a redirect reference resource at the request URI. the server permits a redirect reference resource at the request URI.
18.1 Example: Discovery of Support for Redirect Reference Resources 16.1 Example: Discovery of Support for Redirect Reference Resources
>> Request: >> Request:
OPTIONS /somecollection/someresource HTTP/1.1 OPTIONS /somecollection/someresource HTTP/1.1
HOST: somehost.org HOST: somehost.org
>> Response: >> Response:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Date: Tue, 20 Jan 1998 20:52:29 GMT Date: Tue, 20 Jan 1998 20:52:29 GMT
Connection: close Connection: close
Accept-Ranges: none Accept-Ranges: none
Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE, MKCOL, Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE, MKCOL,
PROPFIND, PROPPATCH, LOCK, UNLOCK, MKREF PROPFIND, PROPPATCH, LOCK, UNLOCK, MKRESOURCE
Public: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE, MKCOL, Public: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE, MKCOL,
PROPFIND, PROPPATCH, LOCK, UNLOCK, BIND, MKREF, ORDERPATCH
PROPFIND, PROPPATCH, LOCK, UNLOCK, BIND, MKRESOURCE, ORDERPATCH
DAV: 1, 2, redirectrefs DAV: 1, 2, redirectrefs
The DAV header in the response indicates that the resource The DAV header in the response indicates that the resource
/somecollection/someresource is level 1 and level 2 compliant, as /somecollection/someresource is level 1 and level 2 compliant, as
defined in [WebDAV]. In addition, /somecollection/someresource supports defined in [WebDAV]. In addition, /somecollection/someresource supports
redirect reference resources. The Allow header indicates that MKREF redirect reference resources. The Allow header indicates that
requests can be submitted to /somecollection/someresource. The Public MKRESOURCE requests can be submitted to /somecollection/someresource.
header shows that other Request-URIs on the server support additional The Public header shows that other Request-URIs on the server support
methods. additional methods.
19 Security Considerations 17 Security Considerations
This section is provided to make WebDAV applications aware of the This section is provided to make WebDAV applications aware of the
security implications of this protocol. security implications of this protocol.
All of the security considerations of HTTP/1.1 and the WebDAV All of the security considerations of HTTP/1.1 and the WebDAV
Distributed Authoring Protocol specification also apply to this protocol Distributed Authoring Protocol specification also apply to this protocol
specification. In addition, redirect reference resources introduce specification. In addition, redirect reference resources introduce
several new security concerns and increase the risk of some existing several new security concerns and increase the risk of some existing
threats. These issues are detailed below. threats. These issues are detailed below.
19.1 Privacy Concerns 17.1 Privacy Concerns
By creating redirect reference resources on a trusted server, it is By creating redirect reference resources on a trusted server, it is
possible for a hostile agent to induce users to send private information possible for a hostile agent to induce users to send private information
to a target on a different server. This risk is mitigated somewhat, to a target on a different server. This risk is mitigated somewhat,
since clients are required to notify the user of the redirection for any since clients are required to notify the user of the redirection for any
request other than GET or HEAD. (See [HTTP], Section 10.3.3 Moved request other than GET or HEAD. (See [HTTP], Section 10.3.3 302 Found.)
Temporarily.)
19.2 Redirect Loops 17.2 Redirect Loops
Although redirect loops were already possible in HTTP 1.1, the Although redirect loops were already possible in HTTP 1.1, the
introduction of the MKREF method creates a new avenue for clients to introduction of the MKRESOURCE method creates a new avenue for clients
create loops accidentally or maliciously. If the reference resource and to create loops accidentally or maliciously. If the reference resource
its target are on the same server, the server may be able to detect and its target are on the same server, the server may be able to detect
MKREF requests that would create loops. See also [HTTP], Section 10.3 MKRESOURCE requests that would create loops. See also [HTTP], Section
"Redirection 3xx." 10.3 "Redirection 3xx."
19.3 Redirect Reference Resources and Denial of Service 17.3 Redirect Reference Resources and Denial of Service
Denial of service attacks were already possible by posting URLs that Denial of service attacks were already possible by posting URLs that
were intended for limited use at heavily used Web sites. The were intended for limited use at heavily used Web sites. The
introduction of MKREF creates a new avenue for similar denial of service introduction of MKRESOURCE creates a new avenue for similar denial of
attacks. Clients can now create redirect reference resources at heavily service attacks. Clients can now create redirect reference resources at
used sites to target locations that were not designed for heavy usage. heavily used sites to target locations that were not designed for heavy
usage.
19.4 Private Locations May Be Revealed 17.4 Private Locations May Be Revealed
There are several ways that redirect reference resources may reveal There are several ways that redirect reference resources may reveal
information about directory structures. First, the DAV:reftarget information about directory structures. First, the DAV:reftarget
property of every redirect reference resource contains the URI of the property of every redirect reference resource contains the URI of the
target resource. Anyone who has access to the reference resource can target resource. Anyone who has access to the reference resource can
discover the directory path that leads to the target resource. The discover the directory path that leads to the target resource. The
owner of the target resource may have wanted to limit knowledge of this owner of the target resource may have wanted to limit knowledge of this
directory structure. directory structure.
Sufficiently powerful access control mechanisms can control this risk to Sufficiently powerful access control mechanisms can control this risk to
some extent. Property-level access control could prevent users from some extent. Property-level access control could prevent users from
examining the DAV:reftarget property. (The Ref-Target and Location examining the DAV:reftarget property. (The Location header returned in
headers, which are returned in some responses to requests on redirect responses to requests on redirect reference resources reveals the same
reference resources, reveal the same information, however.) In some information, however.) In some environments, the owner of a resource
environments, the owner of a resource might be able to use access might be able to use access control to prevent others from creating
control to prevent others from creating references to that resource. references to that resource.
20 Internationalization Considerations 18 Internationalization Considerations
This specification follows the practices of [WebDAV] in encoding all This specification follows the practices of [WebDAV] in encoding all
human-readable content using XML [XML] and in the treatment of names. human-readable content using XML [XML] and in the treatment of names.
Consequently, this specification complies with the IETF Character Set Consequently, this specification complies with the IETF Character Set
Policy [Alvestrand]. Policy [Alvestrand].
WebDAV applications MUST support the character set tagging, character WebDAV applications MUST support the character set tagging, character
set encoding, and the language tagging functionality of the XML set encoding, and the language tagging functionality of the XML
specification. This constraint ensures that the human-readable content specification. This constraint ensures that the human-readable content
of this specification complies with [Alvestrand]. of this specification complies with [Alvestrand].
skipping to change at line 1402 skipping to change at line 1323
For error reporting, [WebDAV] follows the convention of HTTP/1.1 status For error reporting, [WebDAV] follows the convention of HTTP/1.1 status
codes, including with each status code a short, English description of codes, including with each status code a short, English description of
the code (e.g., 423 Locked). Internationalized applications will ignore the code (e.g., 423 Locked). Internationalized applications will ignore
this message, and display an appropriate message in the user's language this message, and display an appropriate message in the user's language
and character set. and character set.
For rationales for these decisions and advice for application For rationales for these decisions and advice for application
implementors, see [WebDAV]. implementors, see [WebDAV].
21 IANA Considerations 19 IANA Considerations
This document uses the namespaces defined by [WebDAV] for properties and This document uses the namespaces defined by [WebDAV] for properties and
XML elements. All other IANA considerations mentioned in [WebDAV] also XML elements. All other IANA considerations mentioned in [WebDAV] also
apply to this document. apply to this document.
22 Copyright In addition, this document defines a new HTTP/1.1 status code, 509
(Dangling References Forbidden) defined in Section 11.1.
20 Copyright
To be supplied by the RFC Editor. To be supplied by the RFC Editor.
23 Intellectual Property 21 Intellectual Property
To be supplied by the RFC Editor. To be supplied by the RFC Editor.
24 Acknowledgements 22 Acknowledgements
This draft has benefited from thoughtful discussion by Jim Amsden, Steve This draft has benefited from thoughtful discussion by Jim Amsden, Steve
Carter, Ken Coar, Ellis Cohen, Bruce Cragun, Spencer Dawkins, Mark Day, Carter, Ken Coar, Ellis Cohen, Bruce Cragun, Spencer Dawkins, Mark Day,
Rajiv Dulepet, David Durand, Roy Fielding, Yaron Goland, Fred Hitt, Alex Rajiv Dulepet, David Durand, Roy Fielding, Yaron Goland, Fred Hitt, Alex
Hopmann, Marcus Jager, Chris Kaler, Manoj Kasichainula, Rohit Khare, Hopmann, Marcus Jager, Chris Kaler, Manoj Kasichainula, Rohit Khare,
Daniel LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Surendra Daniel LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Surendra
Koduru Reddy, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness, John Koduru Reddy, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness, John
Stracke, John Tigue, John Turner, and others. Stracke, John Tigue, John Turner, and others.
25 References 23 References
[URI] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource [URI] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax." RFC 2396. MIT/LCS, U.C. Irvine, Identifiers (URI): Generic Syntax." RFC 2396. MIT/LCS, U.C. Irvine,
Xerox. August, 1998. Xerox. August, 1998.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels." RFC 2119, BCP 14. Harvard University. March, 1997. Levels." RFC 2119, BCP 14. Harvard University. March, 1997.
[XML] T. Bray, J. Paoli, C.M. Sperberg-McQueen, "Extensible Markup [XML] T. Bray, J. Paoli, C.M. Sperberg-McQueen, "Extensible Markup
Language (XML)." World Wide Web Consortium Recommendation REC-xml- Language (XML)." World Wide Web Consortium Recommendation REC-xml-
skipping to change at line 1457 skipping to change at line 1381
[B] J. Slein, E.J. Whitehead Jr., J. Davis, G. Clemm, C. Fay, J. [B] J. Slein, E.J. Whitehead Jr., J. Davis, G. Clemm, C. Fay, J.
Crawford, T. Chihaya, "WebDAV Bindings." Internet Draft (work in Crawford, T. Chihaya, "WebDAV Bindings." Internet Draft (work in
progress) draft-ietf-webdav-binding-protocol-00. Xerox, UC Irvine, progress) draft-ietf-webdav-binding-protocol-00. Xerox, UC Irvine,
CourseNet, Rational, FileNet, IBM, DataChannel. August, 1999. CourseNet, Rational, FileNet, IBM, DataChannel. August, 1999.
[OC] J. Slein, E.J. Whitehead Jr., J. Davis, G. Clemm, C. Fay, J. [OC] J. Slein, E.J. Whitehead Jr., J. Davis, G. Clemm, C. Fay, J.
Crawford, T. Chihaya, "WebDAV Ordered Collections." Internet Draft (work Crawford, T. Chihaya, "WebDAV Ordered Collections." Internet Draft (work
in progress) draft-ietf-webdav-ordering-protocol-00. Xerox, UC Irvine, in progress) draft-ietf-webdav-ordering-protocol-00. Xerox, UC Irvine,
CourseNet, Rational, FileNet, IBM, DataChannel. August, 1999. CourseNet, Rational, FileNet, IBM, DataChannel. August, 1999.
26 Authors' Addresses 24 Authors' Addresses
J. Slein J. Slein
Xerox Corporation Xerox Corporation
800 Phillips Road, 105-50C 800 Phillips Road, 105-50C
Webster, NY 14580 Webster, NY 14580
Email: jslein@crt.xerox.com Email: jslein@crt.xerox.com
E. J. Whitehead, Jr. E. J. Whitehead, Jr.
Dept. of Information and Computer Science Dept. of Information and Computer Science
University of California, Irvine University of California, Irvine
skipping to change at line 1499 skipping to change at line 1423
J. Crawford J. Crawford
IBM IBM
Email: ccjason@us.ibm.com Email: ccjason@us.ibm.com
T. Chihaya T. Chihaya
DataChannel, Inc. DataChannel, Inc.
155 108th Ave. N.E., Suite 400 155 108th Ave. N.E., Suite 400
Bellevue, WA 98004 Bellevue, WA 98004
Email: Tyson@DataChannel.com Email: Tyson@DataChannel.com
27 Appendices 25 Appendices
27.1 Appendix 1: Extensions to the WebDAV Document Type Definition 25.1 Appendix 1: Extensions to the WebDAV Document Type Definition
<!--============= XML Elements from Section 16 ================--> <!--============= XML Elements from Section 14 ================-->
<!ELEMENT redirectref EMPTY > <!ELEMENT redirectref EMPTY >
<!--============= Property Elements from Section 15 =================--> <!--============= Property Elements from Section 13 =================-->
<!ELEMENT reftarget href> <!ELEMENT reftarget href>
<!ELEMENT location href> <!ELEMENT location href>
<!--====== Changes to the DAV:response Element from Section 17 ====--> <!--====== Changes to the DAV:response Element from Section 15 ====-->
<!ELEMENT response (href, ((href*, status, prop?) | (propstat+)), <!ELEMENT response (href, ((href*, status, prop?) | (propstat+)),
responsedescription?) > responsedescription?) >
Expires February 20, 2000 Expires April 15, 2000
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/