idnits 2.17.1
draft-ietf-webdav-redirectref-protocol-04.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], [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 (September 10, 2003) is 7535 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 2405, 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'
-- Possible downref: Non-RFC (?) normative reference: ref. '1'
-- Possible downref: Non-RFC (?) normative reference: ref. '2'
-- Possible downref: Non-RFC (?) normative reference: ref. '3'
-- Possible downref: Non-RFC (?) normative reference: ref. '4'
-- Possible downref: Non-RFC (?) normative reference: ref. '5'
-- Possible downref: Non-RFC (?) normative reference: ref. '6'
-- Possible downref: Non-RFC (?) normative reference: ref. '7'
-- Possible downref: Non-RFC (?) normative reference: ref. '8'
-- Possible downref: Non-RFC (?) normative reference: ref. '9'
-- Possible downref: Non-RFC (?) normative reference: ref. '10'
-- Possible downref: Non-RFC (?) normative reference: ref. '11'
-- Possible downref: Non-RFC (?) normative reference: ref. '12'
-- Possible downref: Non-RFC (?) normative reference: ref. '13'
-- Possible downref: Non-RFC (?) normative reference: ref. '14'
-- Possible downref: Non-RFC (?) normative reference: ref. '15'
-- Possible downref: Non-RFC (?) normative reference: ref. '16'
-- Possible downref: Non-RFC (?) normative reference: ref. '17'
-- Possible downref: Non-RFC (?) normative reference: ref. '18'
-- Possible downref: Non-RFC (?) normative reference: ref. '19'
-- Possible downref: Non-RFC (?) normative reference: ref. '20'
-- Possible downref: Non-RFC (?) normative reference: ref. '21'
-- Possible downref: Non-RFC (?) normative reference: ref. '22'
-- Possible downref: Non-RFC (?) normative reference: ref. '23'
-- Possible downref: Non-RFC (?) normative reference: ref. '24'
-- Possible downref: Non-RFC (?) normative reference: ref. '25'
-- Possible downref: Non-RFC (?) normative reference: ref. '26'
-- Possible downref: Non-RFC (?) normative reference: ref. '27'
-- Possible downref: Non-RFC (?) normative reference: ref. '28'
-- Possible downref: Non-RFC (?) normative reference: ref. '29'
-- Possible downref: Non-RFC (?) normative reference: ref. '30'
-- Possible downref: Non-RFC (?) normative reference: ref. '31'
-- Possible downref: Non-RFC (?) normative reference: ref. '32'
-- Possible downref: Non-RFC (?) normative reference: ref. '33'
-- Possible downref: Non-RFC (?) normative reference: ref. '34'
-- Possible downref: Non-RFC (?) normative reference: ref. '35'
-- Possible downref: Non-RFC (?) normative reference: ref. '36'
-- Possible downref: Non-RFC (?) normative reference: ref. '37'
-- Possible downref: Non-RFC (?) normative reference: ref. '38'
-- Possible downref: Non-RFC (?) normative reference: ref. '39'
-- Possible downref: Non-RFC (?) normative reference: ref. '40'
-- Possible downref: Non-RFC (?) normative reference: ref. '41'
-- Possible downref: Non-RFC (?) normative reference: ref. '42'
-- Possible downref: Non-RFC (?) normative reference: ref. '43'
-- Possible downref: Non-RFC (?) normative reference: ref. '44'
-- Possible downref: Non-RFC (?) normative reference: ref. '45'
-- Possible downref: Non-RFC (?) normative reference: ref. '46'
-- Possible downref: Non-RFC (?) normative reference: ref. '47'
-- Possible downref: Non-RFC (?) normative reference: ref. '48'
-- Possible downref: Non-RFC (?) normative reference: ref. '49'
-- Possible downref: Non-RFC (?) normative reference: ref. '50'
-- Possible downref: Non-RFC (?) normative reference: ref. '51'
-- Possible downref: Non-RFC (?) normative reference: ref. '52'
-- Possible downref: Non-RFC (?) normative reference: ref. '53'
-- Possible downref: Non-RFC (?) normative reference: ref. '54'
-- Possible downref: Non-RFC (?) normative reference: ref. '55'
-- Possible downref: Non-RFC (?) normative reference: ref. '56'
-- Possible downref: Non-RFC (?) normative reference: ref. '57'
-- Possible downref: Non-RFC (?) normative reference: ref. '58'
-- Possible downref: Non-RFC (?) normative reference: ref. '59'
-- Possible downref: Non-RFC (?) normative reference: ref. '60'
Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 63 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: March 10, 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 September 10, 2003
18 WebDAV Redirect Reference Resources
19 draft-ietf-webdav-redirectref-protocol-04
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 March 10, 2004.
43 Copyright Notice
45 Copyright (C) The Internet Society (2003). All Rights Reserved.
47 Abstract
49 This specification defines redirect reference resources. A redirect
50 reference resource is a resource whose default response is an HTTP/
51 1.1 302 (Found) status code, redirecting the client to a different
52 resource, the target resource. A redirect reference makes it
53 possible to access the target resource indirectly, through any URI
54 mapped to the redirect reference resource. There are no integrity
55 guarantees associated with redirect reference resources.
57 Distribution of this document is unlimited. Please send comments to
58 the Distributed Authoring and Versioning (WebDAV) working group at
59 w3c-dist-auth@w3.org [1], which may be joined by sending a message
60 with subject "subscribe" to w3c-dist-auth-request@w3.org [2].
62 Discussions of the WEBDAV working group are archived at URL: http://
63 lists.w3.org/Archives/Public/w3c-dist-auth/.
65 Table of Contents
67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
68 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 7
69 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 8
70 4. Overview of Redirect Reference Resources . . . . . . . . . . 9
71 5. Creating a Redirect Reference Resource . . . . . . . . . . . 10
72 5.1 MKRESOURCE . . . . . . . . . . . . . . . . . . . . . . . . . 10
73 5.2 Example: Creating a Redirect Reference Resource with
74 MKRESOURCE . . . . . . . . . . . . . . . . . . . . . . . . . 11
75 6. Operations on Redirect Reference Resources . . . . . . . . . 13
76 6.1 Example: GET on a Redirect Reference Resource . . . . . . . 14
77 6.2 Example: PUT on a Redirect Reference Resource with
78 Apply-To-Redirect-Ref . . . . . . . . . . . . . . . . . . . 14
79 6.3 Example: PROPPATCH on a Redirect Reference Resource . . . . 15
80 7. Operations on Collections That Contain Redirect Reference
81 Resources . . . . . . . . . . . . . . . . . . . . . . . . . 16
82 7.1 MOVE and DELETE on Collections That Contain Redirect
83 References . . . . . . . . . . . . . . . . . . . . . . . . . 16
84 7.2 LOCK on a Collection That Contains Redirect References . . . 17
85 7.3 Example: PROPFIND on a Collection with Redirect Reference
86 Resources . . . . . . . . . . . . . . . . . . . . . . . . . 17
87 7.4 Example: PROPFIND with Apply-To-Redirect-Ref on a
88 Collection with Redirect Reference Resources . . . . . . . . 18
89 7.5 Example: COPY on a Collection That Contains a Redirect
90 Reference Resource . . . . . . . . . . . . . . . . . . . . . 20
91 7.6 Example: LOCK on a Collection That Contains a Redirect
92 Reference Resource . . . . . . . . . . . . . . . . . . . . . 21
93 8. Operations on Targets of Redirect Reference Resources . . . 24
94 9. Relative URIs in DAV:reftarget . . . . . . . . . . . . . . . 25
95 9.1 Example: Resolving a Relative URI in a MKRESOURCE Request . 25
96 9.2 Example: Resolving a Relative URI in a Multi-Status
97 Response . . . . . . . . . . . . . . . . . . . . . . . . . . 26
99 10. Redirect References to Collections . . . . . . . . . . . . . 28
100 11. Headers . . . . . . . . . . . . . . . . . . . . . . . . . . 30
101 11.1 Redirect-Ref Response Header . . . . . . . . . . . . . . . . 30
102 11.2 Apply-To-Redirect-Ref Request Header . . . . . . . . . . . . 30
103 12. Properties . . . . . . . . . . . . . . . . . . . . . . . . . 31
104 12.1 reftarget Property . . . . . . . . . . . . . . . . . . . . . 31
105 12.2 location Pseudo-Property . . . . . . . . . . . . . . . . . . 31
106 13. XML Elements . . . . . . . . . . . . . . . . . . . . . . . . 32
107 13.1 redirectref XML Element . . . . . . . . . . . . . . . . . . 32
108 14. Extensions to the DAV:response XML Element for
109 Multi-Status Responses . . . . . . . . . . . . . . . . . . . 33
110 15. Capability Discovery . . . . . . . . . . . . . . . . . . . . 34
111 15.1 Example: Discovery of Support for Redirect Reference
112 Resources . . . . . . . . . . . . . . . . . . . . . . . . . 34
113 16. Security Considerations . . . . . . . . . . . . . . . . . . 35
114 16.1 Privacy Concerns . . . . . . . . . . . . . . . . . . . . . . 35
115 16.2 Redirect Loops . . . . . . . . . . . . . . . . . . . . . . . 35
116 16.3 Redirect Reference Resources and Denial of Service . . . . . 35
117 16.4 Revealing Private Locations . . . . . . . . . . . . . . . . 35
118 17. Internationalization Considerations . . . . . . . . . . . . 37
119 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . 38
120 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
121 Normative References . . . . . . . . . . . . . . . . . . . . 40
122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 40
123 A. Changes to the WebDAV Document Type Definition . . . . . . . 42
124 B. Change Log (to be removed by RFC Editor before
125 publication) . . . . . . . . . . . . . . . . . . . . . . . . 43
126 B.1 Since draft-ietf-webdav-redirectref-protocol-02 . . . . . . 43
127 B.2 Since draft-ietf-webdav-redirectref-protocol-03 . . . . . . 43
128 C. Resolved issues (to be removed by RFC Editor before
129 publication) . . . . . . . . . . . . . . . . . . . . . . . . 44
130 C.1 lc-07-bind . . . . . . . . . . . . . . . . . . . . . . . . . 44
131 C.2 lc-08-bind . . . . . . . . . . . . . . . . . . . . . . . . . 44
132 C.3 lc-34-bind . . . . . . . . . . . . . . . . . . . . . . . . . 44
133 C.4 lc-83-bind . . . . . . . . . . . . . . . . . . . . . . . . . 44
134 C.5 lc-12-bind . . . . . . . . . . . . . . . . . . . . . . . . . 45
135 C.6 lc-35-bind . . . . . . . . . . . . . . . . . . . . . . . . . 45
136 C.7 lc-01-body . . . . . . . . . . . . . . . . . . . . . . . . . 45
137 C.8 lc-14-bind . . . . . . . . . . . . . . . . . . . . . . . . . 45
138 C.9 lc-15-direct-ref . . . . . . . . . . . . . . . . . . . . . . 46
139 C.10 lc-39-no-reference-or-direct-resource . . . . . . . . . . . 46
140 C.11 lc-40-direct . . . . . . . . . . . . . . . . . . . . . . . . 46
141 C.12 lc-45-apply-to-rr . . . . . . . . . . . . . . . . . . . . . 47
142 C.13 lc-01A-body . . . . . . . . . . . . . . . . . . . . . . . . 47
143 C.14 lc-31-MKCOL . . . . . . . . . . . . . . . . . . . . . . . . 47
144 C.15 lc-67-redirectref . . . . . . . . . . . . . . . . . . . . . 47
145 C.16 lc-54-s10 . . . . . . . . . . . . . . . . . . . . . . . . . 48
146 C.17 lc-78-directory . . . . . . . . . . . . . . . . . . . . . . 48
147 C.18 lc-82-iana . . . . . . . . . . . . . . . . . . . . . . . . . 48
148 D. Open issues (to be removed by RFC Editor before
149 publication) . . . . . . . . . . . . . . . . . . . . . . . . 49
150 D.1 lc-85-301 . . . . . . . . . . . . . . . . . . . . . . . . . 49
151 D.2 lc-38-not-hierarchical . . . . . . . . . . . . . . . . . . . 49
152 D.3 lc-36-server . . . . . . . . . . . . . . . . . . . . . . . . 49
153 D.4 lc-33-forwarding . . . . . . . . . . . . . . . . . . . . . . 49
154 D.5 lc-56-notjusthttp . . . . . . . . . . . . . . . . . . . . . 50
155 D.6 lc-37-integrity . . . . . . . . . . . . . . . . . . . . . . 50
156 D.7 3-terminology-redirectref . . . . . . . . . . . . . . . . . 50
157 D.8 lc-43-webdav . . . . . . . . . . . . . . . . . . . . . . . . 50
158 D.9 lc-19-direct-ref . . . . . . . . . . . . . . . . . . . . . . 51
159 D.10 lc-04-standard-data-container . . . . . . . . . . . . . . . 51
160 D.11 lc-05-standard-data-container . . . . . . . . . . . . . . . 51
161 D.12 lc-20-intro-mkresource . . . . . . . . . . . . . . . . . . . 51
162 D.13 lc-22-coll . . . . . . . . . . . . . . . . . . . . . . . . . 52
163 D.14 lc-25-atomic . . . . . . . . . . . . . . . . . . . . . . . . 52
164 D.15 lc-41-no-webdav . . . . . . . . . . . . . . . . . . . . . . 52
165 D.16 lc-42-no-webdav . . . . . . . . . . . . . . . . . . . . . . 52
166 D.17 lc-58-update . . . . . . . . . . . . . . . . . . . . . . . . 53
167 D.18 lc-23-body . . . . . . . . . . . . . . . . . . . . . . . . . 53
168 D.19 lc-24-properties . . . . . . . . . . . . . . . . . . . . . . 53
169 D.20 lc-47-207 . . . . . . . . . . . . . . . . . . . . . . . . . 54
170 D.21 lc-48-s6 . . . . . . . . . . . . . . . . . . . . . . . . . . 54
171 D.22 lc-28-lang . . . . . . . . . . . . . . . . . . . . . . . . . 55
172 D.23 lc-29-lang . . . . . . . . . . . . . . . . . . . . . . . . . 55
173 D.24 lc-49-put . . . . . . . . . . . . . . . . . . . . . . . . . 55
174 D.25 lc-44-pseudo . . . . . . . . . . . . . . . . . . . . . . . . 55
175 D.26 lc-61-pseudo . . . . . . . . . . . . . . . . . . . . . . . . 56
176 D.27 lc-60-ex . . . . . . . . . . . . . . . . . . . . . . . . . . 56
177 D.28 lc-62-oldclient . . . . . . . . . . . . . . . . . . . . . . 56
178 D.29 lc-63-move . . . . . . . . . . . . . . . . . . . . . . . . . 56
179 D.30 lc-06-reftarget-relative . . . . . . . . . . . . . . . . . . 57
180 D.31 lc-57-noautoupdate . . . . . . . . . . . . . . . . . . . . . 57
181 D.32 lc-71-relative . . . . . . . . . . . . . . . . . . . . . . . 57
182 D.33 lc-53-s10 . . . . . . . . . . . . . . . . . . . . . . . . . 58
183 D.34 lc-72-trailingslash . . . . . . . . . . . . . . . . . . . . 58
184 D.35 lc-50-blindredirect . . . . . . . . . . . . . . . . . . . . 58
185 D.36 lc-74-terminology . . . . . . . . . . . . . . . . . . . . . 59
186 D.37 lc-75-ignore . . . . . . . . . . . . . . . . . . . . . . . . 59
187 D.38 lc-76-location . . . . . . . . . . . . . . . . . . . . . . . 59
188 D.39 lc-79-accesscontrol . . . . . . . . . . . . . . . . . . . . 59
189 D.40 lc-80-i18n . . . . . . . . . . . . . . . . . . . . . . . . . 60
190 D.41 lc-55-iana . . . . . . . . . . . . . . . . . . . . . . . . . 60
191 Intellectual Property and Copyright Statements . . . . . . . 61
193 1. Introduction
195 This is one of a pair of specifications that extend the WebDAV
196 Distributed Authoring Protocol to enable clients to create new access
197 paths to existing resources. This capability is useful for several
198 reasons:
200 URIs of WebDAV-compliant resources are hierarchical and correspond to
201 a hierarchy of collections in resource space. The WebDAV Distributed
202 Authoring Protocol makes it possible to organize these resources into
203 hierarchies, placing them into groupings, known as collections, which
204 are more easily browsed and manipulated than a single flat
205 collection. However, hierarchies require categorization decisions
206 that locate resources at a single location in the hierarchy, a
207 drawback when a resource has multiple valid categories. For example,
208 in a hierarchy of vehicle descriptions containing collections for
209 cars and boats, a description of a combination car/boat vehicle could
210 belong in either collection. Ideally, the description should be
211 accessible from both. Allowing clients to create new URIs that access
212 the existing resource lets them put that resource into multiple
213 collections.
215 Hierarchies also make resource sharing more difficult, since
216 resources that have utility across many collections are still forced
217 into a single collection. For example, the mathematics department at
218 one university might create a collection of information on fractals
219 that contains bindings to some local resources, but also provides
220 access to some resources at other universities. For many reasons, it
221 may be undesirable to make physical copies of the shared resources on
222 the local server: to conserve disk space, to respect copyright
223 constraints, or to make any changes in the shared resources visible
224 automatically. Being able to create new access paths to existing
225 resources in other collections or even on other servers is useful for
226 this sort of case.
228 The redirect reference resources defined here provide a mechanism for
229 creating alternative access paths to existing resources. A redirect
230 reference resource is a resource in one collection whose purpose is
231 to forward requests to another resource (its target), possibly in a
232 different collection. In this way, it allows clients to submit
233 requests to the target resource from another collection. It
234 redirects most requests to the target resource using the HTTP 302
235 (Found) status code, thereby providing a form of mediated access to
236 the target resource.
238 A redirect reference is a resource, and so can have properties and a
239 body of its own. Properties of a redirect reference resource can
240 contain such information as who created the reference, when, and why.
242 Since redirect reference resources are implemented using HTTP 302
243 responses, it generally takes two round trips to submit a request to
244 the intended resource. Servers are not required to enforce the
245 integrity of redirect references. Redirect references work equally
246 well for local resources and for resources that reside on a different
247 server from the reference.
249 The remainder of this document is structured as follows: Section 3
250 defines terms that will be used throughout the specification.
251 Section 4 provides an overview of redirect reference resources.
252 Section 5 discusses how to create a redirect reference resource.
253 Section 6 defines the semantics of existing methods when applied to
254 redirect reference resources, and Section 7 discusses their semantics
255 when applied to collections that contain redirect reference
256 resources. Sections 8 through 10 discuss several other issues raised
257 by the existence of redirect reference resources. Sections 11
258 through 14 define the new headers, properties, and XML elements
259 required to support redirect reference resources. Section 15
260 discusses capability discovery. Sections 16 through 18 present the
261 security, internationalization, and IANA concerns raised by this
262 specification. The remaining sections provide a variety of supporting
263 information.
265 2. Notational Conventions
267 Since this document describes a set of extensions to the WebDAV
268 Distributed Authoring Protocol [RFC2518], itself an extension to the
269 HTTP/1.1 protocol, the augmented BNF used here to describe protocol
270 elements is exactly the same as described in Section 2.1 of
271 [RFC2616]. Since this augmented BNF uses the basic production rules
272 provided in Section 2.2 of [RFC2616], these rules apply to this
273 document as well.
275 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
276 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
277 document are to be interpreted as described in [RFC2119].
279 3. Terminology
281 The terminology used here follows and extends that in the WebDAV
282 Distributed Authoring Protocol specification [RFC2518]. Definitions
283 of the terms resource, Uniform Resource Identifier (URI), and Uniform
284 Resource Locator (URL) are provided in [RFC2396].
286 Redirect Reference Resource
288 A resource created to redirect all requests made to it, using 302
289 (Found), to a defined target resource.
291 Non-Reference Resource
293 A resource that is not a reference to another resource.
295 Target Resource
297 The resource to which requests are forwarded by a reference
298 resource.
300 4. Overview of Redirect Reference Resources
302 For all operations submitted to a redirect reference resource, the
303 default response is a 302 (Found), accompanied by the Redirect-Ref
304 header (defined in Section 11.1 below) and the Location header set to
305 the URI of the target resource. With this information, the client
306 can resubmit the request to the URI of the target resource.
308 A redirect reference resource never automatically forwards requests
309 to its target resource. Redirect resources bring the same benefits as
310 links in HTML documents. They can be created and maintained without
311 the involvement or even knowledge of their target resource. This
312 reduces the cost of linking between resources."
314 If the client is aware that it is operating on a redirect reference
315 resource, it can resolve the reference by retrieving the reference
316 resource's DAV:reftarget property (defined in Section 12.1 below),
317 whose value contains the URI of the target resource. It can then
318 submit requests to the target resource.
320 A redirect reference resource is a new type of resource. To
321 distinguish redirect reference resources from non-reference
322 resources, a new value of the DAV:resourcetype property (defined in
323 [RFC2518]), DAV:redirectref, is defined in Section 13.1 below.
325 Since a redirect reference resource is a resource, it can have its
326 own properties and body, and methods can be applied to the reference
327 resource as well as to its target resource. The
328 Apply-To-Redirect-Ref request header (defined in Section 11.2 below)
329 is provided so that referencing-aware clients can control whether an
330 operation is applied to the redirect reference resource or to its
331 target resource. The Apply-To-Redirect-Ref header can be used with
332 most requests to redirect reference resources. This header is
333 particularly useful with PROPFIND, to retrieve the reference
334 resource's own properties.
336 5. Creating a Redirect Reference Resource
338 The MKRESOURCE method is used to create new redirect reference
339 resources. As defined in Section 5.1, MKRESOURCE can be used to
340 create a resource of any type other than standard data containers and
341 collections. In order to create a redirect reference resource using
342 MKRESOURCE, the values of two properties must be set in the body of
343 the MKRESOURCE request. The value of DAV:resourcetype MUST be set to
344 DAV:redirectref, a new value of DAV:resourcetype defined in Section
345 13.1. The value of DAV:reftarget MUST be set to the URI of the target
346 resource.
348 Used in this way, the MKRESOURCE method creates a redirect reference
349 resource whose target is identified by the DAV:reftarget property.
351 5.1 MKRESOURCE
353 The MKRESOURCE method requests the creation of a resource and
354 initialization of its properties. It allows resources other than
355 standard data containers and collections to be created and their
356 properties initialized in one atomic operation.
358 Preconditions:
360 A resource MUST NOT exist at the Request-URI.
362 Request Marshalling:
364 The location of the new resource to be created is specified by the
365 Request-URI.
367 The request body of the MKRESOURCE method MUST consist of the
368 DAV:propertyupdate XML element defined in Section 12.13 of
369 [RFC2518].
371 Postconditions:
373 If the response status code is 201, a new resource exists at the
374 Request-URI.
376 The body of the new resource is empty.
378 The properties of the new resource are as specified by the
379 DAV:propertyupdate request body, using PROPPATCH semantics. If the
380 DAV:propertyupdate does not specify a DAV:resourcetype, the
381 resource will be a standard data container.
383 If the response status code is not 201, then a new resource is not
384 created at the Request-URI, and any existing resource at the
385 Request-URI is unaffected.
387 Response Marshalling:
389 Responses from a MKRESOURCE request MUST NOT be cached, as
390 MKRESOURCE has non-idempotent semantics.
392 The following status codes can be expected in responses to
393 MKRESOURCE:
395 201 (Created): The new resource was successfully created.
397 207 (Multi-Status): This response is generated if an error was
398 encountered while initializing the properties of the resource, in
399 which case the response is as defined in Section 8.2.1 of
400 [RFC2518].
402 403 (Forbidden): The server does not allow the creation of the
403 requested resource type at the requested location, or the parent
404 collection of the Request-URI exists but cannot accept members.
406 409 (Conflict): A resource cannot be created at the Request-URI
407 because the parent collection for the resource does not exist, or
408 because there is already a resource at that request-URL.
410 423 (Locked): The Request-URI is locked, and the lock token was
411 not passed with the request.
413 507 (Insufficient Storage): The server does not have sufficient
414 space to record the state of the resource.
416 5.2 Example: Creating a Redirect Reference Resource with MKRESOURCE
418 >> Request:
420 MKRESOURCE /~whitehead/dav/spec08.ref HTTP/1.1
421 Host: www.ics.uci.edu
422 Content-Type: text/xml; charset="utf-8"
423 Content-Length: xxx
425
426
427
428
429
430
431 /i-d/draft-webdav-protocol-08.txt
432
433
434
435
437 >> Response:
439 HTTP/1.1 201 Created
441 This request resulted in the creation of a new redirect reference
442 resource at www.ics.uci.edu/~whitehead/dav/spec08.ref, which points
443 to the resource identified by the DAV:reftarget property. In this
444 example, the target resource is identified by the URI http://
445 www.ics.uci.edu/i-d/draft-webdav-protocol-08.txt. The redirect
446 reference resource's DAV:resourcetype property is set to
447 DAV:redirectref.
449 6. Operations on Redirect Reference Resources
451 Although non-referencing-aware clients cannot create reference
452 resources, they should be able to submit requests through the
453 reference resources created by reference-aware WebDAV clients. They
454 should be able to follow any references to their targets. To make
455 this possible, a server that receives any request made via a redirect
456 reference resource MUST return a 302 (Found) status code, unless the
457 request includes an Apply-To-Redirect-Ref header. The client and
458 server MUST follow [RFC2616] Section 10.3.3 "302 Found," but with
459 these additional rules:
461 o The Location response header MUST contain an absolute URI that
462 identifies the target of the reference resource.
464 o The response MUST include the Redirect-Ref header. This header
465 allows reference-aware WebDAV clients to recognize the resource as
466 a reference resource and understand the reason for the
467 redirection.
469 A reference-aware WebDAV client can act on this response in one of
470 two ways. It can, like a non-referencing client, resubmit the
471 request to the URI in the Location header in order to operate on the
472 target resource. Alternatively, it can resubmit the request to the
473 URI of the redirect reference resource with the Apply-To-Redirect-Ref
474 header in order to operate on the reference resource itself. If the
475 Apply-To-Redirect-Ref header is present, the request MUST be applied
476 to the reference resource itself, and a 302 response MUST NOT be
477 returned.
479 A reference-aware client may know before submitting its request that
480 the Request-URI identifies a redirect reference resource. In this
481 case, if the client wants to apply the method to the reference
482 resource, it can save the round trip caused by the 302 response by
483 using an Apply-To-Redirect-Ref header in its initial request to the
484 URI.
486 A few methods need additional explanation:
488 The Apply-To-Redirect-Ref header can be used with GET or HEAD to
489 retrieve the entity headers of a redirect reference resource. When
490 Apply-To-Redirect-Ref is used with GET or HEAD, the Redirect-Ref
491 entity header MUST be returned.
493 A redirect reference resource MAY have a body, though none is defined
494 for it in this specification. The PUT method can be used, with
495 Apply-To-Redirect-Ref, to create or replace the body of a redirect
496 reference resource.
498 6.1 Example: GET on a Redirect Reference Resource
500 >> Request:
502 GET /bar.html HTTP/1.1
503 Host: www.foo.com
505 >> Response:
507 HTTP/1.1 302 Found
508 Location: http://www.svr.com/Internet/xxspec08.html
509 Redirect-Ref:
511 Since /bar.html is a redirect reference resource and the
512 Apply-To-Redirect-Ref header is not included in the request, the
513 response is a 302 (Found). The Redirect-Ref header informs a
514 reference-aware client that this is not an ordinary HTTP 1.1
515 redirect, but is a redirect reference resource. The URI of the
516 target resource is provided in the Location header so that the client
517 can resubmit the request to the target resource.
519 6.2 Example: PUT on a Redirect Reference Resource with
520 Apply-To-Redirect-Ref
522 >> Request:
524 PUT /bar.html HTTP/1.1
525 Host: www.foo.com
526 Apply-To-Redirect-Ref:
527 Content-Type: text/xml; charset="utf-8"
528 Content-Length: xxxx
530 . . . some content . . .
532 >> Response:
534 HTTP/1.1 200 OK
536 Although /bar.html is a redirect reference resource, the presence of
537 the Apply-To-Redirect-Ref header prevents a 302 response, and instead
538 causes the request to be applied to the reference resource. The
539 result in this case is that the reference resource is replaced by a
540 non-reference resource having the content submitted with the request.
542 6.3 Example: PROPPATCH on a Redirect Reference Resource
544 >> Request:
546 PROPPATCH /bar.html HTTP/1.1
547 Host: www.foo.com
548 Content-Type: text/xml; charset="utf-8"
549 Content-Length: xxxx
551
552
554
555
556
557 Jim Whitehead
558 Roy Fielding
559
560
561
562
563
564
565
566
567
569 >> Response:
571 HTTP/1.1 302 Found
572 Location: http://www.svr.com/Internet/xxspec08.html
573 Redirect-Ref:
575 Since /bar.html is a redirect reference resource and the
576 Apply-To-Redirect-Ref header is not included in the request, the
577 response is a 302 (Found). The Redirect-Ref header informs a
578 reference-aware client that this is not an ordinary HTTP 1.1
579 redirect, but is a redirect reference resource. The URI of the
580 target resource is provided in the Location header so that the client
581 can resubmit the request to the target resource.
583 7. Operations on Collections That Contain Redirect Reference Resources
585 Consistent with the rules in Section 6, the response for each
586 redirect reference encountered while processing a collection MUST be
587 a 302 (Found) unless a Apply-To-Redirect-Ref header is included with
588 the request. The overall response will therefore be a 207
589 (Multi-Status). Since a Location header and Redirect-Ref header
590 cannot be returned for each redirect reference encountered, the same
591 information is provided using properties in the response elements for
592 those resources. The DAV:location pseudo-property and the
593 DAV:resourcetype property MUST be included with the 302 status code.
594 This necessitates an extension to the syntax of the DAV:response
595 element that was defined in [RFC2518]. The extension is defined in
596 Section 14 below.
598 A referencing-aware client can tell from the DAV:resourcetype
599 property that the collection contains a redirect reference resource.
600 The DAV:location pseudo-property contains the absolute URI of the
601 target resource. A referencing-aware client can either use the URI
602 value of the DAV:location pseudo-property to resubmit its request to
603 the target resource, or it can submit the request to the redirect
604 reference resource with Apply-To-Redirect-Ref.
606 It is recommended that future editors of [RFC2518] define the
607 DAV:location pseudo-property in [RFC2518], so that non-referencing
608 clients will also be able to use the response to operate on the
609 target resource. (This will also enable clients to operate on
610 traditional HTTP/1.1 302 responses in Multi-Status responses.) Until
611 then, non-referencing clients will not be able to process 302
612 responses from redirect reference resources encountered while
613 processing a collection.
615 The Apply-To-Redirect-Ref header (defined in Section 11.2) MAY be
616 used with any request on a collection. If present, it will be
617 applied to all redirect reference resources encountered while
618 processing the collection.
620 7.1 MOVE and DELETE on Collections That Contain Redirect References
622 DELETE removes the binding that corresponds to the Request-URI. MOVE
623 removes that binding and creates a new binding to the same resource.
624 In cases where DELETE and MOVE are applied to a collection, these
625 operations affect all the descendents of the collection, but they do
626 so indirectly. There is no need to visit each descendent in order to
627 process the request. Consequently, even if there are redirect
628 reference resources in a tree that is being deleted or moved, there
629 will be no 302 responses from the redirect reference resources.
631 7.2 LOCK on a Collection That Contains Redirect References
633 LOCK poses special problems because it is atomic. An attempt to lock
634 (with Depth: infinity) a collection that contains redirect references
635 will always fail. The Multi-Status response will contain a 302
636 response for each redirect reference.
638 Reference-aware clients can lock the collection by using
639 Apply-To-Redirect-Ref, and, if desired, lock the targets of the
640 redirect references individually.
642 Non-referencing clients must resort to locking each resource
643 individually.
645 7.3 Example: PROPFIND on a Collection with Redirect Reference Resources
647 Suppose a PROPFIND request with Depth: infinity is submitted to the
648 following collection, with the members shown here:
650 http://www.svr.com/MyCollection/
651 (non-reference resource) diary.html
652 (redirect reference resource) nunavut
654 >> Request:
656 PROPFIND /MyCollection/ HTTP/1.1
657 Host: www.svr.com
658 Depth: infinity
659 Content-Type: text/xml
660 Content-Length: xxxx
662
663
664
665
666
667
668
670 >> Response:
672 HTTP/1.1 207 Multi-Status
673 Content-Type: text/xml
674 Content-Length: xxxx
676
677
678
679 http://www.svr.com/MyCollection/
680
681
682
683 diary, interests, hobbies
684
685 HTTP/1.1 200 OK
686
687
688
689 http://www.svr.com/MyCollection/diary.html
690
691
692
693 diary, travel, family, history
694
695 HTTP/1.1 200 OK
696
697
698
699 http://www.svr.com/MyCollection/nunavut
700 HTTP/1.1 302 Found
701
702
703 http://www.inac.gc.ca/art/inuit/
704
705
706
707
708
710 In this example the Depth header is set to infinity, and the
711 Apply-To-Redirect-Ref header is not used. The collection contains
712 one URI that identifies a redirect reference resource. The response
713 element for the redirect reference resource has a status of 302
714 (Found), and includes a DAV:prop element with the DAV:location
715 pseudo-property and the DAV:resourcetype property to allow clients to
716 retrieve the properties of its target resource. (The response
717 element for the redirect reference resource does not include the
718 requested properties. The client can submit another PROPFIND request
719 to the URI in the DAV:location pseudo-property to retrieve those
720 properties.)
722 7.4 Example: PROPFIND with Apply-To-Redirect-Ref on a Collection with
723 Redirect Reference Resources
725 Suppose a PROPFIND request with Apply-To-Redirect-Ref and Depth:
726 infinity is submitted to the following collection, with the members
727 shown here:
729 /MyCollection/
730 (non-reference resource) diary.html
731 (redirect reference resource) nunavut
733 >> Request:
735 PROPFIND /MyCollection/ HTTP/1.1
736 Host: www.svr.com
737 Depth: infinity
738 Apply-To-Redirect-Ref:
739 Content-Type: text/xml
740 Content-Length: xxxx
742
743
744
745
746
747
748
750 >> Response:
752 HTTP/1.1 207 Multi-Status
753 Content-Type: text/xml
754 Content-Length: xxxx
756
757
758
759 http://www.svr.com/MyCollection/
760
761
762
763
764 HTTP/1.1 200 OK
765
766
767
768 HTTP/1.1 404 Not Found
769
770
771
772 http://www.svr.com/MyCollection/diary.html
773
774
775
776
777 HTTP/1.1 200 OK
778
779
780
781 HTTP/1.1 404 Not Found
782
783
784
785 http://www.svr.com/MyCollection/nunavut
786
787
788
789
790 http://www.inac.gc.ca/art/inuit/
791
792
793 HTTP/1.1 200 OK
794
795
796
798 Since the Apply-To-Redirect-Ref header is present, the response shows
799 the properties of the redirect reference resource in the collection
800 rather than reporting a 302 status.
802 7.5 Example: COPY on a Collection That Contains a Redirect Reference
803 Resource
805 Suppose a COPY request is submitted to the following collection, with
806 the members shown:
808 /MyCollection/
809 (non-reference resource) diary.html
810 (redirect reference resource) nunavut with target
811 /Someplace/nunavut.map
813 >> Request:
815 COPY /MyCollection/ HTTP/1.1
816 Host: www.svr.com
817 Depth: infinity
818 Destination: http://www.svr.com/OtherCollection/
820 >> Response:
822 HTTP/1.1 207 Multi-Status
823 Content-Type: text/xml; charset="utf-8"
824 Content-Length: xxx
826
827
828
829 http://www.svr.com/MyCollection/nunavut
830 HTTP/1.1 302 Found
831
832
833 http://www.svr.com//Someplace/nunavut.map
834
835
836
837
838
840 In this case, since /MyCollection/nunavut is a redirect reference
841 resource, the COPY operation was only a partial success. The
842 redirect reference resource was not copied, but a 302 response was
843 returned for it. So the resulting collection is as follows:
845 /OtherCollection/
846 (non-reference resource) diary.html
848 7.6 Example: LOCK on a Collection That Contains a Redirect Reference
849 Resource
851 Suppose a LOCK request is submitted to the following collection, with
852 the members shown:
854 /MyCollection/
855 (non-reference resource) diary.html
856 (redirect reference resource) nunavut
858 >> Request:
860 LOCK /MyCollection/ HTTP/1.1
861 Host: www.svr.com
862 Content-Type: text/xml
863 Content-Length: nnnn
864 Authorizaton: Digest username="jas",
865 realm=jas@webdav.sb.aol.com, nonce=". . . ",
866 uri="/MyCollection/tuva",
867 response=". . . ", opaque=". . . "
869
870
871
872
873
874 http://www.svr.com/~jas/contact.html
875
876
878 >> Response:
880 HTTP/1.1 207 Multi-Status
881 Content-Type: text/xml
882 Content-Length: nnnn
884
885
886
887 http://www.svr.com/MyCollection/
888
889
890 HTTP/1.1 424 Failed Dependency
891
892
893
894 http://www.svr.com/MyCollection/diary.html
895 HTTP/1.1 424 Failed Dependency
896
897
898 http://www.svr.com/MyCollection/nunavut
899 HTTP/1.1 302 Found
900
901
902 http://www.inac.gc.ca/art/inuit/
903
904
905
906
907
909 The server returns a 302 response code for the redirect reference
910 resource in the collection. Consequently, neither the collection nor
911 any of the resources identified by its internal member URIs were
912 locked. A referencing-aware client can submit a separate LOCK request
913 to the URI in the DAV:location pseudo-property returned for the
914 redirect reference resource, and can resubmit the LOCK request with
915 the Apply-To-Redirect-Ref header to the collection. At that point
916 both the reference resource and its target resource will be locked
917 (as well as the collection and all the resources identified by its
918 other members).
920 8. Operations on Targets of Redirect Reference Resources
922 Operations on targets of redirect reference resources have no effect
923 on the reference resource.
925 9. Relative URIs in DAV:reftarget
927 The URI in the href in a DAV:reftarget property MAY be a relative
928 URI. In this case, the base URI to be used for resolving the relative
929 URI to absolute form is the URI used in the HTTP message to identify
930 the redirect reference resource to which the DAV:reftarget property
931 belongs.
933 When DAV:reftarget occurs in the body of a MKRESOURCE request, the
934 base URI is constructed as follows: Its scheme component is "http",
935 its authority component is the value of the Host header in the
936 request, and its path component is the Request-URI in the request.
937 See Section 5 of [RFC2396] for a discussion of relative URI
938 references and how to resolve them.
940 When DAV:reftarget appears in the context of a Multi-Status response,
941 it is in a DAV:response element that contains a single DAV:href
942 element. The value of this DAV:href element serves as the base URI
943 for resolving a relative URI in DAV:reftarget. The value of DAV:href
944 may itself be relative, in which case it must be resolved first in
945 order to serve as the base URI for the relative URI in DAV:reftarget.
946 If the DAV:href element is relative, its base URI is constructed from
947 the scheme component "http", the value of the Host header in the
948 request, and the request-URI.
950 9.1 Example: Resolving a Relative URI in a MKRESOURCE Request
952 >> Request:
954 MKRESOURCE /north/inuvik HTTP/1.1
955 Host: www.somehost.edu
956 Content-Type: text/xml; charset="utf-8"
957 Content-Length: xxx
959
960
961
962
963
964
965 mapcollection/inuvik.gif
966
967
968
969
971 >> Response:
973 HTTP/1.1 201 Created
975 In this example, the base URI is http://www.somehost.edu/north/
976 inuvik. Then, following the rules in [RFC2396] Section 5, the
977 relative URI in DAV:reftarget resolves to the absolute URI http://
978 www.somehost.edu/north/mapcollection/inuvik.gif.
980 9.2 Example: Resolving a Relative URI in a Multi-Status Response
982 >> Request:
984 PROPFIND /geog/ HTTP/1.1
985 Host: www.xxsvr.com
986 Apply-To-Redirect-Ref:
987 Depth: 1
988 Content-Type: text/xml
989 Content-Length: nnn
991
992
993
994
995
996
997
999 >> Response:
1001 HTTP/1.1 207 Multi-Status
1002 Content-Type: text/xml
1003 Content-Length: nnn
1005
1006
1007
1008 /geog/
1009
1010
1011
1012
1013 HTTP/1.1 200 OK
1014
1015
1016
1017 HTTP/1.1 404 Not Found
1018
1019
1020
1021 /geog/stats.html
1022
1023
1024
1025
1026 statistics/population/1997.html
1027
1028
1029 HTTP/1.1 200 OK
1030
1031
1032
1034 In this example, the relative URI statistics/population/1997.html is
1035 returned as the value of reftarget for the reference resource
1036 identified by href /geog/stats.html. The href is itself a relative
1037 URI, which resolves to http://www.xxsrv.com/geog/stats.html. This is
1038 the base URI for resolving the relative URI in reftarget. The
1039 absolute URI of reftarget is http://www.xxsrv.com/geog/statistics/
1040 population/1997.html.
1042 10. Redirect References to Collections
1044 In a Request-URI /segment1/segment2/segment3, any of the three
1045 segments may identify a redirect reference resource. (See [RFC2396],
1046 Section 3.3, for definitions of "path" and "segment".) If any
1047 segment in a Request- URI identifies a redirect reference resource,
1048 the response is a 302. The value of the Location header in the 302
1049 response is as follows:
1051 The leftmost path segment of the request-URI that identifies a
1052 redirect reference resource, together with all path segments and
1053 separators to the left of it, is replaced by the value of the
1054 redirect reference resource's DAV:reftarget property (resolved to an
1055 absolute URI). The remainder of the request-URI is concatenated to
1056 this path.
1058 Note: If the DAV:reftarget property ends with a "/" and the remainder
1059 of the Request-URI is non-empty (and therefore must begin with a "/
1060 "), the final "/" in the DAV:reftarget property is dropped before the
1061 remainder of the Request-URI is appended.
1063 Consider Request-URI /x/y/z.html. Suppose that /x/ is a redirect
1064 reference resource whose target resource is collection /a/, which
1065 contains redirect reference resource y whose target resource is
1066 collection /b/, which contains redirect reference resource z.html
1067 whose target resource is /c/d.html.
1069 /x/y/z.html
1070 |
1071 | /x -> /a
1072 |
1073 v
1074 /a/y/z.html
1075 |
1076 | /a/y -> /b
1077 |
1078 v
1079 /b/z.html
1080 |
1081 | /b/z.html -> /c/d.html
1082 |
1083 v
1084 /c/d.html
1086 In this case the client must follow up three separate 302 responses
1087 before finally reaching the target resource. The server responds to
1088 the initial request with a 302 with Location: /a/y/z.html, and the
1089 client resubmits the request to /a/y/z.html. The server responds to
1090 this request with a 302 with Location: /b/z.html, and the client
1091 resubmits the request to /b/z.html. The server responds to this
1092 request with a 302 with Location: /c/d.html, and the client resubmits
1093 the request to /c/d.html. This final request succeeds.
1095 11. Headers
1097 11.1 Redirect-Ref Response Header
1099 Redirect-Ref = "Redirect-Ref:"
1101 The Redirect-Ref header is used in all 302 responses from redirect
1102 reference resources. Its presence informs reference-aware clients
1103 that the response is not a plain HTTP/1.1 redirect, but is a response
1104 from a redirect reference resource.
1106 11.2 Apply-To-Redirect-Ref Request Header
1108 Apply-To-Redirect-Ref = "Apply-To-Redirect-Ref" ":"
1110 The optional Apply-To-Redirect-Ref header can be used on any request
1111 to a redirect reference resource. When it is used, the request MUST
1112 be applied to the reference resource itself, and a 302 response MUST
1113 NOT be returned.
1115 If the Apply-To-Redirect-Ref header is used on a request to any other
1116 sort of resource besides a redirect reference resource, the server
1117 SHOULD ignore it.
1119 12. Properties
1121 12.1 reftarget Property
1123 Name: reftarget
1125 Namespace: DAV:
1127 Purpose: A property of redirect reference resources that provides an
1128 efficient way for clients to discover the URI of the target
1129 resource. This is a read-only property after its initial
1130 creation. Its value can only be set in a MKRESOURCE request.
1132 Value: href containing the URI of the target resource. This value
1133 MAY be a relative URI. The reftarget property can occur in the
1134 entity bodies of MKRESOURCE requests and of responses to PROPFIND
1135 requests.
1137
1139 12.2 location Pseudo-Property
1141 Name: location
1143 Namespace: DAV:
1145 Purpose: For use with 302 (Found) response codes in Multi-Status
1146 responses. It contains the absolute URI of the temporary location
1147 of the resource. In the context of redirect reference resources,
1148 this value is the absolute URI of the target resource. It is
1149 analogous to the Location header in HTTP 302 responses defined in
1150 [RFC2616] Section 10.3.3 "302 Found." Including the location
1151 pseudo-property in a Multi- Status response requires an extension
1152 to the syntax of the DAV:response element defined in [RFC2518],
1153 which is defined in Section 14 below. This pseudo-property is not
1154 expected to be stored on the reference resource. It is modeled as
1155 a property only so that it can be returned inside a DAV:prop
1156 element in a Multi-Status response.
1158 Value: href containing the absolute URI of the target resource.
1160
1162 13. XML Elements
1164 13.1 redirectref XML Element
1166 Name: redirectref
1168 Namespace: DAV:
1170 Purpose: Used as the value of the DAV:resourcetype property to
1171 specify that the resource type is a redirect reference resource.
1173
1175 14. Extensions to the DAV:response XML Element for Multi-Status
1176 Responses
1178 As described in Section 7, the DAV:location pseudo-property and the
1179 DAV:resourcetype property may be returned in the DAV:response element
1180 of a 207 Multi-Status response, to allow clients to resubmit their
1181 requests to the target resource of a redirect reference resource.
1183 Whenever these properties are included in a Multi-Status response,
1184 they are placed in a DAV:prop element associated with the href to
1185 which they apply. This structure provides a framework for future
1186 extensions by other standards that may need to include additional
1187 properties in their responses.
1189 Consequently, the definition of the DAV:response XML element changes
1190 to the following:
1192
1195 15. Capability Discovery
1197 Sections 9.1 and 15 of [RFC2518] describe the use of compliance
1198 classes with the DAV header in responses to OPTIONS, to indicate
1199 which parts of the WebDAV Distributed Authoring protocols the
1200 resource supports. This specification defines an OPTIONAL extension
1201 to [RFC2518]. It defines a new compliance class, called
1202 redirectrefs, for use with the DAV header in responses to OPTIONS
1203 requests. If a resource does support redirect references, its
1204 response to an OPTIONS request may indicate that it does, by listing
1205 the new redirectrefs compliance class in the DAV headerand by listing
1206 the MKRESOURCE method as one it supports.
1208 When responding to an OPTIONS request, any type of resource can
1209 include redirectrefs in the value of the DAV header. Doing so
1210 indicates that the server permits a redirect reference resource at
1211 the request URI.
1213 15.1 Example: Discovery of Support for Redirect Reference Resources
1215 >> Request:
1217 OPTIONS /somecollection/someresource HTTP/1.1
1218 HOST: somehost.org
1220 >> Response:
1222 HTTP/1.1 200 OK
1223 Date: Tue, 20 Jan 1998 20:52:29 GMT
1224 Connection: close
1225 Accept-Ranges: none
1226 Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE,
1227 MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, MKRESOURCE
1228 DAV: 1, 2, redirectrefs
1230 The DAV header in the response indicates that the resource /
1231 somecollection/someresource is level 1 and level 2 compliant, as
1232 defined in [RFC2518]. In addition, /somecollection/someresource
1233 supports redirect reference resources. The Allow header indicates
1234 that MKRESOURCE requests can be submitted to /somecollection/
1235 someresource. The Public header shows that other Request-URIs on the
1236 server support additional methods.
1238 16. Security Considerations
1240 This section is provided to make applications that implement this
1241 protocol aware of the security implications of this protocol.
1243 All of the security considerations of HTTP/1.1 and the WebDAV
1244 Distributed Authoring Protocol specification also apply to this
1245 protocol specification. In addition, redirect reference resources
1246 introduce several new security concerns and increase the risk of some
1247 existing threats. These issues are detailed below.
1249 16.1 Privacy Concerns
1251 By creating redirect reference resources on a trusted server, it is
1252 possible for a hostile agent to induce users to send private
1253 information to a target on a different server. This risk is
1254 mitigated somewhat, since clients are required to notify the user of
1255 the redirection for any request other than GET or HEAD. (See
1256 [RFC2616], Section 10.3.3 302 Found.)
1258 16.2 Redirect Loops
1260 Although redirect loops were already possible in HTTP 1.1, the
1261 introduction of the MKRESOURCE method creates a new avenue for
1262 clients to create loops accidentally or maliciously. If the
1263 reference resource and its target are on the same server, the server
1264 may be able to detect MKRESOURCE requests that would create loops.
1265 See also [RFC2616], Section 10.3 "Redirection 3xx."
1267 16.3 Redirect Reference Resources and Denial of Service
1269 Denial of service attacks were already possible by posting URLs that
1270 were intended for limited use at heavily used Web sites. The
1271 introduction of MKRESOURCE creates a new avenue for similar denial of
1272 service attacks. Clients can now create redirect reference resources
1273 at heavily used sites to target locations that were not designed for
1274 heavy usage.
1276 16.4 Revealing Private Locations
1278 There are several ways that redirect reference resources may reveal
1279 information about collection structures. First, the DAV:reftarget
1280 property of every redirect reference resource contains the URI of the
1281 target resource. Anyone who has access to the reference resource can
1282 discover the collection path that leads to the target resource. The
1283 owner of the target resource may have wanted to limit knowledge of
1284 this collection structure.
1286 Sufficiently powerful access control mechanisms can control this risk
1287 to some extent. Property-level access control could prevent users
1288 from examining the DAV:reftarget property. (The Location header
1289 returned in responses to requests on redirect reference resources
1290 reveals the same information, however.) In some environments, the
1291 owner of a resource might be able to use access control to prevent
1292 others from creating references to that resource.
1294 This risk is no greater than the similar risk posed by HTML links.
1296 17. Internationalization Considerations
1298 This specification follows the practices of [RFC2518] in encoding all
1299 human-readable content using XML [XML] and in the treatment of names.
1300 Consequently, this specification complies with the IETF Character Set
1301 Policy [RFC2277].
1303 WebDAV applications MUST support the character set tagging, character
1304 set encoding, and the language tagging functionality of the XML
1305 specification. This constraint ensures that the human-readable
1306 content of this specification complies with [RFC2277].
1308 As in [RFC2518], names in this specification fall into three
1309 categories: names of protocol elements such as methods and headers,
1310 names of XML elements, and names of properties. Naming of protocol
1311 elements follows the precedent of HTTP, using English names encoded
1312 in USASCII for methods and headers. The names of XML elements used
1313 in this specification are English names encoded in UTF-8.
1315 For error reporting, [RFC2518] follows the convention of HTTP/1.1
1316 status codes, including with each status code a short, English
1317 description of the code (e.g., 423 Locked). Internationalized
1318 applications will ignore this message, and display an appropriate
1319 message in the user's language and character set.
1321 This specification introduces no new strings that are displayed to
1322 users as part of normal, error-free operation of the protocol.
1324 For rationales for these decisions and advice for application
1325 implementors, see [RFC2518].
1327 18. IANA Considerations
1329 All IANA considerations mentioned in [RFC2518] also apply to this
1330 document.
1332 19. Acknowledgements
1334 This draft has benefited from thoughtful discussion by Jim Amsden,
1335 Peter Carlson, Steve Carter, Tyson Chihaya, Ken Coar, Ellis Cohen,
1336 Bruce Cragun, Spencer Dawkins, Mark Day, Rajiv Dulepet, David Durand,
1337 Roy Fielding, Yaron Goland, Fred Hitt, Alex Hopmann, James Hunt,
1338 Marcus Jager, Chris Kaler, Manoj Kasichainula, Rohit Khare, Daniel
1339 LaLiberte, Steve Martin, Larry Masinter, Jeff McAffer, Joe Orton,
1340 Surendra Koduru Reddy, Juergen Reuter, Max Rible, Sam Ruby, Bradley
1341 Sergeant, Nick Shelness, John Stracke, John Tigue, John Turner, Kevin
1342 Wiggen, and others.
1344 Normative References
1346 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
1347 Languages", BCP 18, RFC 2277, January 1998.
1349 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1350 Requirement Levels", BCP 14, RFC 2119, March 1997.
1352 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
1353 Resource Identifiers (URI): Generic Syntax", RFC 2396,
1354 August 1998.
1356 [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D.
1357 Jensen, "HTTP Extensions for Distributed Authoring --
1358 WEBDAV", RFC 2518, February 1999.
1360 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
1361 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
1362 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
1364 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
1365 "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C
1366 REC-xml, October 2000, .
1369 [1]
1371 [2]
1373 [3]
1376 [4]
1379 [5]
1382 [6]
1385 [7]
1388 [8]
1391 [9]
1394 [10]
1397 [11]
1400 [12]
1403 [13]
1406 [14]
1409 [15]
1412 [16]
1415 [17]
1418 [18]
1421 [19]
1424 [20]
1427 [21]
1430 [22]
1433 [23]
1436 [24]
1439 [25]
1442 [26]
1445 [27]
1448 [28]
1451 [29]
1454 [30]
1457 [31]
1460 [32]
1463 [33]
1466 [34]
1469 [35]
1472 [36]
1475 [37]
1478 [38]
1481 [39]
1484 [40]
1487 [41]
1490 [42]
1493 [43]
1496 [44]
1499 [45]
1502 [46]
1505 [47]
1508 [48]
1511 [49]
1514 [50]
1517 [51]
1520 [52]
1523 [53]
1526 [54]
1529 [55]
1532 [56]
1535 [57]
1538 [58]
1541 [59]
1544 [60]
1547 Authors' Addresses
1549 J. Slein
1550 Xerox Corporation
1551 800 Phillips Road, 105-50C
1552 Webster, NY 14580
1554 EMail: jslein@crt.xerox.com
1556 Jim Whitehead
1557 UC Santa Cruz, Dept. of Computer Science
1558 1156 High Street
1559 Santa Cruz, CA 95064
1560 US
1562 EMail: ejw@cse.ucsc.edu
1564 J. Davis
1565 CourseNet Systems
1566 170 Capp Street
1567 San Francisco, CA 94110
1569 EMail: jrd3@alum.mit.edu
1571 G. Clemm
1572 Rational Software Corporation
1573 20 Maguire Road
1574 Lexington, MA 02173-3104
1576 EMail: geoffrey.clemm@us.ibm.com
1577 C. Fay
1578 FileNet Corporation
1579 3565 Harbor Boulevard
1580 Costa Mesa, CA 92626-1420
1582 EMail: cfay@filenet.com
1584 J. Crawford
1585 IBM Research
1586 P.O. Box 704
1587 Yorktown Heights, NY 10598
1589 EMail: ccjason@us.ibm.com
1591 Julian F. Reschke (editor)
1592 greenbytes GmbH
1593 Salzmannstrasse 152
1594 Muenster, NW 48159
1595 Germany
1597 Phone: +49 251 2807760
1598 Fax: +49 251 2807761
1599 EMail: julian.reschke@greenbytes.de
1600 URI: http://greenbytes.de/tech/webdav/
1602 Appendix A. Changes to the WebDAV Document Type Definition
1604
1605
1606 Property Elements from Section 12 -->
1607
1608
1609
1610
1613 Appendix B. Change Log (to be removed by RFC Editor before publication)
1615 B.1 Since draft-ietf-webdav-redirectref-protocol-02
1617 Julian Reschke takes editorial role (added to authors list). Cleanup
1618 XML indentation. Start adding all unresolved last call issues. Update
1619 some author's contact information. Update references, split into
1620 "normative" and "informational". Remove non-RFC2616 headers
1621 ("Public") from examples. Fixed width problems in artwork. Start
1622 resolving editorial issues.
1624 B.2 Since draft-ietf-webdav-redirectref-protocol-03
1626 Added Joe Orton and Juergen Reuter to Acknowledgements section. Close
1627 more editorial issues. Remove dependencies on BIND spec.
1629 Appendix C. Resolved issues (to be removed by RFC Editor before
1630 publication)
1632 Issues that were either rejected or resolved in this version of this
1633 document.
1635 C.1 lc-07-bind
1637 Type: change
1639 [3]
1641 reuterj@ira.uka.de (2000-02-07): Abstract should discuss only
1642 redirect references, not bindings. Expand discussion of redirect
1643 references.
1645 Resolution: Abstract will discuss only redirect references. See also
1646 issue 34.
1648 C.2 lc-08-bind
1650 Type: change
1652 [4]
1654 reuterj@ira.uka.de (2000-02-07): Get rid of cross-references to the
1655 binding spec: in the abstract, in the introduction, in the definition
1656 of Reference Resource.
1658 Resolution: Cross-references to bindings will be removed. See also
1659 issue 34.
1661 C.3 lc-34-bind
1663 Type: change
1665 [5]
1667 yarong@Exchange.Microsoft.com (2000-02-11): NoBind: Remove all
1668 cross-references to the binding spec. Prefer also removing all
1669 mention of bindings.
1671 Resolution: Agreed. See also issues 7, 8, 14
1673 C.4 lc-83-bind
1675 Type: change
1677 [6]
1679 reuterj@ira.uka.de (2000-02-22): References: Get rid of the reference
1680 to the bindings spec.
1682 Resolution: Agreed.
1684 C.5 lc-12-bind
1686 Type: change
1688 [7]
1690 reuterj@ira.uka.de (2000-02-07): First 3 paragraphs of Introduction
1691 are identical to those in binding spec. Make sure that any changes
1692 made there are also incorporated here.
1694 Resolution: These paragraphs will change as necessary to make the
1695 redirect spec completely independent of the rest of WebDAV.
1697 C.6 lc-35-bind
1699 Type: change
1701 [8]
1703 yarong@Exchange.Microsoft.com (2000-02-11): ReallyNoBind: Remove
1704 paras. 6 and 8 from Intro.
1706 Resolution: Agreed. See also issue 14.
1708 C.7 lc-01-body
1710 Type: change
1712 [9]
1714 joe@orton.demon.co.uk (2000-01-26): Entity Bodies for Redirect
1715 References: Clarify: Are there 2 resources, one that redirects and
1716 one that responds with its own entity body? Clarify: What is the
1717 effect of PUT for a URI that currently maps to a redirect reference?
1719 Resolution: Redirect resource MUST NOT have a body. See also issue
1720 last call issue 23.
1722 C.8 lc-14-bind
1724 Type: change
1726 [10]
1728 reuterj@ira.uka.de (2000-02-07): Limit the discussion of bindings to
1729 just what is needed to understand the differences from redirect
1730 references. Maybe the paragraph in the Intro that starts "By
1731 contrast, a BIND request . . ." is all that is needed.
1733 Resolution: Get rid of discussion of bindings altogether. See also
1734 issue 34, 35.
1736 C.9 lc-15-direct-ref
1738 Type: change
1740 [11]
1742 reuterj@ira.uka.de (2000-02-07): Don't define Direct Reference
1743 Resource, since direct references are out of scope. (If you do keep
1744 the definition, say explicitly that a direct reference resource is a
1745 type of reference resource.)
1747 Resolution: Remove definition of Direct Reference Resource. See also
1748 issue 39.
1750 C.10 lc-39-no-reference-or-direct-resource
1752 Type: change
1754 [12]
1756 yarong@Exchange.Microsoft.com (2000-02-11):
1757 NoReferenceOrDirectResource: Remove the definitions of "Reference"
1758 and "Direct Reference Resource." Change the definition of "Redirect
1759 Reference Resource" to be: Redirect Resource: A resource created to
1760 redirect all requests made to it, using 302 (Found), to a defined
1761 target resource.
1763 julian.reschke@greenbytes.de (2003-07-27): (Rename from "redirect
1764 reference resource" to "redirect resource" delayed for now).
1766 Resolution: Agreed. See also issue 15.
1768 C.11 lc-40-direct
1770 Type: change
1772 [13]
1773 yarong@Exchange.Microsoft.com (2000-02-11): Assorted changes to
1774 Section 4, para 2 to get rid of the word "forward" and the word
1775 "server" and remove comparison with direct references.
1777 Resolution: See also issue 33 (forward). See also issue 36 (server).
1778 Remove discussion of direct references.
1780 C.12 lc-45-apply-to-rr
1782 Type: change
1784 [14]
1786 yarong@Exchange.Microsoft.com (2000-02-11): Suggested replacement
1787 text for this paragraph, which briefly introduces
1788 Apply-To-Redirect-Ref. Includes a note that even with this header,
1789 the response may be a 302.
1791 Resolution: See issue 19 for replacement text. Disagree. Redirect
1792 reference will never respond to Apply-To-RR with 302.
1794 C.13 lc-01A-body
1796 Type: change
1798 [15]
1800 joe@orton.demon.co.uk (2000-01-26): In the definition of MKRESOURCE,
1801 "Body" needs to be defined or else terminology changed.
1803 Resolution: We will use MKREF instead of MKRESOURCE.
1805 C.14 lc-31-MKCOL
1807 Type: edit
1809 [16]
1811 reuterj@ira.uka.de (2000-02-07): Section 6, para on MKRESOURCE and
1812 MKCOL is obvious and doesn't need to be stated. Maybe show in an
1813 example.
1815 Resolution: Agreed. See also issue 48.
1817 C.15 lc-67-redirectref
1819 Type: change
1821 [17]
1823 reuterj@ira.uka.de (2000-02-14): 7.4: The explanation should not
1824 contrast displaying the properties of the redirect ref with
1825 displaying the properties of its target, but with returning a 302.
1827 Resolution: Revise as recommended.
1829 C.16 lc-54-s10
1831 Type: change
1833 [18]
1835 yarong@Exchange.Microsoft.com (2000-02-11): The Note: in section 10
1836 has the same problem pointed out in Bindings.NoSlash and needs to be
1837 fixed. It contradicts RFC 2518 and 2616, which both assume that a URL
1838 and the same URL + "/" may map to different resources.
1840 Resolution: Agreed in mailing list discussions that no change is
1841 needed.
1843 C.17 lc-78-directory
1845 Type: change
1847 [19]
1849 reuterj@ira.uka.de (2000-02-22): Section 16.4: Change "directory" to
1850 "collection". Not new to this protocol. Holds for any protocol that
1851 has hierarchical access paths.
1853 C.18 lc-82-iana
1855 Type: change
1857 [20]
1859 reuterj@ira.uka.de (2000-02-22): Section 18: Just reference [WebDAV]
1860 and say this protocol does not introduce any new considerations.
1862 Resolution: Simplify, then resolve issue 55.
1864 Appendix D. Open issues (to be removed by RFC Editor before publication)
1866 D.1 lc-85-301
1868 Type: change
1870 ejw@cse.ucsc.edu (2000-01-03): Support creation of other than 302
1871 redirects, especially 301.
1873 D.2 lc-38-not-hierarchical
1875 Type: change
1877 [21]
1879 yarong@Exchange.Microsoft.com (2000-02-11): Not Hierarchical: The
1880 first sentence of the second paragraph of the introduction of the
1881 redirect spec asserts that the URIs of WebDAV compliant resources
1882 match to collections. The WebDAV standard makes no such requirement.
1883 I therefore move that this sentence be stricken.
1885 Resolution: State the more general HTTP rationale first (alternative
1886 names for the same resource), then introduce the collection hierarchy
1887 rationale, which applies only if you are in a WebDAV-compliant space.
1889 D.3 lc-36-server
1891 Type: change
1893 [22]
1895 yarong@Exchange.Microsoft.com (2000-02-11): Servers: Replace "server"
1896 with "unrelated system" throughout.
1898 Resolution: Try replacing "server" with "host" in some contexts,
1899 rephrasing in passive voice in others. See also issue 40.
1901 D.4 lc-33-forwarding
1903 Type: change
1905 [23]
1907 yarong@Exchange.Microsoft.com (2000-02-11): Forwarding: Replace
1908 "forward" with "redirect" throughout.
1910 Resolution: Use "redirect" for the behavior redirect resources do
1911 exhibit. Use "forward" for the contrasting behavior (passing a method
1912 on to the target with no client action needed). Define these two
1913 terms. See also issue 40.
1915 D.5 lc-56-notjusthttp
1917 Type: change
1919 [24]
1921 yarong@Exchange.Microsoft.com (2000-02-11): Make it clear in examples
1922 and text that the redirection URI could be non-HTTP.
1924 Resolution: We agree that it is possible to create redirect
1925 references to non-HTTP resources. Add example.
1927 D.6 lc-37-integrity
1929 Type: change
1931 [25]
1933 yarong@Exchange.Microsoft.com (2000-02-11): Integrity: Intro, para 7
1934 "Servers are not required to enforce the integrity of redirect
1935 references." Integrity is not defined. Replace with something
1936 clearer.
1938 Resolution: Rewrite to say that the server MUST NOT update the target
1939 See also issue 6.
1941 D.7 3-terminology-redirectref
1943 Type: change
1945 [26]
1947 julian.reschke@greenbytes.de (2003-07-27): Consider global rename of
1948 "redirect reference resource" to "redirect resource".
1950 D.8 lc-43-webdav
1952 Type: change
1954 [27]
1956 yarong@Exchange.Microsoft.com (2000-02-11): Get rid of the
1957 DAV:reftarget property.
1959 Resolution: DAV:reftarget is readonly and is present only for
1960 redirect references that are also WebDAV resources. We'll also have a
1961 method for setting target; Redirect-Ref header (returned on all 302
1962 responses) will have the target as its value. See also issue 6, 17,
1963 50.
1965 D.9 lc-19-direct-ref
1967 Type: change
1969 [28]
1971 reuterj@ira.uka.de (2000-02-07): Section 4, para 5 and Section 6,
1972 para 3 discussions of the Apply-to-Redirect-Ref header make it sound
1973 as if we are specifying direct reference behavior.
1975 Resolution: Change these passages so that the contrast is between
1976 applying the method to the redirect reference and responding with a
1977 302.
1979 D.10 lc-04-standard-data-container
1981 Type: change
1983 [29]
1985 joe@orton.demon.co.uk (2000-01-26): "Standard data container" needs
1986 to be defined in the context of MKRESOURCE
1988 Resolution: Not relevant once we switch to MKREF.
1990 D.11 lc-05-standard-data-container
1992 Type: change
1994 [30]
1996 joe@orton.demon.co.uk (2000-01-26): Inconsistency about whether a
1997 "standard data container" can be created with MKRESOURCE or not.
1999 Resolution: Not relevant once we switch to MKREF.
2001 D.12 lc-20-intro-mkresource
2003 Type: change
2005 [31]
2007 reuterj@ira.uka.de (2000-02-07): Section 5: Start with "The new
2008 MKRESOURCE method" to make it clear that it is being introduced for
2009 the first time here.
2011 Resolution: Say "The MKREF method defined normatively here . . ."
2013 D.13 lc-22-coll
2015 Type: change
2017 [32]
2019 reuterj@ira.uka.de (2000-02-07): Inconsistency about whether
2020 collections can be created with MKRESOURCE.
2022 Resolution: Not relevant for MKREF.
2024 D.14 lc-25-atomic
2026 Type: change
2028 [33]
2030 reuterj@ira.uka.de (2000-02-07): Is MKRESOURCE atomic as viewed by a
2031 client? Can another client access the new resource's properties
2032 before they have been fully initialized? Maybe the MKRESOURCE request
2033 should let the client ask for it to be atomic.
2035 Resolution: No longer relevant once we switch to MKREF with no
2036 request body.
2038 D.15 lc-41-no-webdav
2040 Type: change
2042 [34]
2044 yarong@Exchange.Microsoft.com (2000-02-11): Make redirect references
2045 independent of the rest of WebDAV. The creation method for redirect
2046 references shouldn't require an XML request body.
2048 Resolution: We will make redirect references independent of the rest
2049 of WebDAV. MKREF will not have an XML request body.
2051 D.16 lc-42-no-webdav
2053 Type: change
2055 [35]
2056 yarong@Exchange.Microsoft.com (2000-02-11): Use a creation method
2057 that creates only redirect references. The MKRESOURCE method hinders
2058 experiment because a user of a server who wishes to add support for
2059 the creation of a new resource type can't simply throw in another
2060 Apache module and allow it to provide the code for the new resource
2061 type. They have to find the code used for MKRESOURCE and change it to
2062 support the new resource type.
2064 Resolution: We will replace MKRESOURCE with MKREF, which creates only
2065 redirect reference resources.
2067 D.17 lc-58-update
2069 Type: change
2071 [36]
2073 yarong@Exchange.Microsoft.com (2000-02-11): There needs to be a way
2074 to update the target of a redirect reference.
2076 Resolution: Agreed. See also issues 6, 43.
2078 D.18 lc-23-body
2080 Type: change
2082 [37]
2084 reuterj@ira.uka.de (2000-02-07): Section 5.1: Get rid of the
2085 statement that the body of the resource is empty (PostConditions). It
2086 would be good if the response to GET included a response body that
2087 could be shown to a user by a client that doesn't do automatic
2088 redirection. There is a related problem in Section 6 on PUT. It is
2089 wrong to assume that what is PUT to a resource is what GET will
2090 return. In Section 6, say "A PUT with Apply-To-RR MAY contain a
2091 request body. The semantics of the request body is out of scope for
2092 this specification..." Also fix the discussion of example 6.2.
2094 Resolution: Redirect references cannot have bodies. GET with
2095 Apply-To-RR MUST fail with 403. PUT with Apply-To-RR MUST fail with
2096 403. See also issue 1.
2098 D.19 lc-24-properties
2100 Type: change
2102 [38]
2103 reuterj@ira.uka.de (2000-02-07): Section 5.1: Replace the sentence
2104 "The properties of the new resource are as specified by the
2105 DAV:propertyupdate request body, using PROPPATCH semantics" with the
2106 following: "The MKRESOURCE request MAY contain a DAV:propertyupdate
2107 request body to initialize resource properties. Herein, the semantics
2108 is the same as when sending a MKRESOURCE request without a request
2109 body, followed by a PROPPATCH with the DAV:propertyupdate request
2110 body."
2112 Resolution: No longer relevant once we switch to MKREF with no
2113 request body.
2115 D.20 lc-47-207
2117 Type: change
2119 [39]
2121 yarong@Exchange.Microsoft.com (2000-02-11): In line with his wish to
2122 get rid of the request message body of MKRESOURCE, 207 would not be
2123 an appropriate response code. The description of 409 might lead
2124 someone to believe that you can't create redirect references outside
2125 of WebDAV namespaces. Suggests a different description.
2127 Resolution: No longer relevant - MKREF can't get a 207 response.
2128 Revise to make it clear that the first condition will only occur in
2129 WebDAV-compliant namespaces.
2131 D.21 lc-48-s6
2133 Type: change
2135 [40]
2137 yarong@Exchange.Microsoft.com (2000-02-11): Replace all of section 6
2138 with just this: A redirect resource, upon receiving a request without
2139 an Apply-To-Redirect-Ref header, MUST respond with a 302 (Found)
2140 response. The 302 (Found) response MUST include a location header
2141 identifying the target and a Redirect-Ref header. If a redirect
2142 resource receives a request with an Apply-To-Redirect-Ref header then
2143 the redirect reference resource MUST apply the method to itself
2144 rather than blindly returning a 302 (Found) response.
2146 Resolution: Keep a summary along the lines of Yaron's proposal (don't
2147 use the word "blindly"). Keep the bullets detailing the headers to be
2148 returned. Delete the rest, including the examples. See also issue 28,
2149 29, 30, 31, 32.
2151 D.22 lc-28-lang
2153 Type: edit
2155 [41]
2157 reuterj@ira.uka.de (2000-02-07): Section 6: Get rid of the sentence
2158 "A reference-aware WebDAV client can act on this response in one of
2159 two ways." A client can act on the response in any way it wants.
2161 Resolution: Agreed. See also issue 48.
2163 D.23 lc-29-lang
2165 Type: edit
2167 [42]
2169 reuterj@ira.uka.de (2000-02-07): Section 6, para 4: Obvious, doesn't
2170 need to be stated. Maybe note in an example.
2172 Resolution: Agreed. See also issue 48.
2174 D.24 lc-49-put
2176 Type: change
2178 [43]
2180 yarong@Exchange.Microsoft.com (2000-02-11): Remove the last sentence
2181 of Example 6.2, which says that PUT replaces the reference with a
2182 different resource.
2184 Resolution: No longer relevant. Deleted this example in response to
2185 issue 48.
2187 D.25 lc-44-pseudo
2189 Type: change
2191 [44]
2193 yarong@Exchange.Microsoft.com (2000-02-11): Instead of adding an
2194 optional prop XML element to the response element in 207 responses,
2195 define a new location XML element and a new refresource XML element.
2197 Resolution: Agree to define new XML elements that are not
2198 pseudo-properties. Disagreement about whether refresource is needed.
2200 See issue 61.
2202 D.26 lc-61-pseudo
2204 Type: change
2206 [45]
2208 reuterj@ira.uka.de (2000-02-14): Section 7: It doesn't make sense to
2209 ask future editors of RFC 2518 to define DAV:location with the
2210 semantics it has here. RFC 2518 should provide the information in the
2211 Location header somehow in multistatus responses, but not by using
2212 properties.
2214 Resolution: Define an XML element for location that is not a
2215 pseudo-property. We'll keep the recommendation that RFC 2518 add this
2216 for 302 responses. See also issue 44.
2218 D.27 lc-60-ex
2220 Type: change
2222 [46]
2224 reuterj@ira.uka.de (2000-02-14): Section 7, para 3: Make it clear
2225 that these are just examples of client behavior, and are not meant to
2226 limit the client's behavior to these options.
2228 Resolution: Agreed to delete this paragraph. Continue discussion of
2229 what information should be returned with 302 in multistatus. Just
2230 location? Also redirectref?
2232 D.28 lc-62-oldclient
2234 Type: change
2236 [47]
2238 reuterj@ira.uka.de (2000-02-14): Section 7: It's too strong to claim
2239 that non-referencing clients can't process 302 responses occurring in
2240 Multi-Status responses. They just have an extra round trip for each
2241 302.
2243 Resolution: Remove last sentence of the paragraph that recommends
2244 changes to RFC 2518.
2246 D.29 lc-63-move
2247 Type: change
2249 [48]
2251 reuterj@ira.uka.de (2000-02-14): Section 7.1: Is MOVE atomic from the
2252 perspective of a client? Agrees that there should be no 302s for
2253 member redirect references, but finds the rationale dubious.
2255 Resolution: Remove 7.1. Reword 7.2 to avoid concerns with "poses
2256 special problems" and "due to atomicity".
2258 D.30 lc-06-reftarget-relative
2260 Type: change
2262 [49]
2264 joe@orton.demon.co.uk (2000-01-29): Why does the spec talk about
2265 relative URIs in DAV:reftarget in MKRESOURCE requests? Is the server
2266 required to resolve the relative URI and store it as absolute? Is the
2267 server required to keep DAV:reftarget pointing to the target resource
2268 as the reference / target move, or is DAV:reftarget a dead property?
2270 Resolution: DAV:reftarget is readonly and present only on redirect
2271 references that are also WebDAV resources. Add a method for setting
2272 the target. Change definition of Redirect-Ref header so that it has
2273 the target as its value (comes back on all 302 responses). Server
2274 MUST store the target exactly as it is set. It MUST NOT resolve
2275 relatives to absolutes and MUST NOT update if target resource moves.
2276 See also issue 17, 43, 50, 57
2278 D.31 lc-57-noautoupdate
2280 Type: change
2282 [50]
2284 yarong@Exchange.Microsoft.com (2000-02-11): Add language to forbid
2285 servers from automatically updating redirect resources when their
2286 targets move.
2288 Resolution: Agreed. See also issue 6.
2290 D.32 lc-71-relative
2292 Type: change
2294 [51]
2295 reuterj@ira.uka.de (2000-02-14): Section 9: Base URI should be the
2296 Request-URI or href minus its final segment.
2298 Resolution: Fix this.
2300 D.33 lc-53-s10
2302 Type: change
2304 [52]
2306 yarong@Exchange.Microsoft.com (2000-02-11): The behavior described in
2307 this section would have a very serious impact on the efficiency of
2308 mapping Request-URIs to resources in HTTP request processing. Also
2309 specify another type of redirect resource that does not behave as in
2310 section 10, but instead would "expose the behavior we see today in
2311 various HTTP servers that allow their users to create 300 resources."
2312 Be sure we know what behavior will be if the redirect location is not
2313 an HTTP URL, but, say ftp.
2315 Resolution: We won't define 2 sorts of redirect references here.
2316 Servers SHOULD respond with 302 as described here, but if they can't
2317 do that, respond with 404 Not Found. (It's hard to modularize the
2318 behavior specified - it impacts processing Not Found cases of all
2319 methods, so you can't just add it to an HTTP server in a redirect ref
2320 module.)
2322 D.34 lc-72-trailingslash
2324 Type: change
2326 [53]
2328 reuterj@ira.uka.de (2000-02-14): Section 10: Forbid DAV:reftarget
2329 from ending in "/"
2331 Resolution: Make the note warn about the possibility of two slashes
2332 in a row, recommend against ending target with a slash, since that
2333 could result in two slashes in a row.
2335 D.35 lc-50-blindredirect
2337 Type: change
2339 [54]
2341 yarong@Exchange.Microsoft.com (2000-02-11): Replace current language
2342 explaining the purpose of the Redirect-Ref header with language that
2343 simply states that it marks blind 302 responses from redirect
2344 resources. (Section 6.3, 11.1)
2346 Resolution: Section 6.3 was removed in response to issue 48. In 11.1,
2347 change the definition of the Redirect-Ref header to have the value of
2348 the target (relative URI) as its value. Then we don't need a method
2349 for retrieving the target's relative URI. Presence of the
2350 Redirect-Ref header lets the client know that the resource accepts
2351 Apply-To-RR header and the new method for updating target. Reject
2352 Yaron's suggested language, but make the above changes.
2354 D.36 lc-74-terminology
2356 Type: change
2358 [55]
2360 reuterj@ira.uka.de (2000-02-14): "plain HTTP/1.1 redirect" - find
2361 some good name for this an use it consistently
2363 D.37 lc-75-ignore
2365 Type: change
2367 [56]
2369 reuterj@ira.uka.de (2000-02-14): 11.2: "If the Apply-To-Redirect-Ref
2370 header is used on a request to any other sort of resource besides a
2371 redirect reference resource, the server SHOULD ignore it." Don't need
2372 to say this since HTP already says that any header that is not
2373 understood should be ignored.
2375 D.38 lc-76-location
2377 Type: change
2379 [57]
2381 reuterj@ira.uka.de (2000-02-22): 12.2: Make DAV:location a real
2382 (live) property, get rid of the DAV:reftarget property
2384 D.39 lc-79-accesscontrol
2386 Type: change
2388 [58]
2390 reuterj@ira.uka.de (2000-02-22): Section 16.4: "In some environments,
2391 the owner of a resource might be able to use access control to
2392 prevent others from creating references to that resource." That would
2393 not be consistent with the concept of redirect references as weak
2394 links (e.g. think of moving a resource to a different locationo that
2395 is already the target of some redirection reference.
2397 D.40 lc-80-i18n
2399 Type: change
2401 [59]
2403 reuterj@ira.uka.de (2000-02-22): Section 17: Could get rid of a lot
2404 of this section, since this protocol extends WebDAV. Just reference
2405 [WebDAV].
2407 D.41 lc-55-iana
2409 Type: change
2411 [60]
2413 yarong@Exchange.Microsoft.com (2000-02-11): Expand the IANA section
2414 to list all methods, headers, XML elements, MIME types, URL schemes,
2415 etc., defined by the spec.
2417 Resolution: Agreed.
2419 Intellectual Property Statement
2421 The IETF takes no position regarding the validity or scope of any
2422 intellectual property or other rights that might be claimed to
2423 pertain to the implementation or use of the technology described in
2424 this document or the extent to which any license under such rights
2425 might or might not be available; neither does it represent that it
2426 has made any effort to identify any such rights. Information on the
2427 IETF's procedures with respect to rights in standards-track and
2428 standards-related documentation can be found in BCP-11. Copies of
2429 claims of rights made available for publication and any assurances of
2430 licenses to be made available, or the result of an attempt made to
2431 obtain a general license or permission for the use of such
2432 proprietary rights by implementors or users of this specification can
2433 be obtained from the IETF Secretariat.
2435 The IETF invites any interested party to bring to its attention any
2436 copyrights, patents or patent applications, or other proprietary
2437 rights which may cover technology that may be required to practice
2438 this standard. Please address the information to the IETF Executive
2439 Director.
2441 Full Copyright Statement
2443 Copyright (C) The Internet Society (2003). All Rights Reserved.
2445 This document and translations of it may be copied and furnished to
2446 others, and derivative works that comment on or otherwise explain it
2447 or assist in its implementation may be prepared, copied, published
2448 and distributed, in whole or in part, without restriction of any
2449 kind, provided that the above copyright notice and this paragraph are
2450 included on all such copies and derivative works. However, this
2451 document itself may not be modified in any way, such as by removing
2452 the copyright notice or references to the Internet Society or other
2453 Internet organizations, except as needed for the purpose of
2454 developing Internet standards in which case the procedures for
2455 copyrights defined in the Internet Standards process must be
2456 followed, or as required to translate it into languages other than
2457 English.
2459 The limited permissions granted above are perpetual and will not be
2460 revoked by the Internet Society or its successors or assignees.
2462 This document and the information contained herein is provided on an
2463 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
2464 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
2465 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
2466 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
2467 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2469 Acknowledgment
2471 Funding for the RFC Editor function is currently provided by the
2472 Internet Society.