- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sat, 01 Oct 2005 21:40:37 +0200
- To: webdav <w3c-dist-auth@w3.org>
- CC: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>, John Baumgarten <jbaumgarten@apple.com>
Geoffrey M Clemm wrote:
>
> I agree with Julian that the Depth infinity section of redirectref should
> be redefined based on this implementation experience.
>
> Cheers,
> Geoff
OK, I finally got around reviewing the issue. I have changed the spec
based on the principle of "least client astonishment", letting the
behaviour default to "the right thing". That is, non redirect-aware
clients will see no difference when applying LOCK, COPY, MOVE or DELETE
to a collection that may contain redirects. (Our server currently obeys
the Apply-To-Redirect-Ref header for COPY and MOVE, but I'm not aware of
any use case depending on that, so I'll simply change the behaviour).
Not surprisingly, the spec has gotten quiet a bit shorter because of that.
Feedback appreciated -- I'd like to submit this as a revised draft
addressing all WGLC comments before the cutoff date for the upcoming IETF.
Best regards, Julian
--
Link to issue for tracking:
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-redirectref-protocol-issues.html#8.1_deep_lock_complexity>
Link to latest edits (includes change tracking):
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-redirectref-protocol-latest.html>
Revised spec text (Section 8):
8. Operations on Collections That Contain Redirect Reference Resources
According to [RFC2518], Section 9.2, methods that have defined
interactions with the "Depth" request header should apply all other
request headers to each resource in scope. However, applying this
principle to the "Apply-To-Redirect-Ref" header uniformly would make
it impractical to implement this specification on top of existing
servers and also would result in unexpected server behaviour for
clients that do not take the existence of redirect references into
account. On the other hand, the definition of the "Depth" header
allows to explicitly define alternate behaviours.
For this reason, this specification defines the interaction between
"Depth" and "Apply-To-Redirect-Ref" request headers on a case-by-case
basis, and also provides a default for methods not mentioned here
that do not specify the behaviour themselves.
+-------------+-----------------+------------------+-----------+
| method name | defined in | supported depths | behaviour |
+-------------+-----------------+------------------+-----------+
| COPY | [RFC2518], 8.9 | 0, infinity | "T" |
| DELETE | [RFC2518], 8.7 | infinity | "T" |
| LOCK | [RFC2518], 8.11 | 0, infinity | "T" |
| MOVE | [RFC2518], 8.10 | 0, infinity | "T" |
| PROPFIND | [RFC2518], 8.2 | 0, 1, infinity | inherit |
| REPORT | [RFC3253], 3.6 | 0, 1, infinity | inherit |
| default | | | "T" |
+-------------+-----------------+------------------+-----------+
When the behaviour is defined to be "inherit", the method should
follow RFC2518's default behaviour for "Depth" operations, which
means applying the value given for "Apply-To-Redirect-Ref" to each
resource in scope. On the other hand, when it is defined to be "T",
the method should behave as if a "Apply-To-Redirect-Ref: T" header
was specified for each operation on child resources. The latter
ensures that "Depth: infinity" operations will not fail unexpectedly
just because there was a redirect reference resource in scope.
8.1 Example: PROPFIND on a Collection with Redirect Reference Resources
Suppose a PROPFIND request with Depth: infinity is submitted to the
following collection, with the members shown here:
/MyCollection/
(non-reference resource) diary.html
(redirect reference resource) nunavut
>> Request:
PROPFIND /MyCollection/ HTTP/1.1
Host: example.com
Depth: infinity
Apply-To-Redirect-Ref: F
Content-Type: text/xml
Content-Length: xxxx
<?xml version="1.0" ?>
<D:propfind xmlns:D="DAV: ">
<D:prop xmlns:J="http://example.com/jsprops/">
<D:resourcetype/>
<J:keywords/>
</D:prop>
</D:propfind>
>> Response:
HTTP/1.1 207 Multi-Status
Content-Type: text/xml
Content-Length: xxxx
<?xml version="1.0" ?>
<D:multistatus xmlns:D="DAV:" xmlns:J="http://example.com/jsprops/">
<D:response>
<D:href>/MyCollection/</D:href>
<D:propstat>
<D:prop>
<D:resourcetype><D:collection/></D:resourcetype>
<J:keywords>diary, interests, hobbies</J:keywords>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>/MyCollection/diary.html</D:href>
<D:propstat>
<D:prop>
<D:resourcetype/>
<J:keywords>diary, travel, family, history</J:keywords>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>/MyCollection/nunavut</D:href>
<D:status>HTTP/1.1 302 Found</D:status>
<D:location>
<D:href>http://example.ca/art/inuit/</D:href>
</D:location>
</D:response>
</D:multistatus>
In this example the Depth header is set to infinity, and the Apply-
To-Redirect-Ref header is set to "F". The collection contains one
URI that identifies a redirect reference resource. The response
element for the redirect reference resource has a status of 302
(Found), and includes a DAV:location extension element to allow
clients to retrieve the properties of its target resource. (The
response element for the redirect reference resource does not include
the requested properties. The client can submit another PROPFIND
request to the URI in the DAV:location pseudo-property to retrieve
those properties.)
8.2 Example: PROPFIND with Apply-To-Redirect-Ref on a Collection with
Redirect Reference Resources
Suppose a PROPFIND request with "Apply-To-Redirect-Ref: T" and Depth:
infinity is submitted to the following collection, with the members
shown here:
/MyCollection/
(non-reference resource) diary.html
(redirect reference resource) nunavut
>> Request:
PROPFIND /MyCollection/ HTTP/1.1
Host: example.com
Depth: infinity
Apply-To-Redirect-Ref: T
Content-Type: text/xml
Content-Length: xxxx
<?xml version="1.0" ?>
<D:propfind xmlns:D="DAV:">
<D:prop>
<D:resourcetype/>
<D:reftarget/>
<D:redirect-lifetime/>
</D:prop>
</D:propfind>
>> Response:
HTTP/1.1 207 Multi-Status
Content-Type: text/xml
Content-Length: xxxx
<?xml version="1.0" ?>
<D:multistatus xmlns:D="DAV:">
<D:response>
<D:href>/MyCollection/</D:href>
<D:propstat>
<D:prop>
<D:resourcetype><D:collection/></D:resourcetype>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
<D:propstat>
<D:prop>
<D:reftarget/>
<D:redirect-lifetime/>
</D:prop>
<D:status>HTTP/1.1 404 Not Found</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>/MyCollection/diary.html</D:href>
<D:propstat>
<D:prop>
<D:resourcetype/>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
<D:propstat>
<D:prop>
<D:reftarget/>
<D:redirect-lifetime/>
</D:prop>
<D:status>HTTP/1.1 404 Not Found</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>/MyCollection/nunavut</D:href>
<D:propstat>
<D:prop>
<D:resourcetype><D:redirectref/></D:resourcetype>
<D:reftarget>
<D:href>http://example.ca/art/inuit/</D:href>
</D:reftarget>
<D:redirect-lifetime><D:temporary/></D:redirect-lifetime>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
Since the "Apply-To-Redirect-Ref: T" header is present, the response
shows the properties of the redirect reference resource in the
collection rather than reporting a 302 status.
Received on Saturday, 1 October 2005 19:41:20 UTC