idnits 2.17.1
draft-ietf-webdav-redirectref-protocol-03.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Looks like you're using RFC 2026 boilerplate. This must be updated to
follow RFC 3978/3979, as updated by RFC 4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The abstract seems to contain references ([2], [B], [1]), which it
shouldn't. Please replace those with straight textual mentions of the
documents in question.
== There are 13 instances of lines with non-RFC2606-compliant FQDNs in the
document.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (July 25, 2003) is 7575 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: 'WebDAV' is mentioned on line 2908, but not defined
** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986)
** Obsolete normative reference: RFC 2518 (Obsoleted by RFC 4918)
** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231,
RFC 7232, RFC 7233, RFC 7234, RFC 7235)
-- Possible downref: Non-RFC (?) normative reference: ref. 'XML'
== Outdated reference: A later version (-27) exists of
draft-ietf-webdav-bind-02
Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 WEBDAV Working Group J. Slein
3 Internet-Draft Xerox
4 Expires: January 23, 2004 J. Whitehead
5 U.C. Santa Cruz
6 J. Davis
7 CourseNet
8 G. Clemm
9 Rational
10 C. Fay
11 FileNet
12 J. Crawford
13 IBM
14 J. Reschke, Ed.
15 greenbytes
16 July 25, 2003
18 WebDAV Redirect Reference Resources
19 draft-ietf-webdav-redirectref-protocol-03.txt
21 Status of this Memo
23 This document is an Internet-Draft and is in full conformance with
24 all provisions of Section 10 of RFC2026.
26 Internet-Drafts are working documents of the Internet Engineering
27 Task Force (IETF), its areas, and its working groups. Note that other
28 groups may also distribute working documents as Internet-Drafts.
30 Internet-Drafts are draft documents valid for a maximum of six months
31 and may be updated, replaced, or obsoleted by other documents at any
32 time. It is inappropriate to use Internet-Drafts as reference
33 material or to cite them other than as "work in progress."
35 The list of current Internet-Drafts can be accessed at http://
36 www.ietf.org/ietf/1id-abstracts.txt.
38 The list of Internet-Draft Shadow Directories can be accessed at
39 http://www.ietf.org/shadow.html.
41 This Internet-Draft will expire on January 23, 2004.
43 Copyright Notice
45 Copyright (C) The Internet Society (2003). All Rights Reserved.
47 Abstract
49 This is one of a pair of specifications that extend the WebDAV
50 Distributed Authoring Protocol to enable clients to create new access
51 paths to existing resources. The two protocol extensions have very
52 different characteristics that make them useful for different sorts
53 of applications.
55 The present specification defines redirect reference resources. A
56 redirect reference resource is a resource whose default response is
57 an HTTP/1.1 302 (Found) status code, redirecting the client to a
58 different resource, the target resource. A redirect reference makes
59 it possible to access the target resource indirectly, through any URI
60 mapped to the redirect reference resource. There are no integrity
61 guarantees associated with redirect reference resources.
63 The related specification [B], defines bindings, and the BIND method
64 for creating them. Creating a new binding to a resource indirectly
65 creates one or more new URIs mapped to that resource, which can then
66 be used to access it. Servers are required to insure the integrity
67 of any bindings that they allow to be created.
69 Distribution of this document is unlimited. Please send comments to
70 the Distributed Authoring and Versioning (WebDAV) working group at
71 w3c-dist-auth@w3.org [1], which may be joined by sending a message
72 with subject "subscribe" to w3c-dist-auth-request@w3.org [2].
74 Discussions of the WEBDAV working group are archived at URL: http://
75 lists.w3.org/Archives/Public/w3c-dist-auth/.
77 Table of Contents
79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7
80 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 9
81 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 10
82 4. Overview of Redirect Reference Resources . . . . . . . . . . 11
83 5. Creating a Redirect Reference Resource . . . . . . . . . . . 12
84 5.1 MKRESOURCE . . . . . . . . . . . . . . . . . . . . . . . . . 12
85 5.2 Example: Creating a Redirect Reference Resource with
86 MKRESOURCE . . . . . . . . . . . . . . . . . . . . . . . . . 13
87 6. Operations on Redirect Reference Resources . . . . . . . . . 15
88 6.1 Example: GET on a Redirect Reference Resource . . . . . . . 16
89 6.2 Example: PUT on a Redirect Reference Resource with
90 Apply-To-Redirect-Ref . . . . . . . . . . . . . . . . . . . 16
91 6.3 Example: PROPPATCH on a Redirect Reference Resource . . . . 17
92 7. Operations on Collections That Contain Redirect Reference
93 Resources . . . . . . . . . . . . . . . . . . . . . . . . . 18
94 7.1 MOVE and DELETE on Collections That Contain Redirect
95 References . . . . . . . . . . . . . . . . . . . . . . . . . 18
96 7.2 LOCK on a Collection That Contains Redirect References . . . 19
97 7.3 Example: PROPFIND on a Collection with Redirect Reference
98 Resources . . . . . . . . . . . . . . . . . . . . . . . . . 19
99 7.4 Example: PROPFIND with Apply-To-Redirect-Ref on a
100 Collection with Redirect Reference Resources . . . . . . . . 20
101 7.5 Example: COPY on a Collection That Contains a Redirect
102 Reference Resource . . . . . . . . . . . . . . . . . . . . . 22
103 7.6 Example: LOCK on a Collection That Contains a Redirect
104 Reference Resource . . . . . . . . . . . . . . . . . . . . . 23
105 8. Operations on Targets of Redirect Reference Resources . . . 26
106 9. Relative URIs in DAV:reftarget . . . . . . . . . . . . . . . 27
107 9.1 Example: Resolving a Relative URI in a MKRESOURCE Request . 27
108 9.2 Example: Resolving a Relative URI in a Multi-Status
109 Response . . . . . . . . . . . . . . . . . . . . . . . . . . 28
110 10. Redirect References to Collections . . . . . . . . . . . . . 30
111 11. Headers . . . . . . . . . . . . . . . . . . . . . . . . . . 32
112 11.1 Redirect-Ref Response Header . . . . . . . . . . . . . . . . 32
113 11.2 Apply-To-Redirect-Ref Request Header . . . . . . . . . . . . 32
114 12. Properties . . . . . . . . . . . . . . . . . . . . . . . . . 33
115 12.1 reftarget Property . . . . . . . . . . . . . . . . . . . . . 33
116 12.2 location Pseudo-Property . . . . . . . . . . . . . . . . . . 33
117 13. XML Elements . . . . . . . . . . . . . . . . . . . . . . . . 34
118 13.1 redirectref XML Element . . . . . . . . . . . . . . . . . . 34
119 14. Extensions to the DAV:response XML Element for
120 Multi-Status Responses . . . . . . . . . . . . . . . . . . . 35
121 15. Capability Discovery . . . . . . . . . . . . . . . . . . . . 36
122 15.1 Example: Discovery of Support for Redirect Reference
123 Resources . . . . . . . . . . . . . . . . . . . . . . . . . 36
124 16. Security Considerations . . . . . . . . . . . . . . . . . . 37
125 16.1 Privacy Concerns . . . . . . . . . . . . . . . . . . . . . . 37
126 16.2 Redirect Loops . . . . . . . . . . . . . . . . . . . . . . . 37
127 16.3 Redirect Reference Resources and Denial of Service . . . . . 37
128 16.4 Revealing Private Locations . . . . . . . . . . . . . . . . 37
129 17. Internationalization Considerations . . . . . . . . . . . . 39
130 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . 40
131 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41
132 Normative References . . . . . . . . . . . . . . . . . . . . 42
133 Informative References . . . . . . . . . . . . . . . . . . . 43
134 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 44
135 A. Changes to the WebDAV Document Type Definition . . . . . . . 46
136 B. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 47
137 B.1 Since draft-ietf-webdav-redirectref-protocol-02 . . . . . . 47
138 C. Resolved issues . . . . . . . . . . . . . . . . . . . . . . 48
139 C.1 lc-11-pagination . . . . . . . . . . . . . . . . . . . . . . 48
140 C.2 lc-09-notational-after-introduction . . . . . . . . . . . . 48
141 C.3 lc-13-usually . . . . . . . . . . . . . . . . . . . . . . . 48
142 C.4 lc-16-insure . . . . . . . . . . . . . . . . . . . . . . . . 48
143 C.5 lc-17-location . . . . . . . . . . . . . . . . . . . . . . . 49
144 C.6 lc-21-bind . . . . . . . . . . . . . . . . . . . . . . . . . 49
145 C.7 lc-46-bind . . . . . . . . . . . . . . . . . . . . . . . . . 49
146 C.8 lc-26-lang . . . . . . . . . . . . . . . . . . . . . . . . . 49
147 C.9 lc-03-mkresource-response-cacheability . . . . . . . . . . . 50
148 C.10 lc-02-status-codes . . . . . . . . . . . . . . . . . . . . . 50
149 C.11 lc-27-lang . . . . . . . . . . . . . . . . . . . . . . . . . 50
150 C.12 lc-30-headers . . . . . . . . . . . . . . . . . . . . . . . 50
151 C.13 lc-32-ORDERPATCH . . . . . . . . . . . . . . . . . . . . . . 51
152 C.14 lc-51-repeat . . . . . . . . . . . . . . . . . . . . . . . . 51
153 C.15 lc-59-depth . . . . . . . . . . . . . . . . . . . . . . . . 51
154 C.16 lc-65-lock . . . . . . . . . . . . . . . . . . . . . . . . . 51
155 C.17 lc-66-depth . . . . . . . . . . . . . . . . . . . . . . . . 52
156 C.18 lc-69-424 . . . . . . . . . . . . . . . . . . . . . . . . . 52
157 C.19 lc-68-lock . . . . . . . . . . . . . . . . . . . . . . . . . 52
158 C.20 lc-52-no-relative . . . . . . . . . . . . . . . . . . . . . 53
159 C.21 lc-64-reftarget . . . . . . . . . . . . . . . . . . . . . . 53
160 C.22 lc-70-relative . . . . . . . . . . . . . . . . . . . . . . . 53
161 C.23 lc-73-asciiart . . . . . . . . . . . . . . . . . . . . . . . 53
162 C.24 lc-77-webdav-applications . . . . . . . . . . . . . . . . . 54
163 C.25 lc-10-title . . . . . . . . . . . . . . . . . . . . . . . . 54
164 C.26 lc-81-typo . . . . . . . . . . . . . . . . . . . . . . . . . 54
165 C.27 lc-18-resource-types . . . . . . . . . . . . . . . . . . . . 54
166 C.28 lc-84-ext . . . . . . . . . . . . . . . . . . . . . . . . . 54
167 D. Open issues . . . . . . . . . . . . . . . . . . . . . . . . 56
168 D.1 lc-85-301 . . . . . . . . . . . . . . . . . . . . . . . . . 56
169 D.2 lc-07-bind . . . . . . . . . . . . . . . . . . . . . . . . . 56
170 D.3 lc-08-bind . . . . . . . . . . . . . . . . . . . . . . . . . 56
171 D.4 lc-34-bind . . . . . . . . . . . . . . . . . . . . . . . . . 56
172 D.5 lc-35-bind . . . . . . . . . . . . . . . . . . . . . . . . . 57
173 D.6 lc-83-bind . . . . . . . . . . . . . . . . . . . . . . . . . 57
174 D.7 lc-12-bind . . . . . . . . . . . . . . . . . . . . . . . . . 57
175 D.8 lc-38-not-hierarchical . . . . . . . . . . . . . . . . . . . 57
176 D.9 lc-36-server . . . . . . . . . . . . . . . . . . . . . . . . 58
177 D.10 lc-33-forwarding . . . . . . . . . . . . . . . . . . . . . . 58
178 D.11 lc-56-notjusthttp . . . . . . . . . . . . . . . . . . . . . 58
179 D.12 lc-01-body . . . . . . . . . . . . . . . . . . . . . . . . . 58
180 D.13 lc-37-integrity . . . . . . . . . . . . . . . . . . . . . . 59
181 D.14 lc-14-bind . . . . . . . . . . . . . . . . . . . . . . . . . 59
182 D.15 lc-15-direct-ref . . . . . . . . . . . . . . . . . . . . . . 59
183 D.16 lc-39-no-reference-or-direct-resource . . . . . . . . . . . 59
184 D.17 lc-40-direct . . . . . . . . . . . . . . . . . . . . . . . . 60
185 D.18 lc-43-webdav . . . . . . . . . . . . . . . . . . . . . . . . 60
186 D.19 lc-19-direct-ref . . . . . . . . . . . . . . . . . . . . . . 60
187 D.20 lc-45-apply-to-rr . . . . . . . . . . . . . . . . . . . . . 61
188 D.21 lc-04-standard-data-container . . . . . . . . . . . . . . . 61
189 D.22 lc-05-standard-data-container . . . . . . . . . . . . . . . 61
190 D.23 lc-20-intro-mkresource . . . . . . . . . . . . . . . . . . . 61
191 D.24 lc-22-coll . . . . . . . . . . . . . . . . . . . . . . . . . 62
192 D.25 lc-25-atomic . . . . . . . . . . . . . . . . . . . . . . . . 62
193 D.26 lc-41-no-webdav . . . . . . . . . . . . . . . . . . . . . . 62
194 D.27 lc-42-no-webdav . . . . . . . . . . . . . . . . . . . . . . 62
195 D.28 lc-58-update . . . . . . . . . . . . . . . . . . . . . . . . 63
196 D.29 lc-01A-body . . . . . . . . . . . . . . . . . . . . . . . . 63
197 D.30 lc-23-body . . . . . . . . . . . . . . . . . . . . . . . . . 63
198 D.31 lc-24-properties . . . . . . . . . . . . . . . . . . . . . . 64
199 D.32 lc-47-207 . . . . . . . . . . . . . . . . . . . . . . . . . 64
200 D.33 lc-48-s6 . . . . . . . . . . . . . . . . . . . . . . . . . . 64
201 D.34 lc-28-lang . . . . . . . . . . . . . . . . . . . . . . . . . 65
202 D.35 lc-29-lang . . . . . . . . . . . . . . . . . . . . . . . . . 65
203 D.36 lc-31-MKCOL . . . . . . . . . . . . . . . . . . . . . . . . 65
204 D.37 lc-49-put . . . . . . . . . . . . . . . . . . . . . . . . . 65
205 D.38 lc-44-pseudo . . . . . . . . . . . . . . . . . . . . . . . . 66
206 D.39 lc-61-pseudo . . . . . . . . . . . . . . . . . . . . . . . . 66
207 D.40 lc-60-ex . . . . . . . . . . . . . . . . . . . . . . . . . . 66
208 D.41 lc-62-oldclient . . . . . . . . . . . . . . . . . . . . . . 67
209 D.42 lc-63-move . . . . . . . . . . . . . . . . . . . . . . . . . 67
210 D.43 lc-67-redirectref . . . . . . . . . . . . . . . . . . . . . 67
211 D.44 lc-06-reftarget-relative . . . . . . . . . . . . . . . . . . 67
212 D.45 lc-57-noautoupdate . . . . . . . . . . . . . . . . . . . . . 68
213 D.46 lc-71-relative . . . . . . . . . . . . . . . . . . . . . . . 68
214 D.47 lc-53-s10 . . . . . . . . . . . . . . . . . . . . . . . . . 68
215 D.48 lc-72-trailingslash . . . . . . . . . . . . . . . . . . . . 69
216 D.49 lc-54-s10 . . . . . . . . . . . . . . . . . . . . . . . . . 69
217 D.50 lc-50-blindredirect . . . . . . . . . . . . . . . . . . . . 69
218 D.51 lc-74-terminology . . . . . . . . . . . . . . . . . . . . . 70
219 D.52 lc-75-ignore . . . . . . . . . . . . . . . . . . . . . . . . 70
220 D.53 lc-76-location . . . . . . . . . . . . . . . . . . . . . . . 70
221 D.54 lc-78-directory . . . . . . . . . . . . . . . . . . . . . . 70
222 D.55 lc-79-accesscontrol . . . . . . . . . . . . . . . . . . . . 71
223 D.56 lc-80-i18n . . . . . . . . . . . . . . . . . . . . . . . . . 71
224 D.57 lc-55-iana . . . . . . . . . . . . . . . . . . . . . . . . . 71
225 D.58 lc-82-iana . . . . . . . . . . . . . . . . . . . . . . . . . 71
226 Intellectual Property and Copyright Statements . . . . . . . 72
228 1. Introduction
230 This is one of a pair of specifications that extend the WebDAV
231 Distributed Authoring Protocol to enable clients to create new access
232 paths to existing resources. This capability is useful for several
233 reasons:
235 URIs of WebDAV-compliant resources are hierarchical and correspond to
236 a hierarchy of collections in resource space. The WebDAV Distributed
237 Authoring Protocol makes it possible to organize these resources into
238 hierarchies, placing them into groupings, known as collections, which
239 are more easily browsed and manipulated than a single flat
240 collection. However, hierarchies require categorization decisions
241 that locate resources at a single location in the hierarchy, a
242 drawback when a resource has multiple valid categories. For example,
243 in a hierarchy of vehicle descriptions containing collections for
244 cars and boats, a description of a combination car/boat vehicle could
245 belong in either collection. Ideally, the description should be
246 accessible from both. Allowing clients to create new URIs that access
247 the existing resource lets them put that resource into multiple
248 collections.
250 Hierarchies also make resource sharing more difficult, since
251 resources that have utility across many collections are still forced
252 into a single collection. For example, the mathematics department at
253 one university might create a collection of information on fractals
254 that contains bindings to some local resources, but also provides
255 access to some resources at other universities. For many reasons, it
256 may be undesirable to make physical copies of the shared resources on
257 the local server: to conserve disk space, to respect copyright
258 constraints, or to make any changes in the shared resources visible
259 automatically. Being able to create new access paths to existing
260 resources in other collections or even on other servers is useful for
261 this sort of case.
263 The redirect reference resources defined here provide a mechanism for
264 creating alternative access paths to existing resources. A redirect
265 reference resource is a resource in one collection whose purpose is
266 to forward requests to another resource (its target), possibly in a
267 different collection. In this way, it allows clients to submit
268 requests to the target resource from another collection. It
269 redirects most requests to the target resource using the HTTP 302
270 (Found) status code, thereby providing a form of mediated access to
271 the target resource.
273 The companion specification [B], defines the BIND method, a different
274 mechanism for allowing clients to create alternative access paths to
275 existing WebDAV-compliant resources. The BIND method lets clients
276 associate a new URI with an existing WebDAV resource. This URI can
277 then be used to submit requests to the resource. Since URIs of
278 WebDAV-compliant resources are hierarchical, and correspond to a
279 hierarchy of collections in resource space, the BIND method also has
280 the effect of adding the resource to a collection. As new URIs are
281 associated with the resource, it appears in additional collections.
283 Redirect references and bindings have very different characteristics:
285 A redirect reference is a resource, and so can have properties and a
286 body of its own. Properties of a redirect reference resource can
287 contain such information as who created the reference, when, and why.
288 Since redirect reference resources are implemented using HTTP 302
289 responses, it generally takes two round trips to submit a request to
290 the intended resource. Servers are not required to enforce the
291 integrity of redirect references. Redirect references work equally
292 well for local resources and for resources that reside on a different
293 server from the reference.
295 By contrast, a BIND request does not create a new resource, but
296 simply makes available a new URI for submitting requests to an
297 existing resource. The new URI is indistinguishable from any other
298 URI when submitting a request to a resource. Only one round trip is
299 needed to submit a request to the intended target. Servers are
300 required to enforce the integrity of the relationships between the
301 new URIs and the resources associated with them. Consequently, it
302 may be very costly for servers to support BIND requests that cross
303 server boundaries.
305 The remainder of this document is structured as follows: Section 3
306 defines terms that will be used throughout the specification.
307 Section 4 provides an overview of redirect reference resources.
308 Section 5 discusses how to create a redirect reference resource.
309 Section 6 defines the semantics of existing methods when applied to
310 redirect reference resources, and Section 7 discusses their semantics
311 when applied to collections that contain redirect reference
312 resources. Sections 8 through 10 discuss several other issues raised
313 by the existence of redirect reference resources. Sections 11
314 through 14 define the new headers, properties, and XML elements
315 required to support redirect reference resources. Section 15
316 discusses capability discovery. Sections 16 through 18 present the
317 security, internationalization, and IANA concerns raised by this
318 specification. The remaining sections provide a variety of supporting
319 information.
321 2. Notational Conventions
323 Since this document describes a set of extensions to the WebDAV
324 Distributed Authoring Protocol [RFC2518], itself an extension to the
325 HTTP/1.1 protocol, the augmented BNF used here to describe protocol
326 elements is exactly the same as described in Section 2.1 of
327 [RFC2616]. Since this augmented BNF uses the basic production rules
328 provided in Section 2.2 of [RFC2616], these rules apply to this
329 document as well.
331 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
332 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
333 document are to be interpreted as described in [RFC2119].
335 3. Terminology
337 The terminology used here follows and extends that in the WebDAV
338 Distributed Authoring Protocol specification [RFC2518]. Definitions
339 of the terms resource, Uniform Resource Identifier (URI), and Uniform
340 Resource Locator (URL) are provided in [RFC2396].
342 Reference Resource
344 A resource whose purpose is to forward requests to another
345 resource. Reference resources are an alternative mechanism to
346 bindings (defined in [B]) for allowing clients to create multiple
347 URIs that can be used to submit requests to the same resource.
349 Redirect Reference Resource
351 A resource that allows clients to forward requests to another
352 resource using the HTTP 1.1 302 (Found) response mechanism. The
353 client is aware that this type of reference resource is mediating
354 between it and the target resource.
356 Direct Reference Resource
358 Direct Reference Resources are out of scope for this
359 specification, but are defined here for contrast with redirect
360 reference resources. A direct reference resource automatically
361 forwards requests to another resource, in a way that is
362 transparent to the client.
364 Non-Reference Resource
366 A resource that is not a reference to another resource.
368 Target Resource
370 The resource to which requests are forwarded by a reference
371 resource.
373 4. Overview of Redirect Reference Resources
375 For all operations submitted to a redirect reference resource, the
376 default response is a 302 (Found), accompanied by the Redirect-Ref
377 header (defined in Section 11.1 below) and the Location header set to
378 the URI of the target resource. With this information, the client
379 can resubmit the request to the URI of the target resource.
381 A redirect reference resource never automatically forwards requests
382 to its target resource. It is this characteristic that distinguishes
383 redirect reference resource from direct reference resources and from
384 bindings. It is also what helps to insure that redirect reference
385 resources will be simple to implement and that cross-server
386 references will be possible. If the redirect reference resource were
387 required to forward requests automatically, the server would need
388 proxy capabilities in order to support cross-server references.
390 If the client is aware that it is operating on a redirect reference
391 resource, it can resolve the reference by retrieving the reference
392 resource's DAV:reftarget property (defined in Section 12.1 below),
393 whose value contains the URI of the target resource. It can then
394 submit requests to the target resource.
396 A redirect reference resource is a new type of resource. To
397 distinguish redirect reference resources from non-reference
398 resources, a new value of the DAV:resourcetype property (defined in
399 [RFC2518]), DAV:redirectref, is defined in Section 13.1 below.
401 Since a redirect reference resource is a resource, it can have its
402 own properties and body, and methods can be applied to the reference
403 resource as well as to its target resource. The
404 Apply-To-Redirect-Ref request header (defined in Section 11.2 below)
405 is provided so that referencing-aware clients can control whether an
406 operation is applied to the redirect reference resource or to its
407 target resource. The Apply-To-Redirect-Ref header can be used with
408 most requests to redirect reference resources. This header is
409 particularly useful with PROPFIND, to retrieve the reference
410 resource's own properties.
412 5. Creating a Redirect Reference Resource
414 The MKRESOURCE method is used to create new redirect reference
415 resources. As defined in Section 5.1, MKRESOURCE can be used to
416 create a resource of any type other than standard data containers and
417 collections. In order to create a redirect reference resource using
418 MKRESOURCE, the values of two properties must be set in the body of
419 the MKRESOURCE request. The value of DAV:resourcetype MUST be set to
420 DAV:redirectref, a new value of DAV:resourcetype defined in Section
421 13.1. The value of DAV:reftarget MUST be set to the URI of the target
422 resource.
424 Used in this way, the MKRESOURCE method creates a redirect reference
425 resource whose target is identified by the DAV:reftarget property.
427 5.1 MKRESOURCE
429 The MKRESOURCE method requests the creation of a resource and
430 initialization of its properties. It allows resources other than
431 standard data containers and collections to be created and their
432 properties initialized in one atomic operation.
434 Preconditions:
436 A resource MUST NOT exist at the Request-URI.
438 Request Marshalling:
440 The location of the new resource to be created is specified by the
441 Request-URI.
443 The request body of the MKRESOURCE method MUST consist of the
444 DAV:propertyupdate XML element defined in Section 12.13 of
445 [RFC2518].
447 Postconditions:
449 If the response status code is 201, a new resource exists at the
450 Request-URI.
452 The body of the new resource is empty.
454 The properties of the new resource are as specified by the
455 DAV:propertyupdate request body, using PROPPATCH semantics. If the
456 DAV:propertyupdate does not specify a DAV:resourcetype, the
457 resource will be a standard data container.
459 If the response status code is not 201, then a new resource is not
460 created at the Request-URI, and any existing resource at the
461 Request-URI is unaffected.
463 Response Marshalling:
465 Responses from a MKRESOURCE request MUST NOT be cached, as
466 MKRESOURCE has non-idempotent semantics.
468 The following status codes can be expected in responses to
469 MKRESOURCE:
471 201 (Created): The new resource was successfully created.
473 207 (Multi-Status): This response is generated if an error was
474 encountered while initializing the properties of the resource, in
475 which case the response is as defined in Section 8.2.1 of
476 [RFC2518].
478 403 (Forbidden): The server does not allow the creation of the
479 requested resource type at the requested location, or the parent
480 collection of the Request-URI exists but cannot accept members.
482 409 (Conflict): A resource cannot be created at the Request-URI
483 because the parent collection for the resource does not exist, or
484 because there is already a resource at that request-URL.
486 423 (Locked): The Request-URI is locked, and the lock token was
487 not passed with the request.
489 507 (Insufficient Storage): The server does not have sufficient
490 space to record the state of the resource.
492 5.2 Example: Creating a Redirect Reference Resource with MKRESOURCE
494 >> Request:
496 MKRESOURCE /~whitehead/dav/spec08.ref HTTP/1.1
497 Host: www.ics.uci.edu
498 Content-Type: text/xml; charset="utf-8"
499 Content-Length: xxx
501
502
503
504
505
506
507 /i-d/draft-webdav-protocol-08.txt
508
509
510
511
513 >> Response:
515 HTTP/1.1 201 Created
517 This request resulted in the creation of a new redirect reference
518 resource at www.ics.uci.edu/~whitehead/dav/spec08.ref, which points
519 to the resource identified by the DAV:reftarget property. In this
520 example, the target resource is identified by the URI http://
521 www.ics.uci.edu/i-d/draft-webdav-protocol-08.txt. The redirect
522 reference resource's DAV:resourcetype property is set to
523 DAV:redirectref.
525 6. Operations on Redirect Reference Resources
527 Although non-referencing-aware clients cannot create reference
528 resources, they should be able to submit requests through the
529 reference resources created by reference-aware WebDAV clients. They
530 should be able to follow any references to their targets. To make
531 this possible, a server that receives any request made via a redirect
532 reference resource MUST return a 302 (Found) status code, unless the
533 request includes an Apply-To-Redirect-Ref header. The client and
534 server MUST follow [RFC2616] Section 10.3.3 "302 Found," but with
535 these additional rules:
537 o The Location response header MUST contain an absolute URI that
538 identifies the target of the reference resource.
540 o The response MUST include the Redirect-Ref header. This header
541 allows reference-aware WebDAV clients to recognize the resource as
542 a reference resource and understand the reason for the
543 redirection.
545 A reference-aware WebDAV client can act on this response in one of
546 two ways. It can, like a non-referencing client, resubmit the
547 request to the URI in the Location header in order to operate on the
548 target resource. Alternatively, it can resubmit the request to the
549 URI of the redirect reference resource with the Apply-To-Redirect-Ref
550 header in order to operate on the reference resource itself. If the
551 Apply-To-Redirect-Ref header is present, the request MUST be applied
552 to the reference resource itself, and a 302 response MUST NOT be
553 returned.
555 A reference-aware client may know before submitting its request that
556 the Request-URI identifies a redirect reference resource. In this
557 case, if the client wants to apply the method to the reference
558 resource, it can save the round trip caused by the 302 response by
559 using an Apply-To-Redirect-Ref header in its initial request to the
560 URI.
562 A few methods need additional explanation:
564 The Apply-To-Redirect-Ref header can be used with GET or HEAD to
565 retrieve the entity headers of a redirect reference resource. When
566 Apply-To-Redirect-Ref is used with GET or HEAD, the Redirect-Ref
567 entity header MUST be returned.
569 A redirect reference resource MAY have a body, though none is defined
570 for it in this specification. The PUT method can be used, with
571 Apply-To-Redirect-Ref, to create or replace the body of a redirect
572 reference resource.
574 Since MKCOL and MKRESOURCE fail when applied to existing resources,
575 if the client attempts to resubmit the request to the target
576 resource, the request MUST fail (unless the reference resource is a
577 dangling reference). Similarly, if the client attempts to resubmit
578 the request to the reference resource with an Apply-To-Redirect-Ref
579 header, the request MUST fail.
581 6.1 Example: GET on a Redirect Reference Resource
583 >> Request:
585 GET /bar.html HTTP/1.1
586 Host: www.foo.com
588 >> Response:
590 HTTP/1.1 302 Found
591 Location: http://www.svr.com/Internet/xxspec08.html
592 Redirect-Ref:
594 Since /bar.html is a redirect reference resource and the
595 Apply-To-Redirect-Ref header is not included in the request, the
596 response is a 302 (Found). The Redirect-Ref header informs a
597 reference-aware client that this is not an ordinary HTTP 1.1
598 redirect, but is a redirect reference resource. The URI of the
599 target resource is provided in the Location header so that the client
600 can resubmit the request to the target resource.
602 6.2 Example: PUT on a Redirect Reference Resource with
603 Apply-To-Redirect-Ref
605 >> Request:
607 PUT /bar.html HTTP/1.1
608 Host: www.foo.com
609 Apply-To-Redirect-Ref:
610 Content-Type: text/xml; charset="utf-8"
611 Content-Length: xxxx
613 . . . some content . . .
615 >> Response:
617 HTTP/1.1 200 OK
619 Although /bar.html is a redirect reference resource, the presence of
620 the Apply-To-Redirect-Ref header prevents a 302 response, and instead
621 causes the request to be applied to the reference resource. The
622 result in this case is that the reference resource is replaced by a
623 non-reference resource having the content submitted with the request.
625 6.3 Example: PROPPATCH on a Redirect Reference Resource
627 >> Request:
629 PROPPATCH /bar.html HTTP/1.1
630 Host: www.foo.com
631 Content-Type: text/xml; charset="utf-8"
632 Content-Length: xxxx
634
635
637
638
639
640 Jim Whitehead
641 Roy Fielding
642
643
644
645
646
647
648
649
650
652 >> Response:
654 HTTP/1.1 302 Found
655 Location: http://www.svr.com/Internet/xxspec08.html
656 Redirect-Ref:
658 Since /bar.html is a redirect reference resource and the
659 Apply-To-Redirect-Ref header is not included in the request, the
660 response is a 302 (Found). The Redirect-Ref header informs a
661 reference-aware client that this is not an ordinary HTTP 1.1
662 redirect, but is a redirect reference resource. The URI of the
663 target resource is provided in the Location header so that the client
664 can resubmit the request to the target resource.
666 7. Operations on Collections That Contain Redirect Reference Resources
668 Consistent with the rules in Section 6, the response for each
669 redirect reference encountered while processing a collection MUST be
670 a 302 (Found) unless a Apply-To-Redirect-Ref header is included with
671 the request. The overall response will therefore be a 207
672 (Multi-Status). Since a Location header and Redirect-Ref header
673 cannot be returned for each redirect reference encountered, the same
674 information is provided using properties in the response elements for
675 those resources. The DAV:location pseudo-property and the
676 DAV:resourcetype property MUST be included with the 302 status code.
677 This necessitates an extension to the syntax of the DAV:response
678 element that was defined in [RFC2518]. The extension is defined in
679 Section 14 below.
681 A referencing-aware client can tell from the DAV:resourcetype
682 property that the collection contains a redirect reference resource.
683 The DAV:location pseudo-property contains the absolute URI of the
684 target resource. A referencing-aware client can either use the URI
685 value of the DAV:location pseudo-property to resubmit its request to
686 the target resource, or it can submit the request to the redirect
687 reference resource with Apply-To-Redirect-Ref.
689 It is recommended that future editors of [RFC2518] define the
690 DAV:location pseudo-property in [RFC2518], so that non-referencing
691 clients will also be able to use the response to operate on the
692 target resource. (This will also enable clients to operate on
693 traditional HTTP/1.1 302 responses in Multi-Status responses.) Until
694 then, non- referencing clients will not be able to process 302
695 responses from redirect reference resources encountered while
696 processing a collection.
698 The Apply-To-Redirect-Ref header (defined in Section 11.2) MAY be
699 used with any request on a collection. If present, it will be
700 applied to all redirect reference resources encountered while
701 processing the collection.
703 7.1 MOVE and DELETE on Collections That Contain Redirect References
705 DELETE removes the binding that corresponds to the Request-URI. MOVE
706 removes that binding and creates a new binding to the same resource.
707 In cases where DELETE and MOVE are applied to a collection, these
708 operations affect all the descendents of the collection, but they do
709 so indirectly. There is no need to visit each descendent in order to
710 process the request. Consequently, even if there are redirect
711 reference resources in a tree that is being deleted or moved, there
712 will be no 302 responses from the redirect reference resources.
714 7.2 LOCK on a Collection That Contains Redirect References
716 LOCK poses special problems because it is atomic. An attempt to lock
717 (with Depth: infinity) a collection that contains redirect references
718 will always fail. The Multi-Status response will contain a 302
719 response for each redirect reference.
721 Reference-aware clients can lock the collection by using
722 Apply-To-Redirect-Ref, and, if desired, lock the targets of the
723 redirect references individually.
725 Non-referencing clients must resort to locking each resource
726 individually.
728 7.3 Example: PROPFIND on a Collection with Redirect Reference Resources
730 Suppose a PROPFIND request with Depth: infinity is submitted to the
731 following collection, with the members shown here:
733 http://www.svr.com/MyCollection/
734 (non-reference resource) diary.html
735 (redirect reference resource) nunavut
737 >> Request:
739 PROPFIND /MyCollection/ HTTP/1.1
740 Host: www.svr.com
741 Depth: infinity
742 Content-Type: text/xml
743 Content-Length: xxxx
745
746
747
748
749
750
751
753 >> Response:
755 HTTP/1.1 207 Multi-Status
756 Content-Type: text/xml
757 Content-Length: xxxx
759
760
761
762 http://www.svr.com/MyCollection/
763
764
765
766 diary, interests, hobbies
767
768 HTTP/1.1 200 OK
769
770
771
772 http://www.svr.com/MyCollection/diary.html
773
774
775
776 diary, travel, family, history
777
778 HTTP/1.1 200 OK
779
780
781
782 http://www.svr.com/MyCollection/nunavut
783 HTTP/1.1 302 Found
784
785
786 http://www.inac.gc.ca/art/inuit/
787
788
789
790
791
793 In this example the Depth header is set to infinity, and the
794 Apply-To-Redirect-Ref header is not used. The collection contains
795 one URI that identifies a redirect reference resource. The response
796 element for the redirect reference resource has a status of 302
797 (Found), and includes a DAV:prop element with the DAV:location
798 pseudo-property and the DAV:resourcetype property to allow clients to
799 retrieve the properties of its target resource. (The response
800 element for the redirect reference resource does not include the
801 requested properties. The client can submit another PROPFIND request
802 to the URI in the DAV:location pseudo-property to retrieve those
803 properties.)
805 7.4 Example: PROPFIND with Apply-To-Redirect-Ref on a Collection with
806 Redirect Reference Resources
808 Suppose a PROPFIND request with Apply-To-Redirect-Ref and Depth =
809 infinity is submitted to the following collection, with the members
810 shown here:
812 /MyCollection/
813 (non-reference resource) diary.html
814 (redirect reference resource) nunavut
816 >> Request:
818 PROPFIND /MyCollection/ HTTP/1.1
819 Host: www.svr.com
820 Depth: infinity
821 Apply-To-Redirect-Ref:
822 Content-Type: text/xml
823 Content-Length: xxxx
825
826
827
828
829
830
831
833 >> Response:
835 HTTP/1.1 207 Multi-Status
836 Content-Type: text/xml
837 Content-Length: xxxx
839
840
841
842 http://www.svr.com/MyCollection/
843
844
845
846
847 HTTP/1.1 200 OK
848
849
850
851 HTTP/1.1 404 Not Found
852
853
854
855 http://www.svr.com/MyCollection/diary.html
856
857
858
859
860 HTTP/1.1 200 OK
861
862
863
864 HTTP/1.1 404 Not Found
865
866
867
868 http://www.svr.com/MyCollection/nunavut
869
870
871
872
873 http://www.inac.gc.ca/art/inuit/
874
875
876 HTTP/1.1 200 OK
877
878
879
881 Since the Apply-To-Redirect-Ref header is present, the response shows
882 the properties of the redirect reference resource in the collection
883 rather than the properties of its target. The Apply-To-Redirect-Ref
884 header also prevents a 302 response from being returned for the
885 redirect reference resource.
887 7.5 Example: COPY on a Collection That Contains a Redirect Reference
888 Resource
890 Suppose a COPY request is submitted to the following collection, with
891 the members shown:
893 /MyCollection/
894 (non-reference resource) diary.html
895 (redirect reference resource) nunavut with target
896 /Someplace/nunavut.map
898 >> Request:
900 COPY /MyCollection/ HTTP/1.1
901 Host: www.svr.com
902 Depth: infinity
903 Destination: http://www.svr.com/OtherCollection/
904 >> Response:
906 HTTP/1.1 207 Multi-Status
907 Content-Type: text/xml; charset="utf-8"
908 Content-Length: xxx
910
911
912
913 http://www.svr.com/MyCollection/nunavut
914 HTTP/1.1 302 Found
915
916
917 http://www.svr.com//Someplace/nunavut.map
918
919
920
921
922
924 In this case, since /MyCollection/nunavut is a redirect reference
925 resource, the COPY operation was only a partial success. The
926 redirect reference resource was not copied, but a 302 response was
927 returned for it. So the resulting collection is as follows:
929 /OtherCollection/
930 (non-reference resource) diary.html
932 7.6 Example: LOCK on a Collection That Contains a Redirect Reference
933 Resource
935 Suppose a LOCK request is submitted to the following collection, with
936 the members shown:
938 /MyCollection/
939 (non-reference resource) diary.html
940 (redirect reference resource) nunavut
942 >> Request:
944 LOCK /MyCollection/ HTTP/1.1
945 Host: www.svr.com
946 Content-Type: text/xml
947 Content-Length: nnnn
948 Authorizaton: Digest username="jas",
949 realm=jas@webdav.sb.aol.com, nonce=". . . ",
950 uri="/MyCollection/tuva",
951 response=". . . ", opaque=". . . "
953
954
955
956
957
958 http://www.svr.com/~jas/contact.html
959
960
962 >> Response:
964 HTTP/1.1 207 Multi-Status
965 Content-Type: text/xml
966 Content-Length: nnnn
968
969
970
971 http://www.svr.com/MyCollection/
972
973
974 HTTP/1.1 424 Failed Dependency
975
976
977
978 http://www.svr.com/MyCollection/diary.html
979 HTTP/1.1 424 Failed Dependency
980
981
982 http://www.svr.com/MyCollection/nunavut
983 HTTP/1.1 302 Found
984
985
986 http://www.inac.gc.ca/art/inuit/
987
988
989
990
991
993 The server returns a 302 response code for the redirect reference
994 resource in the collection. Consequently, neither the collection nor
995 any of the resources identified by its internal member URIs were
996 locked. A referencing-aware client can submit a separate LOCK request
997 to the URI in the DAV:location pseudo-property returned for the
998 redirect reference resource, and can resubmit the LOCK request with
999 the Apply-To-Redirect-Ref header to the collection. At that point
1000 both the reference resource and its target resource will be locked
1001 (as well as the collection and all the resources identified by its
1002 other members).
1004 8. Operations on Targets of Redirect Reference Resources
1006 Operations on targets of redirect reference resources have no effect
1007 on the reference resource.
1009 9. Relative URIs in DAV:reftarget
1011 The URI in the href in a DAV:reftarget property MAY be a relative
1012 URI. In this case, the base URI to be used for resolving the relative
1013 URI to absolute form is the URI used in the HTTP message to identify
1014 the redirect reference resource to which the DAV:reftarget property
1015 belongs.
1017 When DAV:reftarget occurs in the body of a MKRESOURCE request, the
1018 base URI is constructed as follows: Its scheme component is "http",
1019 its authority component is the value of the Host header in the
1020 request, and its path component is the Request-URI in the request.
1021 See Section 5 of [RFC2396] for a discussion of relative URI
1022 references and how to resolve them.
1024 When DAV:reftarget appears in the context of a Multi-Status response,
1025 it is in a DAV:response element that contains a single DAV:href
1026 element. The value of this DAV:href element serves as the base URI
1027 for resolving a relative URI in DAV:reftarget. The value of DAV:href
1028 may itself be relative, in which case it must be resolved first in
1029 order to serve as the base URI for the relative URI in DAV:reftarget.
1030 If the DAV:href element is relative, its base URI is constructed from
1031 the scheme component "http", the value of the Host header in the
1032 request, and the request-URI.
1034 9.1 Example: Resolving a Relative URI in a MKRESOURCE Request
1036 >> Request:
1038 MKRESOURCE /north/inuvik HTTP/1.1
1039 Host: www.somehost.edu
1040 Content-Type: text/xml; charset="utf-8"
1041 Content-Length: xxx
1043
1044
1045
1046
1047
1048
1049 mapcollection/inuvik.gif
1050
1051
1052
1053
1055 >> Response:
1057 HTTP/1.1 201 Created
1059 In this example, the base URI is http://www.somehost.edu/north/
1060 inuvik. Then, following the rules in [RFC2396] Section 5, the
1061 relative URI in DAV:reftarget resolves to the absolute URI http://
1062 www.somehost.edu/north/mapcollection/inuvik.gif.
1064 9.2 Example: Resolving a Relative URI in a Multi-Status Response
1066 >> Request:
1068 PROPFIND /geog/ HTTP/1.1
1069 Host: www.xxsvr.com
1070 Apply-To-Redirect-Ref:
1071 Depth: 1
1072 Content-Type: text/xml
1073 Content-Length: nnn
1075
1076
1077
1078
1079
1080
1081
1083 >> Response:
1085 HTTP/1.1 207 Multi-Status
1086 Content-Type: text/xml
1087 Content-Length: nnn
1089
1090
1091
1092 /geog/
1093
1094
1095
1096
1097 HTTP/1.1 200 OK
1098
1099
1100
1101 HTTP/1.1 404 Not Found
1102
1103
1104
1105 /geog/stats.html
1106
1107
1108
1109
1110 statistics/population/1997.html
1111
1112
1113 HTTP/1.1 200 OK
1114
1115
1116
1118 In this example, the relative URI statistics/population/1997.html is
1119 returned as the value of reftarget for the reference resource
1120 identified by href /geog/stats.html. The href is itself a relative
1121 URI, which resolves to http://www.xxsrv.com/geog/stats.html. This is
1122 the base URI for resolving the relative URI in reftarget. The
1123 absolute URI of reftarget is http://www.xxsrv.com/geog/statistics/
1124 population/1997.html.
1126 10. Redirect References to Collections
1128 In a Request-URI /segment1/segment2/segment3, any of the three
1129 segments may identify a redirect reference resource. (See [RFC2396],
1130 Section 3.3, for definitions of "path" and "segment".) If any
1131 segment in a Request- URI identifies a redirect reference resource,
1132 the response is a 302. The value of the Location header in the 302
1133 response is as follows:
1135 The leftmost path segment of the request-URI that identifies a
1136 redirect reference resource, together with all path segments and
1137 separators to the left of it, is replaced by the value of the
1138 redirect reference resource's DAV:reftarget property (resolved to an
1139 absolute URI). The remainder of the request-URI is concatenated to
1140 this path.
1142 Note: If the DAV:reftarget property ends with a "/" and the remainder
1143 of the Request-URI is non-empty (and therefore must begin with a "/
1144 "), the final "/" in the DAV:reftarget property is dropped before the
1145 remainder of the Request-URI is appended.
1147 Consider Request-URI /x/y/z.html. Suppose that /x/ is a redirect
1148 reference resource whose target resource is collection /a/, which
1149 contains redirect reference resource y whose target resource is
1150 collection /b/, which contains redirect reference resource z.html
1151 whose target resource is /c/d.html.
1153 /x/y/z.html
1154 |
1155 | /x -> /a
1156 |
1157 v
1158 /a/y/z.html
1159 |
1160 | /a/y -> /b
1161 |
1162 v
1163 /b/z.html
1164 |
1165 | /b/z.html -> /c/d.html
1166 |
1167 v
1168 /c/d.html
1170 In this case the client must follow up three separate 302 responses
1171 before finally reaching the target resource. The server responds to
1172 the initial request with a 302 with Location: /a/y/z.html, and the
1173 client resubmits the request to /a/y/z.html. The server responds to
1174 this request with a 302 with Location: /b/z.html, and the client
1175 resubmits the request to /b/z.html. The server responds to this
1176 request with a 302 with Location: /c/d.html, and the client resubmits
1177 the request to /c/d.html. This final request succeeds.
1179 11. Headers
1181 11.1 Redirect-Ref Response Header
1183 Redirect-Ref = "Redirect-Ref:"
1185 The Redirect-Ref header is used in all 302 responses from redirect
1186 reference resources. Its presence informs reference-aware clients
1187 that the response is not a plain HTTP/1.1 redirect, but is a response
1188 from a redirect reference resource.
1190 11.2 Apply-To-Redirect-Ref Request Header
1192 Apply-To-Redirect-Ref = "Apply-To-Redirect-Ref" ":"
1194 The optional Apply-To-Redirect-Ref header can be used on any request
1195 to a redirect reference resource. When it is used, the request MUST
1196 be applied to the reference resource itself, and a 302 response MUST
1197 NOT be returned.
1199 If the Apply-To-Redirect-Ref header is used on a request to any other
1200 sort of resource besides a redirect reference resource, the server
1201 SHOULD ignore it.
1203 12. Properties
1205 12.1 reftarget Property
1207 Name: reftarget
1209 Namespace: DAV:
1211 Purpose: A property of redirect reference resources that provides an
1212 efficient way for clients to discover the URI of the target
1213 resource. This is a read-only property after its initial
1214 creation. Its value can only be set in a MKRESOURCE request.
1216 Value: href containing the URI of the target resource. This value
1217 MAY be a relative URI. The reftarget property can occur in the
1218 entity bodies of MKRESOURCE requests and of responses to PROPFIND
1219 requests.
1221
1223 12.2 location Pseudo-Property
1225 Name: location
1227 Namespace: DAV:
1229 Purpose: For use with 302 (Found) response codes in Multi-Status
1230 responses. It contains the absolute URI of the temporary location
1231 of the resource. In the context of redirect reference resources,
1232 this value is the absolute URI of the target resource. It is
1233 analogous to the Location header in HTTP 302 responses defined in
1234 [RFC2616] Section 10.3.3 "302 Found." Including the location
1235 pseudo-property in a Multi- Status response requires an extension
1236 to the syntax of the DAV:response element defined in [RFC2518],
1237 which is defined in Section 14 below. This pseudo-property is not
1238 expected to be stored on the reference resource. It is modeled as
1239 a property only so that it can be returned inside a DAV:prop
1240 element in a Multi-Status response.
1242 Value: href containing the absolute URI of the target resource.
1244
1246 13. XML Elements
1248 13.1 redirectref XML Element
1250 Name: redirectref
1252 Namespace: DAV:
1254 Purpose: Used as the value of the DAV:resourcetype property to
1255 specify that the resource type is a redirect reference resource.
1257
1259 14. Extensions to the DAV:response XML Element for Multi-Status
1260 Responses
1262 As described in Section 7, the DAV:location pseudo-property and the
1263 DAV:resourcetype property may be returned in the DAV:response element
1264 of a 207 Multi-Status response, to allow clients to resubmit their
1265 requests to the target resource of a redirect reference resource.
1267 Whenever these properties are included in a Multi-Status response,
1268 they are placed in a DAV:prop element associated with the href to
1269 which they apply. This structure provides a framework for future
1270 extensions by other standards that may need to include additional
1271 properties in their responses.
1273 Consequently, the definition of the DAV:response XML element changes
1274 to the following:
1276
1279 15. Capability Discovery
1281 Sections 9.1 and 15 of [RFC2518] describe the use of compliance
1282 classes with the DAV header in responses to OPTIONS, to indicate
1283 which parts of the WebDAV Distributed Authoring protocols the
1284 resource supports. This specification defines an OPTIONAL extension
1285 to [RFC2518]. It defines a new compliance class, called
1286 redirectrefs, for use with the DAV header in responses to OPTIONS
1287 requests. If a resource does support redirect references, its
1288 response to an OPTIONS request may indicate that it does, by listing
1289 the new redirectrefs compliance class in the DAV headerand by listing
1290 the MKRESOURCE method as one it supports.
1292 When responding to an OPTIONS request, any type of resource can
1293 include redirectrefs in the value of the DAV header. Doing so
1294 indicates that the server permits a redirect reference resource at
1295 the request URI.
1297 15.1 Example: Discovery of Support for Redirect Reference Resources
1299 >> Request:
1301 OPTIONS /somecollection/someresource HTTP/1.1
1302 HOST: somehost.org
1304 >> Response:
1306 HTTP/1.1 200 OK
1307 Date: Tue, 20 Jan 1998 20:52:29 GMT
1308 Connection: close
1309 Accept-Ranges: none
1310 Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE,
1311 MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, MKRESOURCE
1312 DAV: 1, 2, redirectrefs
1314 The DAV header in the response indicates that the resource /
1315 somecollection/someresource is level 1 and level 2 compliant, as
1316 defined in [RFC2518]. In addition, /somecollection/someresource
1317 supports redirect reference resources. The Allow header indicates
1318 that MKRESOURCE requests can be submitted to /somecollection/
1319 someresource. The Public header shows that other Request-URIs on the
1320 server support additional methods.
1322 16. Security Considerations
1324 This section is provided to make applications that implement this
1325 protocol aware of the security implications of this protocol.
1327 All of the security considerations of HTTP/1.1 and the WebDAV
1328 Distributed Authoring Protocol specification also apply to this
1329 protocol specification. In addition, redirect reference resources
1330 introduce several new security concerns and increase the risk of some
1331 existing threats. These issues are detailed below.
1333 16.1 Privacy Concerns
1335 By creating redirect reference resources on a trusted server, it is
1336 possible for a hostile agent to induce users to send private
1337 information to a target on a different server. This risk is
1338 mitigated somewhat, since clients are required to notify the user of
1339 the redirection for any request other than GET or HEAD. (See
1340 [RFC2616], Section 10.3.3 302 Found.)
1342 16.2 Redirect Loops
1344 Although redirect loops were already possible in HTTP 1.1, the
1345 introduction of the MKRESOURCE method creates a new avenue for
1346 clients to create loops accidentally or maliciously. If the
1347 reference resource and its target are on the same server, the server
1348 may be able to detect MKRESOURCE requests that would create loops.
1349 See also [RFC2616], Section 10.3 "Redirection 3xx."
1351 16.3 Redirect Reference Resources and Denial of Service
1353 Denial of service attacks were already possible by posting URLs that
1354 were intended for limited use at heavily used Web sites. The
1355 introduction of MKRESOURCE creates a new avenue for similar denial of
1356 service attacks. Clients can now create redirect reference resources
1357 at heavily used sites to target locations that were not designed for
1358 heavy usage.
1360 16.4 Revealing Private Locations
1362 There are several ways that redirect reference resources may reveal
1363 information about directory structures. First, the DAV:reftarget
1364 property of every redirect reference resource contains the URI of the
1365 target resource. Anyone who has access to the reference resource can
1366 discover the directory path that leads to the target resource. The
1367 owner of the target resource may have wanted to limit knowledge of
1368 this directory structure.
1370 Sufficiently powerful access control mechanisms can control this risk
1371 to some extent. Property-level access control could prevent users
1372 from examining the DAV:reftarget property. (The Location header
1373 returned in responses to requests on redirect reference resources
1374 reveals the same information, however.) In some environments, the
1375 owner of a resource might be able to use access control to prevent
1376 others from creating references to that resource.
1378 This risk is no greater than the similar risk posed by HTML links.
1380 17. Internationalization Considerations
1382 This specification follows the practices of [RFC2518] in encoding all
1383 human-readable content using XML [XML] and in the treatment of names.
1384 Consequently, this specification complies with the IETF Character Set
1385 Policy [RFC2277].
1387 WebDAV applications MUST support the character set tagging, character
1388 set encoding, and the language tagging functionality of the XML
1389 specification. This constraint ensures that the human-readable
1390 content of this specification complies with [RFC2277].
1392 As in [RFC2518], names in this specification fall into three
1393 categories: names of protocol elements such as methods and headers,
1394 names of XML elements, and names of properties. Naming of protocol
1395 elements follows the precedent of HTTP, using English names encoded
1396 in USASCII for methods and headers. The names of XML elements used
1397 in this specification are English names encoded in UTF-8.
1399 For error reporting, [RFC2518] follows the convention of HTTP/1.1
1400 status codes, including with each status code a short, English
1401 description of the code (e.g., 423 Locked). Internationalized
1402 applications will ignore this message, and display an appropriate
1403 message in the user's language and character set.
1405 This specification introduces no new strings that are displayed to
1406 users as part of normal, error-free operation of the protocol.
1408 For rationales for these decisions and advice for application
1409 implementors, see [RFC2518].
1411 18. IANA Considerations
1413 This document uses the namespaces defined by [RFC2518] for properties
1414 and XML elements. All other IANA considerations mentioned in
1415 [RFC2518] also apply to this document.
1417 19. Acknowledgements
1419 This draft has benefited from thoughtful discussion by Jim Amsden,
1420 Peter Carlson, Steve Carter, Tyson Chihaya, Ken Coar, Ellis Cohen,
1421 Bruce Cragun, Spencer Dawkins, Mark Day, Rajiv Dulepet, David Durand,
1422 Roy Fielding, Yaron Goland, Fred Hitt, Alex Hopmann, James Hunt,
1423 Marcus Jager, Chris Kaler, Manoj Kasichainula, Rohit Khare, Daniel
1424 LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Surendra
1425 Koduru Reddy, Max Rible, Sam Ruby, Bradley Sergeant, Nick Shelness,
1426 John Stracke, John Tigue, John Turner, Kevin Wiggen, and others.
1428 Normative References
1430 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
1431 Languages", BCP 18, RFC 2277, January 1998.
1433 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1434 Requirement Levels", BCP 14, RFC 2119, March 1997.
1436 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
1437 Resource Identifiers (URI): Generic Syntax", RFC 2396,
1438 August 1998.
1440 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D.
1441 Jensen, "HTTP Extensions for Distributed Authoring --
1442 WEBDAV", RFC 2518, February 1999.
1444 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
1445 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
1446 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
1448 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
1449 "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C
1450 REC-xml, October 2000, .
1453 Informative References
1455 [B] Clemm, G., Crawford, J., Reschke, J., Slein, J. and J.
1456 Whitehead, "Binding Extensions to WebDAV", Internet Draft (work
1457 in progress) draft-ietf-webdav-bind-02, June 2003.
1459 URIs
1461 [1]
1463 [2]
1465 [3]
1468 [4]
1471 [5]
1474 [6]
1477 [7]
1480 [8]
1483 [9]
1486 [10]
1489 [11]
1492 [12]
1495 [13]
1498 [14]
1501 [15]
1504 [16]
1507 [17]
1510 [18]
1513 [19]
1516 [20]
1519 [21]
1522 [22]
1525 [23]
1528 [24]
1531 [25]
1534 [26]
1537 [27]
1540 [28]
1543 [29]
1546 [30]
1549 [31]
1552 [32]
1555 [33]
1558 [34]
1561 [35]
1564 [36]
1567 [37]
1570 [38]
1573 [39]
1576 [40]
1579 [41]
1582 [42]
1585 [43]
1588 [44]
1591 [45]
1594 [46]
1597 [47]
1600 [48]
1603 [49]
1606 [50]
1609 [51]
1612 [52]
1615 [53]
1618 [54]
1621 [55]
1624 [56]
1627 [57]
1630 [58]
1633 [59]
1636 [60]
1639 [61]
1642 [62]
1645 [63]
1648 [64]
1651 [65]
1654 [66]
1657 [67]
1660 [68]
1663 [69]
1666 [70]
1669 [71]
1672 [72]
1675 [73]
1678 [74]
1681 [75]
1684 [76]
1687 [77]
1690 [78]
1693 [79]
1696 [80]
1699 [81]
1702 [82]
1705 [83]
1708 [84]
1711 [85]
1714 [86]
1717 [87]
1720 Authors' Addresses
1722 J. Slein
1723 Xerox Corporation
1724 800 Phillips Road, 105-50C
1725 Webster, NY 14580
1727 EMail: jslein@crt.xerox.com
1729 Jim Whitehead
1730 UC Santa Cruz, Dept. of Computer Science
1731 1156 High Street
1732 Santa Cruz, CA 95064
1733 US
1735 EMail: ejw@cse.ucsc.edu
1737 J. Davis
1738 CourseNet Systems
1739 170 Capp Street
1740 San Francisco, CA 94110
1742 EMail: jrd3@alum.mit.edu
1743 G. Clemm
1744 Rational Software Corporation
1745 20 Maguire Road
1746 Lexington, MA 02173-3104
1748 EMail: geoffrey.clemm@us.ibm.com
1750 C. Fay
1751 FileNet Corporation
1752 3565 Harbor Boulevard
1753 Costa Mesa, CA 92626-1420
1755 EMail: cfay@filenet.com
1757 J. Crawford
1758 IBM Research
1759 P.O. Box 704
1760 Yorktown Heights, NY 10598
1762 EMail: ccjason@us.ibm.com
1764 Julian F. Reschke (editor)
1765 greenbytes GmbH
1766 Salzmannstrasse 152
1767 Muenster, NW 48159
1768 Germany
1770 Phone: +49 251 2807760
1771 Fax: +49 251 2807761
1772 EMail: julian.reschke@greenbytes.de
1773 URI: http://greenbytes.de/tech/webdav/
1775 Appendix A. Changes to the WebDAV Document Type Definition
1777
1778
1779 Property Elements from Section 12 -->
1780
1781
1782
1783
1786 Appendix B. Change Log
1788 B.1 Since draft-ietf-webdav-redirectref-protocol-02
1790 Julian Reschke takes editorial role (added to authors list). Cleanup
1791 XML indentation. Start adding all unresolved last call issues. Update
1792 some author's contact information. Update references, split into
1793 "normative" and "informational". Remove non-RFC2616 headers
1794 ("Public") from examples. Fixed width problems in artwork. Start
1795 resolving editorial issues.
1797 Appendix C. Resolved issues
1799 Issues that were either rejected or resolved in this version of this
1800 document.
1802 C.1 lc-11-pagination
1804 Type: change
1806 [3]
1808 reuterj@ira.uka.de (2000-02-07): Don't paginate the review draft.
1810 Resolution: We will paginate in accordance with IETF rules, but will
1811 try to produce a nicely formatted review spec as well.
1813 C.2 lc-09-notational-after-introduction
1815 Type: change
1817 [4]
1819 reuterj@ira.uka.de (2000-02-07): Move Notational Conventions after
1820 Introduction.
1822 Resolution: Section will be moved.
1824 C.3 lc-13-usually
1826 Type: change
1828 [5]
1830 reuterj@ira.uka.de (2000-02-07): Intro, para 4: Change "usually" to
1831 "possibly" in the sentence "A redirect reference resource is a
1832 resource in one collection whose purpose is to forward requests to
1833 another resource (its target), usually in a different collection."
1835 Resolution: Agreed.
1837 C.4 lc-16-insure
1839 Type: change
1841 [6]
1843 reuterj@ira.uka.de (2000-02-07): Section 4, para 2: Change "It is
1844 also what insures" to "It is also what helps to insure".
1846 Resolution: Agreed.
1848 C.5 lc-17-location
1850 Type: change
1852 [7]
1854 reuterj@ira.uka.de (2000-02-07): Section 4, para 3: Clients should
1855 use the Location header, not the DAV:reftarget property, to find the
1856 location of the target. The purpose of the DAV:reftarget property
1857 should be to let the client update its value.
1859 Resolution: We need both Location (which is absolute) and target
1860 (which may be relative). See also issue 6, 43.
1862 C.6 lc-21-bind
1864 Type: change
1866 [8]
1868 reuterj@ira.uka.de (2000-02-07): Get rid of the binding-dependent
1869 language in the last para of Section 5.
1871 Resolution: Delete all but the first sentence in this paragraph.
1873 C.7 lc-46-bind
1875 Type: change
1877 [9]
1879 yarong@Exchange.Microsoft.com (2000-02-11): Remove dependency on
1880 bindings from second paragraph of section 5.
1882 Resolution: Agreed.
1884 C.8 lc-26-lang
1886 Type: edit
1888 [10]
1890 reuterj@ira.uka.de (2000-02-07): Change "is not created" to "was not
1891 created" in para 4 under Postconditions of MKRESOURCE.
1893 Resolution: Editor's discretion.
1895 C.9 lc-03-mkresource-response-cacheability
1897 Type: change
1899 [11]
1901 joe@orton.demon.co.uk (2000-01-26): Saying that responses to
1902 MKRESOURCE SHOULD NOT be cached suggests that there are sometimes
1903 good reasons to cache responses. Is this the case?
1905 Resolution: Responses to MKREF MUST NOT be cached.
1907 C.10 lc-02-status-codes
1909 Type: change
1911 [12]
1913 joe@orton.demon.co.uk (2000-01-29): List only new status codes for
1914 MKRESOURCE. Don't discuss previously-defined status codes.
1916 Resolution: Follow same practice as in binding spec: for existing
1917 status codes, describe new circumstances that might cause them. Make
1918 it clear that we are not redefining these codes.
1920 C.11 lc-27-lang
1922 Type: edit
1924 [13]
1926 reuterj@ira.uka.de (2000-02-07): Section 6: Change
1927 "non-referencing-aware clients" to "clients not aware of this
1928 protocol".
1930 Resolution: Editor's discretion.
1932 C.12 lc-30-headers
1934 Type: edit
1936 [14]
1938 reuterj@ira.uka.de (2000-02-07): Section 6, "When Apply-To-RR is used
1939 with GET or HEAD..." Either give a precise list of the headers that
1940 MUST be returned, or change MUST to SHOULD with the list of examples.
1942 Resolution: Delete "along with all HTTP headers that make sense for
1943 reference resources (for example, Cache-Control, Age, Etag, Expires,
1944 and Last-Modified)." See also issue 48.
1946 C.13 lc-32-ORDERPATCH
1948 Type: edit
1950 [15]
1952 reuterj@ira.uka.de (2000-02-07): Section 6. Don't talk about
1953 ORDERPATCH, since it hasn't been specified anywhere.
1955 Resolution: Agreed. See also issue 48.
1957 C.14 lc-51-repeat
1959 Type: change
1961 [16]
1963 yarong@Exchange.Microsoft.com (2000-02-11): The first sentence of
1964 this paragraph says only what's clear from RFC 2518, so will cause
1965 confusion by its presence. Delete it. The last sentence of this
1966 paragraph lists methods. That's a bad idea. Remove it.
1968 Resolution: Delete entire paragraph.
1970 C.15 lc-59-depth
1972 Type: change
1974 [17]
1976 reuterj@ira.uka.de (2000-02-14): Section 7: When a method is being
1977 applied to a collection with Depth > 0, let Apply-To-Redirect-Ref
1978 contain a list of URIs. This way you could have it apply to some
1979 subset of the redirect references in the collection.
1981 Resolution: Declined. Too complex, no use case for it.
1983 C.16 lc-65-lock
1985 Type: change
1987 [18]
1989 reuterj@ira.uka.de (2000-02-14): "In the case of a redirect reference
1990 resource, I think the intended meaning of WebDAV is that the resource
1991 itself is the internal member to be locked, not the target resource.
1992 In so far, I think, the Apply-To-Redirect-Ref header should
1993 implicitly always be set, and a LOCK request for a collection MUST
1994 fail if in the hierarchy of collections there is an ordinary redirect
1995 reference as internal member."
1997 Resolution: Declined. Behavior will be the same for all methods. No
1998 exceptions. Consistency / simplicity override other considerations
2000 C.17 lc-66-depth
2002 Type: change
2004 [19]
2006 reuterj@ira.uka.de (2000-02-14): 7.3, 7.4: Change "Depth=infinity" to
2007 "Depth: infinity".
2009 Resolution: Agreed.
2011 C.18 lc-69-424
2013 Type: change
2015 [20]
2017 reuterj@ira.uka.de (2000-02-14): 7.6: Thinks there should not be 424
2018 returned for diary.html because it is not an ancestor of a member
2019 that caused the lock to fail.
2021 Resolution: No change needed. The interpretation of "dependency" in
2022 the example is correct. It doesn't have to do with ancestor
2023 relationship, only with what caused operation to fail.
2025 C.19 lc-68-lock
2027 Type: change
2029 [21]
2031 reuterj@ira.uka.de (2000-02-14): 7.6: The LOCK example responds with
2032 207, as does the example in RFC 2518, but section 8.10.4 of RFC 2518
2033 says if the lock cannot be granted to all resources the response MUST
2034 be 409 conflict.
2036 Resolution: We'll keep 207 and encourage RFC 2518 to say the same.
2037 (This inconsistency in RFC 2518 is on the WebDAV issues list.)
2039 C.20 lc-52-no-relative
2041 Type: change
2043 [22]
2045 yarong@Exchange.Microsoft.com (2000-02-11): Don't allow relative
2046 URIs. Delete section 9.
2048 Resolution: Declined. Some applications need relative URI.
2050 C.21 lc-64-reftarget
2052 Type: change
2054 [23]
2056 reuterj@ira.uka.de (2000-02-14): Perhaps make DAV:location a real
2057 property, instead of DAV:reftarget, and require it to be an absolute
2058 URI.
2060 Resolution: Declined. Some applications need relative URI. See also
2061 issue 52.
2063 C.22 lc-70-relative
2065 Type: change
2067 [24]
2069 reuterj@ira.uka.de (2000-02-14): Section 9, para 1: Maybe say that
2070 the resulting absolute URI could be any of a number of URIs,
2071 depending on which URI is used in the request to identify the
2072 redirect reference.
2074 Resolution: No change needed.
2076 C.23 lc-73-asciiart
2078 Type: change
2080 [25]
2082 reuterj@ira.uka.de (2000-02-14): Section 10: Replace the ascii art
2083 with Juergen's suggestion (see his message).
2085 Resolution: Replace.
2087 C.24 lc-77-webdav-applications
2089 Type: change
2091 [26]
2093 reuterj@ira.uka.de (2000-02-22): Section 16: Change "WebDAV
2094 applications" to "applications that implement this protocol".
2096 C.25 lc-10-title
2098 Type: change
2100 [27]
2102 reuterj@ira.uka.de (2000-02-07): Change the title of 16.4 so that it
2103 is not a sentence.
2105 Resolution: Change to "Revealing Private Locations".
2107 C.26 lc-81-typo
2109 Type: change
2111 [28]
2113 reuterj@ira.uka.de (2000-02-22): Section 17: Typo "As in [WebDAV}"
2115 Resolution: Fixed.
2117 C.27 lc-18-resource-types
2119 Type: change
2121 [29]
2123 reuterj@ira.uka.de (2000-02-07): Need a registration procedure for
2124 resource types to insure interoperability.
2126 Resolution: We won't hold up this spec to establish a registration
2127 procedure. We will mention in IANA considerations that as the number
2128 of resource types grows the need for a registration procedure
2129 increases, but that there is none at this time.
2131 C.28 lc-84-ext
2133 Type: change
2135 [30]
2137 reuterj@ira.uka.de (2000-02-22): Appendix 24.1: This is not an
2138 extension but a replacement for the WebDAV definition of the response
2139 element.
2141 Resolution: Fixed.
2143 Appendix D. Open issues
2145 D.1 lc-85-301
2147 Type: change
2149 ejw@cse.ucsc.edu (2000-01-03): Support creation of other than 302
2150 redirects, especially 301.
2152 D.2 lc-07-bind
2154 Type: change
2156 [31]
2158 reuterj@ira.uka.de (2000-02-07): Abstract should discuss only
2159 redirect references, not bindings. Expand discussion of redirect
2160 references.
2162 Resolution: Abstract will discuss only redirect references. See also
2163 issue 34.
2165 D.3 lc-08-bind
2167 Type: change
2169 [32]
2171 reuterj@ira.uka.de (2000-02-07): Get rid of cross-references to the
2172 binding spec: in the abstract, in the introduction, in the definition
2173 of Reference Resource.
2175 Resolution: Cross-references to bindings will be removed. See also
2176 issue 34.
2178 D.4 lc-34-bind
2180 Type: change
2182 [33]
2184 yarong@Exchange.Microsoft.com (2000-02-11): NoBind: Remove all
2185 cross-references to the binding spec. Prefer also removing all
2186 mention of bindings.
2188 Resolution: Agreed. See also issues 7, 8, 14
2190 D.5 lc-35-bind
2192 Type: change
2194 [34]
2196 yarong@Exchange.Microsoft.com (2000-02-11): ReallyNoBind: Remove
2197 paras. 6 and 8 from Intro.
2199 Resolution: Agreed. See also issue 14.
2201 D.6 lc-83-bind
2203 Type: change
2205 [35]
2207 reuterj@ira.uka.de (2000-02-22): References: Get rid of the reference
2208 to the bindings spec.
2210 D.7 lc-12-bind
2212 Type: change
2214 [36]
2216 reuterj@ira.uka.de (2000-02-07): First 3 paragraphs of Introduction
2217 are identical to those in binding spec. Make sure that any changes
2218 made there are also incorporated here.
2220 Resolution: These paragraphs will change as necessary to make the
2221 redirect spec completely independent of the rest of WebDAV.
2223 D.8 lc-38-not-hierarchical
2225 Type: change
2227 [37]
2229 yarong@Exchange.Microsoft.com (2000-02-11): Not Hierarchical: The
2230 first sentence of the second paragraph of the introduction of the
2231 redirect spec asserts that the URIs of WebDAV compliant resources
2232 match to collections. The WebDAV standard makes no such requirement.
2233 I therefore move that this sentence be stricken.
2235 Resolution: State the more general HTTP rationale first (alternative
2236 names for the same resource), then introduce the collection hierarchy
2237 rationale, which applies only if you are in a WebDAV-compliant space.
2239 D.9 lc-36-server
2241 Type: change
2243 [38]
2245 yarong@Exchange.Microsoft.com (2000-02-11): Servers: Replace "server"
2246 with "unrelated system" throughout.
2248 Resolution: Try replacing "server" with "host" in some contexts,
2249 rephrasing in passive voice in others. See also issue 40.
2251 D.10 lc-33-forwarding
2253 Type: change
2255 [39]
2257 yarong@Exchange.Microsoft.com (2000-02-11): Forwarding: Replace
2258 "forward" with "redirect" throughout.
2260 Resolution: Use "redirect" for the behavior redirect resources do
2261 exhibit. Use "forward" for the contrasting behavior (passing a method
2262 on to the target with no client action needed). Define these two
2263 terms. See also issue 40.
2265 D.11 lc-56-notjusthttp
2267 Type: change
2269 [40]
2271 yarong@Exchange.Microsoft.com (2000-02-11): Make it clear in examples
2272 and text that the redirection URI could be non-HTTP.
2274 Resolution: We agree that it is possible to create redirect
2275 references to non-HTTP resources. Add example.
2277 D.12 lc-01-body
2279 Type: change
2281 [41]
2283 joe@orton.demon.co.uk (2000-01-26): Entity Bodies for Redirect
2284 References: Clarify: Are there 2 resources, one that redirects and
2285 one that responds with its own entity body? Clarify: What is the
2286 effect of PUT for a URI that currently maps to a redirect reference?
2287 Resolution: Redirect resource MUST NOT have a body. See also issue
2288 last call issue 23.
2290 D.13 lc-37-integrity
2292 Type: change
2294 [42]
2296 yarong@Exchange.Microsoft.com (2000-02-11): Integrity: Intro, para 7
2297 "Servers are not required to enforce the integrity of redirect
2298 references." Integrity is not defined. Replace with something
2299 clearer.
2301 Resolution: Rewrite to say that the server MUST NOT update the target
2302 See also issue 6.
2304 D.14 lc-14-bind
2306 Type: change
2308 [43]
2310 reuterj@ira.uka.de (2000-02-07): Limit the discussion of bindings to
2311 just what is needed to understand the differences from redirect
2312 references. Maybe the paragraph in the Intro that starts "By
2313 contrast, a BIND request . . ." is all that is needed.
2315 Resolution: Get rid of discussion of bindings altogether. See also
2316 issue 34, 35.
2318 D.15 lc-15-direct-ref
2320 Type: change
2322 [44]
2324 reuterj@ira.uka.de (2000-02-07): Don't define Direct Reference
2325 Resource, since direct references are out of scope. (If you do keep
2326 the definition, say explicitly that a direct reference resource is a
2327 type of reference resource.)
2329 Resolution: Remove definition of Direct Reference Resource. See also
2330 issue 39.
2332 D.16 lc-39-no-reference-or-direct-resource
2334 Type: change
2336 [45]
2338 yarong@Exchange.Microsoft.com (2000-02-11):
2339 NoReferenceOrDirectResource: Remove the definitions of "Reference"
2340 and "Direct Reference Resource." Change the definition of "Redirect
2341 Reference Resource" to be: Redirect Resource: A resource created to
2342 redirect all requests made to it, using 302 (Found), to a defined
2343 target resource.
2345 Resolution: Agreed. See also issue 15.
2347 D.17 lc-40-direct
2349 Type: change
2351 [46]
2353 yarong@Exchange.Microsoft.com (2000-02-11): Assorted changes to
2354 Section 4, para 2 to get rid of the word "forward" and the word
2355 "server" and remove comparison with direct references.
2357 Resolution: See also issue 33 (forward). See also issue 36 (server).
2358 Remove discussion of direct references.
2360 D.18 lc-43-webdav
2362 Type: change
2364 [47]
2366 yarong@Exchange.Microsoft.com (2000-02-11): Get rid of the
2367 DAV:reftarget property.
2369 Resolution: DAV:reftarget is readonly and is present only for
2370 redirect references that are also WebDAV resources. We'll also have a
2371 method for setting target; Redirect-Ref header (returned on all 302
2372 responses) will have the target as its value. See also issue 6, 17,
2373 50.
2375 D.19 lc-19-direct-ref
2377 Type: change
2379 [48]
2381 reuterj@ira.uka.de (2000-02-07): Section 4, para 5 and Section 6,
2382 para 3 discussions of the Apply-to-Redirect-Ref header make it sound
2383 as if we are specifying direct reference behavior.
2385 Resolution: Change these passages so that the contrast is between
2386 applying the method to the redirect reference and responding with a
2387 302.
2389 D.20 lc-45-apply-to-rr
2391 Type: change
2393 [49]
2395 yarong@Exchange.Microsoft.com (2000-02-11): Suggested replacement
2396 text for this paragraph, which briefly introduces
2397 Apply-To-Redirect-Ref. Includes a note that even with this header,
2398 the response may be a 302.
2400 Resolution: See issue 19 for replacement text. Disagree. Redirect
2401 reference will never respond to Apply-To-RR with 302.
2403 D.21 lc-04-standard-data-container
2405 Type: change
2407 [50]
2409 joe@orton.demon.co.uk (2000-01-26): "Standard data container" needs
2410 to be defined in the context of MKRESOURCE
2412 Resolution: Not relevant once we switch to MKREF.
2414 D.22 lc-05-standard-data-container
2416 Type: change
2418 [51]
2420 joe@orton.demon.co.uk (2000-01-26): Inconsistency about whether a
2421 "standard data container" can be created with MKRESOURCE or not.
2423 Resolution: Not relevant once we switch to MKREF.
2425 D.23 lc-20-intro-mkresource
2427 Type: change
2429 [52]
2431 reuterj@ira.uka.de (2000-02-07): Section 5: Start with "The new
2432 MKRESOURCE method" to make it clear that it is being introduced for
2433 the first time here.
2435 Resolution: Say "The MKREF method defined normatively here . . ."
2437 D.24 lc-22-coll
2439 Type: change
2441 [53]
2443 reuterj@ira.uka.de (2000-02-07): Inconsistency about whether
2444 collections can be created with MKRESOURCE.
2446 Resolution: Not relevant for MKREF.
2448 D.25 lc-25-atomic
2450 Type: change
2452 [54]
2454 reuterj@ira.uka.de (2000-02-07): Is MKRESOURCE atomic as viewed by a
2455 client? Can another client access the new resource's properties
2456 before they have been fully initialized? Maybe the MKRESOURCE request
2457 should let the client ask for it to be atomic.
2459 Resolution: No longer relevant once we switch to MKREF with no
2460 request body.
2462 D.26 lc-41-no-webdav
2464 Type: change
2466 [55]
2468 yarong@Exchange.Microsoft.com (2000-02-11): Make redirect references
2469 independent of the rest of WebDAV. The creation method for redirect
2470 references shouldn't require an XML request body.
2472 Resolution: We will make redirect references independent of the rest
2473 of WebDAV. MKREF will not have an XML request body.
2475 D.27 lc-42-no-webdav
2477 Type: change
2479 [56]
2480 yarong@Exchange.Microsoft.com (2000-02-11): Use a creation method
2481 that creates only redirect references. The MKRESOURCE method hinders
2482 experiment because a user of a server who wishes to add support for
2483 the creation of a new resource type can't simply throw in another
2484 Apache module and allow it to provide the code for the new resource
2485 type. They have to find the code used for MKRESOURCE and change it to
2486 support the new resource type.
2488 Resolution: We will replace MKRESOURCE with MKREF, which creates only
2489 redirect reference resources.
2491 D.28 lc-58-update
2493 Type: change
2495 [57]
2497 yarong@Exchange.Microsoft.com (2000-02-11): There needs to be a way
2498 to update the target of a redirect reference.
2500 Resolution: Agreed. See also issues 6, 43.
2502 D.29 lc-01A-body
2504 Type: change
2506 [58]
2508 joe@orton.demon.co.uk (2000-01-26): In the definition of MKRESOURCE,
2509 "Body" needs to be defined or else terminology changed.
2511 Resolution: We will use MKREF instead of MKRESOURCE.
2513 D.30 lc-23-body
2515 Type: change
2517 [59]
2519 reuterj@ira.uka.de (2000-02-07): Section 5.1: Get rid of the
2520 statement that the body of the resource is empty (PostConditions). It
2521 would be good if the response to GET included a response body that
2522 could be shown to a user by a client that doesn't do automatic
2523 redirection. There is a related problem in Section 6 on PUT. It is
2524 wrong to assume that what is PUT to a resource is what GET will
2525 return. In Section 6, say "A PUT with Apply-To-RR MAY contain a
2526 request body. The semantics of the request body is out of scope for
2527 this specification..." Also fix the discussion of example 6.2.
2529 Resolution: Redirect references cannot have bodies. GET with
2530 Apply-To-RR MUST fail with 403. PUT with Apply-To-RR MUST fail with
2531 403. See also issue 1.
2533 D.31 lc-24-properties
2535 Type: change
2537 [60]
2539 reuterj@ira.uka.de (2000-02-07): Section 5.1: Replace the sentence
2540 "The properties of the new resource are as specified by the
2541 DAV:propertyupdate request body, using PROPPATCH semantics" with the
2542 following: "The MKRESOURCE request MAY contain a DAV:propertyupdate
2543 request body to initialize resource properties. Herein, the semantics
2544 is the same as when sending a MKRESOURCE request without a request
2545 body, followed by a PROPPATCH with the DAV:propertyupdate request
2546 body."
2548 Resolution: No longer relevant once we switch to MKREF with no
2549 request body.
2551 D.32 lc-47-207
2553 Type: change
2555 [61]
2557 yarong@Exchange.Microsoft.com (2000-02-11): In line with his wish to
2558 get rid of the request message body of MKRESOURCE, 207 would not be
2559 an appropriate response code. The description of 409 might lead
2560 someone to believe that you can't create redirect references outside
2561 of WebDAV namespaces. Suggests a different description.
2563 Resolution: No longer relevant - MKREF can't get a 207 response.
2564 Revise to make it clear that the first condition will only occur in
2565 WebDAV-compliant namespaces.
2567 D.33 lc-48-s6
2569 Type: change
2571 [62]
2573 yarong@Exchange.Microsoft.com (2000-02-11): Replace all of section 6
2574 with just this: A redirect resource, upon receiving a request without
2575 an Apply-To-Redirect-Ref header, MUST respond with a 302 (Found)
2576 response. The 302 (Found) response MUST include a location header
2577 identifying the target and a Redirect-Ref header. If a redirect
2578 resource receives a request with an Apply-To-Redirect-Ref header then
2579 the redirect reference resource MUST apply the method to itself
2580 rather than blindly returning a 302 (Found) response.
2582 Resolution: Keep a summary along the lines of Yaron's proposal (don't
2583 use the word "blindly"). Keep the bullets detailing the headers to be
2584 returned. Delete the rest, including the examples. See also issue 28,
2585 29, 30, 31, 32.
2587 D.34 lc-28-lang
2589 Type: edit
2591 [63]
2593 reuterj@ira.uka.de (2000-02-07): Section 6: Get rid of the sentence
2594 "A reference-aware WebDAV client can act on this response in one of
2595 two ways." A client can act on the response in any way it wants.
2597 Resolution: Agreed. See also issue 48.
2599 D.35 lc-29-lang
2601 Type: edit
2603 [64]
2605 reuterj@ira.uka.de (2000-02-07): Section 6, para 4: Obvious, doesn't
2606 need to be stated. Maybe note in an example.
2608 Resolution: Agreed. See also issue 48.
2610 D.36 lc-31-MKCOL
2612 Type: edit
2614 [65]
2616 reuterj@ira.uka.de (2000-02-07): Section 6, para on MKRESOURCE and
2617 MKCOL is obvious and doesn't need to be stated. Maybe show in an
2618 example.
2620 Resolution: Agreed. See also issue 48.
2622 D.37 lc-49-put
2624 Type: change
2626 [66]
2628 yarong@Exchange.Microsoft.com (2000-02-11): Remove the last sentence
2629 of Example 6.2, which says that PUT replaces the reference with a
2630 different resource.
2632 Resolution: No longer relevant. Deleted this example in response to
2633 issue 48.
2635 D.38 lc-44-pseudo
2637 Type: change
2639 [67]
2641 yarong@Exchange.Microsoft.com (2000-02-11): Instead of adding an
2642 optional prop XML element to the response element in 207 responses,
2643 define a new location XML element and a new refresource XML element.
2645 Resolution: Agree to define new XML elements that are not
2646 pseudo-properties. Disagreement about whether refresource is needed.
2647 See issue 61.
2649 D.39 lc-61-pseudo
2651 Type: change
2653 [68]
2655 reuterj@ira.uka.de (2000-02-14): Section 7: It doesn't make sense to
2656 ask future editors of RFC 2518 to define DAV:location with the
2657 semantics it has here. RFC 2518 should provide the information in the
2658 Location header somehow in multistatus responses, but not by using
2659 properties.
2661 Resolution: Define an XML element for location that is not a
2662 pseudo-property. We'll keep the recommendation that RFC 2518 add this
2663 for 302 responses. See also issue 44.
2665 D.40 lc-60-ex
2667 Type: change
2669 [69]
2671 reuterj@ira.uka.de (2000-02-14): Section 7, para 3: Make it clear
2672 that these are just examples of client behavior, and are not meant to
2673 limit the client's behavior to these options.
2675 Resolution: Agreed to delete this paragraph. Continue discussion of
2676 what information should be returned with 302 in multistatus. Just
2677 location? Also redirectref?
2679 D.41 lc-62-oldclient
2681 Type: change
2683 [70]
2685 reuterj@ira.uka.de (2000-02-14): Section 7: It's too strong to claim
2686 that non-referencing clients can't process 302 responses occurring in
2687 Multi-Status responses. They just have an extra round trip for each
2688 302.
2690 Resolution: Remove last sentence of the paragraph that recommends
2691 changes to RFC 2518.
2693 D.42 lc-63-move
2695 Type: change
2697 [71]
2699 reuterj@ira.uka.de (2000-02-14): Section 7.1: Is MOVE atomic from the
2700 perspective of a client? Agrees that there should be no 302s for
2701 member redirect references, but finds the rationale dubious.
2703 Resolution: Remove 7.1. Reword 7.2 to avoid concerns with "poses
2704 special problems" and "due to atomicity".
2706 D.43 lc-67-redirectref
2708 Type: change
2710 [72]
2712 reuterj@ira.uka.de (2000-02-14): 7.4: The explanation should not
2713 contrast displaying the properties of the redirect ref with
2714 displaying the properties of its target, but with returning a 302.
2716 Resolution: Revise as recommended.
2718 D.44 lc-06-reftarget-relative
2720 Type: change
2722 [73]
2723 joe@orton.demon.co.uk (2000-01-29): Why does the spec talk about
2724 relative URIs in DAV:reftarget in MKRESOURCE requests? Is the server
2725 required to resolve the relative URI and store it as absolute? Is the
2726 server required to keep DAV:reftarget pointing to the target resource
2727 as the reference / target move, or is DAV:reftarget a dead property?
2729 Resolution: DAV:reftarget is readonly and present only on redirect
2730 references that are also WebDAV resources. Add a method for setting
2731 the target. Change definition of Redirect-Ref header so that it has
2732 the target as its value (comes back on all 302 responses). Server
2733 MUST store the target exactly as it is set. It MUST NOT resolve
2734 relatives to absolutes and MUST NOT update if target resource moves.
2735 See also issue 17, 43, 50, 57
2737 D.45 lc-57-noautoupdate
2739 Type: change
2741 [74]
2743 yarong@Exchange.Microsoft.com (2000-02-11): Add language to forbid
2744 servers from automatically updating redirect resources when their
2745 targets move.
2747 Resolution: Agreed. See also issue 6.
2749 D.46 lc-71-relative
2751 Type: change
2753 [75]
2755 reuterj@ira.uka.de (2000-02-14): Section 9: Base URI should be the
2756 Request-URI or href minus its final segment.
2758 Resolution: Fix this.
2760 D.47 lc-53-s10
2762 Type: change
2764 [76]
2766 yarong@Exchange.Microsoft.com (2000-02-11): The behavior described in
2767 this section would have a very serious impact on the efficiency of
2768 mapping Request-URIs to resources in HTTP request processing. Also
2769 specify another type of redirect resource that does not behave as in
2770 section 10, but instead would "expose the behavior we see today in
2771 various HTTP servers that allow their users to create 300 resources."
2772 Be sure we know what behavior will be if the redirect location is not
2773 an HTTP URL, but, say ftp.
2775 Resolution: We won't define 2 sorts of redirect references here.
2776 Servers SHOULD respond with 302 as described here, but if they can't
2777 do that, respond with 404 Not Found. (It's hard to modularize the
2778 behavior specified - it impacts processing Not Found cases of all
2779 methods, so you can't just add it to an HTTP server in a redirect ref
2780 module.)
2782 D.48 lc-72-trailingslash
2784 Type: change
2786 [77]
2788 reuterj@ira.uka.de (2000-02-14): Section 10: Forbid DAV:reftarget
2789 from ending in "/"
2791 Resolution: Make the note warn about the possibility of two slashes
2792 in a row, recommend against ending target with a slash, since that
2793 could result in two slashes in a row.
2795 D.49 lc-54-s10
2797 Type: change
2799 [78]
2801 yarong@Exchange.Microsoft.com (2000-02-11): The Note: in section 10
2802 has the same problem pointed out in Bindings.NoSlash and needs to be
2803 fixed. It contradicts RFC 2518 and 2616, which both assume that a URL
2804 and the same URL + "/" may map to different resources.
2806 Resolution: Agreed in mailing list discussions that no change is
2807 needed.
2809 D.50 lc-50-blindredirect
2811 Type: change
2813 [79]
2815 yarong@Exchange.Microsoft.com (2000-02-11): Replace current language
2816 explaining the purpose of the Redirect-Ref header with language that
2817 simply states that it marks blind 302 responses from redirect
2818 resources. (Section 6.3, 11.1)
2819 Resolution: Section 6.3 was removed in response to issue 48. In 11.1,
2820 change the definition of the Redirect-Ref header to have the value of
2821 the target (relative URI) as its value. Then we don't need a method
2822 for retrieving the target's relative URI. Presence of the
2823 Redirect-Ref header lets the client know that the resource accepts
2824 Apply-To-RR header and the new method for updating target. Reject
2825 Yaron's suggested language, but make the above changes.
2827 D.51 lc-74-terminology
2829 Type: change
2831 [80]
2833 reuterj@ira.uka.de (2000-02-14): "plain HTTP/1.1 redirect" - find
2834 some good name for this an use it consistently
2836 D.52 lc-75-ignore
2838 Type: change
2840 [81]
2842 reuterj@ira.uka.de (2000-02-14): 11.2: "If the Apply-To-Redirect-Ref
2843 header is used on a request to any other sort of resource besides a
2844 redirect reference resource, the server SHOULD ignore it." Don't need
2845 to say this since HTP already says that any header that is not
2846 understood should be ignored.
2848 D.53 lc-76-location
2850 Type: change
2852 [82]
2854 reuterj@ira.uka.de (2000-02-22): 12.2: Make DAV:location a real
2855 (live) property, get rid of the DAV:reftarget property
2857 D.54 lc-78-directory
2859 Type: change
2861 [83]
2863 reuterj@ira.uka.de (2000-02-22): Section 16.4: Change "directory" to
2864 "collection". Not new to this protocol. Holds for any protocol that
2865 has hierarchical access paths.
2867 D.55 lc-79-accesscontrol
2869 Type: change
2871 [84]
2873 reuterj@ira.uka.de (2000-02-22): Section 16.4: "In some environments,
2874 the owner of a resource might be able to use access control to
2875 prevent others from creating references to that resource." That would
2876 not be consistent with the concept of redirect references as weak
2877 links (e.g. think of moving a resource to a different locationo that
2878 is already the target of some redirection reference.
2880 D.56 lc-80-i18n
2882 Type: change
2884 [85]
2886 reuterj@ira.uka.de (2000-02-22): Section 17: Could get rid of a lot
2887 of this section, since this protocol extends WebDAV. Just reference
2888 [WebDAV].
2890 D.57 lc-55-iana
2892 Type: change
2894 [86]
2896 yarong@Exchange.Microsoft.com (2000-02-11): Expand the IANA section
2897 to list all methods, headers, XML elements, MIME types, URL schemes,
2898 etc., defined by the spec.
2900 Resolution: Agreed.
2902 D.58 lc-82-iana
2904 Type: change
2906 [87]
2908 reuterj@ira.uka.de (2000-02-22): Section 18: Just reference [WebDAV]
2909 and say this protocol does not introduce any new considerations.
2911 Intellectual Property Statement
2913 The IETF takes no position regarding the validity or scope of any
2914 intellectual property or other rights that might be claimed to
2915 pertain to the implementation or use of the technology described in
2916 this document or the extent to which any license under such rights
2917 might or might not be available; neither does it represent that it
2918 has made any effort to identify any such rights. Information on the
2919 IETF's procedures with respect to rights in standards-track and
2920 standards-related documentation can be found in BCP-11. Copies of
2921 claims of rights made available for publication and any assurances of
2922 licenses to be made available, or the result of an attempt made to
2923 obtain a general license or permission for the use of such
2924 proprietary rights by implementors or users of this specification can
2925 be obtained from the IETF Secretariat.
2927 The IETF invites any interested party to bring to its attention any
2928 copyrights, patents or patent applications, or other proprietary
2929 rights which may cover technology that may be required to practice
2930 this standard. Please address the information to the IETF Executive
2931 Director.
2933 Full Copyright Statement
2935 Copyright (C) The Internet Society (2003). All Rights Reserved.
2937 This document and translations of it may be copied and furnished to
2938 others, and derivative works that comment on or otherwise explain it
2939 or assist in its implementation may be prepared, copied, published
2940 and distributed, in whole or in part, without restriction of any
2941 kind, provided that the above copyright notice and this paragraph are
2942 included on all such copies and derivative works. However, this
2943 document itself may not be modified in any way, such as by removing
2944 the copyright notice or references to the Internet Society or other
2945 Internet organizations, except as needed for the purpose of
2946 developing Internet standards in which case the procedures for
2947 copyrights defined in the Internet Standards process must be
2948 followed, or as required to translate it into languages other than
2949 English.
2951 The limited permissions granted above are perpetual and will not be
2952 revoked by the Internet Society or its successors or assignees.
2954 This document and the information contained herein is provided on an
2955 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
2956 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
2957 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
2958 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
2959 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2961 Acknowledgment
2963 Funding for the RFC Editor function is currently provided by the
2964 Internet Society.