Review: Redirect Reference Resources -- Part two

Following the working group's last call for comments, below is the
second part of a review of the Redirect Reference Resources Protocol.
It covers chapters 7 to 11 of the protocol.

********

> 7 Operations on Collections That Contain Redirect Reference Resources
> ...
> Consistent with the rules in Section 6, the response for each redirect 
> reference encountered while processing a collection MUST be a 302 
> (Found) unless a Apply-To-Redirect-Ref header is included with the 
> request.

Just an idea: one could consider to specify the field value of the
Apply-To-Redirect-Ref header to optionally contain a list of internal
member URIs, allowing a request method on a collection to apply to
redirect reference resources for a selected set of URIs only.

> The DAV:location pseudo-property ...

Just wondering: why is it called a "pseudo"-property?  Is there
anything on it that does not match the regular definition of a DAV
property?

> A referencing-aware client can either use the URI value of 
> the DAV:location pseudo-property to resubmit its request to the target 
> resource, or it can submit the request to the redirect reference 
> resource with Apply-To-Redirect-Ref.  

Once again, I suppose you merely want to present two examples of
typical behaviour that a client may choose rather than limiting the
client's capabilities of submitting requests.  Hence, I move to fix
the wording accordingly.

> It is recommended that future editors of [WebDAV] define the
> DAV:location pseudo-property in [WebDAV], so that non-referencing
> clients will also be able to use the response to operate on the target
> resource.

This specification introduces redirect references to be viewed as
WebDAV resources, while, from the perspective of WebDAV, redirect
references are still no WebDAV resources.  Hence, in WebDAV, redirect
references can not be associated with properties.  In so far, I do not
see how to introduce a DAV:location property in WebDAV with the
imposed semantics.

> (This will also enable clients to operate on traditional
> HTTP/1.1 302 responses in Multi-Status responses.)

This probably should read: "This can also save one round-trip for
WebDAV clients when operating on HTTP/1.1 302 responses in
Multi-Status responses arisen from either ordinary redirect references
or redirect reference resources."

> Until then, non-
> referencing clients will not be able to process 302 responses from
> redirect reference resources encountered while processing a
> collection.

That is not true.  You just have to do one more round-trip for each
302 response.

Summarizing the last three paragraphs, I think it might be a good idea
for future WebDAV specifications to somehow include the information of
the Location response header field for each 302 response in a
Multi-Status response; but I think this can not be done using resource
properties as currently defined in WebDAV.  By the way, is that the
reason why the DAV:location property is called a "pseudo"-property?

> 7.1 MOVE and DELETE on Collections That Contain Redirect References
> ...
> MOVE removes that binding and creates a new binding to the same
> resource.

Atomically (from WebDAV clients' perspective)?

> In cases where DELETE and MOVE are applied to a collection, these 
> operations affect all the descendents of the collection, but they do so 
> indirectly.
> There is no need to visit each descendent in order to process the
> request.
> Consequently, even if there are redirect reference
> resources in a tree that is being deleted or moved, there will be no
> 302 responses from the redirect reference resources.

I agree that there should be no 302 repsonses, but I can not follow
the argumentation.

For DELETE on collections, WebDAV says: "DELETE instructs that the
collection specified in the Request-URI and all resources identified
by its internal member URIs are to be deleted."  In the case of a
redirect reference resource, this means that the redirect reference
resource is to be deleted.  Note, that WebDAV does not require a
DELETE to be performed on the resource, but that the resource be
deleted.  Hence, for a DELETE on a collection, there will be no 302
response from a redirect reference resource in a collection.

Similary, for a MOVE on a collection, WebDAV does not require a MOVE
to be performed on each resource identified by the internal member
URIs of the collection identified by the Request-URI be moved, but
each of these resources be moved to locations relative to the
Request-URI.  Hence, for a MOVE on a collection, there will be no 302
response from a redirect reference resource in a collection.

For MOVE on collections, WebDAV says: "A MOVE with "Depth: infinity"
instructs that the collection identified by the Request-URI be moved
to the URI specified in the Destination header, and all resources
identified by its internal member URIs are to be moved to locations
relative to it, recursively through all levels of the collection
hierarchy."  Once again,

It may be worth noting that, when the DAV:reftarget property contains
a relative URI, a MOVE applied to a collection may result in redirect
reference resources with dangling references.  Anyway, is there any
difference in the semantics between a DAV:reftarget property and a
DAV:location property except that DAV:reftarget may be a relative URI?
If not, could the DAV:reftarget be dropped and DAV:location always be
used instead?  By the way, HTTP/1.1 does not allow a Location URI to
be relative.  I do not know the reason, but could that also be a good
reason to forbid relative URIs as DAV:reftarget properties?

> 7.2 LOCK on a Collection That Contains Redirect References
>
> LOCK poses special problems because it is atomic. An attempt to lock 
> (with Depth: infinity) a collection that contains redirect references 
> will always fail.

Probably, this should read "MUST always fail" instead of "will always
fail".  However, I do not understand why it should fail at all.  As
far as I understand section 7.1, upon a DELETE redirect references are
deleted rather than returning a 302 response.  What is the reason that
LOCK should behave differently?

> Reference-aware clients can lock the collection by using Apply-To-
> Redirect-Ref, and, if desired, lock the targets of the redirect 
> references individually.

I see.  The first paragraph of this section will prevent clients
unaware of this specification to LOCK a collection that contains
redirect references, while the above paragraph allows clients aware of
this specification to perform the LOCK.

However, section 8.4.10 of WebDAV says: "If the Depth header is set to
infinity then the resource specified in the Request-URI along with all
its internal members, all the way down the hierarchy, are to be
locked."

In the case of a redirect reference resource, I think the intended
meaning of WebDAV is that the resource itself is the internal member
to be locked, not the target resource.  In so far, I think, the
Apply-To-Redirect-Ref target should implicitly always be set, and a
LOCK request for a collection MUST fail if in the hierarchy of
collections there is an ordinary redirect reference as internal
member.

> 7.3 Example: PROPFIND on a Collection with Redirect Reference Resources
>
> Suppose a PROPFIND request with Depth = infinity
> ...

'Depth = infinity' probably should read '"Depth: infinity"'.

> 7.4 Example: PROPFIND with Apply-To-Redirect-Ref on a Collection with 
> Redirect Reference Resources
> ...
> Depth = infinity

Cp. section 7.3.

> Since the Apply-To-Redirect-Ref header is present, the response shows 
> the properties of the redirect reference resource in the collection 
> rather than the properties of its target.

The response should not show the properties of the target even if the
Apply-To-Redirect-Ref header is not present, since the purpose of a
redirect reference resource is "to forward requests to another
resource (its target)" (see introduction), unlike a direct reference
resource that "automatically forwards requests to another resource, in
a way that is transparent to the client" (see chapter 3).

> 7.6 Example: LOCK on a Collection That Contains a Redirect Reference 
> Resource
> ...
> >> Response:
>
> HTTP/1.1 207 Multi-Status

Section 8.10.4 of WebDAV requires that "if the lock cannot be granted
to all resources, a 409 (Conflict) status code MUST be returned with a
response entity body ... ".  (FYI: The example in section 8.10.10 of
WebDAV also erroneously returns a 207 code.)

> ...
>    <D:response>
>       <D:href>http://www.svr.com/MyCollection/diary.html</D:href>
>       <D:status>HTTP/1.1 424 Failed Dependency</D:status>
>    </D:response>

Although WebDAV does not clearly state when a 424 code should be
returned upon a failed LOCK, from the example in 8.10.10 of WebDAV, I
guess that upon diary.html there should no 424 be returned, because it
is not an ancestor of a member that is responsible for the LOCK
failing (and this behaviour would be analogous to that of DELETE as
described in section 8.6.2 of WebDAV).

> ...
> At that point both the reference resource 
> and its target resource will be locked

Once again, I think that at that point the target resource should not
be locked, according to the purpose of a redirect reference resource
"to forward requests to another resource (its target)".

> 8 Operations on Targets of Redirect Reference Resources
>
> Operations on targets of redirect reference resources have no effect on 
> the reference resource. 

This is yet another reason that at that point (see previous paragraph)
the target resource should not be locked.

> 9 Relative URIs in DAV:reftarget
>
> The URI in the href in a DAV:reftarget property MAY be a relative
> URI.  

See above comment on relative URIs in last paragraph to section 7.1.

> In this case, the base URI to be used for resolving the relative URI to 
> absolute form is the URI used in the HTTP message to identify the 
> redirect reference resource to which the DAV:reftarget property belongs.  

It may be worth noting that section 5.1 of WebDAV mentions that
multiple URIs may identify a single resource: "Although implicit in
[RFC2068] and [RFC2396], any resource, including collection resources,
MAY be identified by more than one URI. For example, a resource could
be identified by multiple HTTP URLs."  Hence, resolution of the
relative URI for a single resource may result in multiple absolute
URIs, depending on the URI used in the current HTTP request message.

> When DAV:reftarget appears in the context of a Multi-Status response, it 
> is in a DAV:response element that contains a single DAV:href element.  
> The value of this DAV:href element serves as the base URI for resolving 
> a relative URI in DAV:reftarget.

It should be noted that in this context the value of the DAV:href
element always denotes a redirect reference resource, i.e. a
non-collection resource.  Hence, to resolve a relative URI in
DAV:reftarget, the last segment of the DAV:href element must be
ignored.  Otherwise, in the example in section 9.2, the resolved URI
would become
"http://www.xxsrv.com/geog/stats.html/statistics/population/1997.html"
instead of
"http://www.xxsrv.com/geog/statistics/population/1997.html".

> 10 Redirect References to Collections
> ...
> Note: If the DAV:reftarget property ends with a "/" and the remainder of 
> the Request-URI is non-empty (and therefore must begin with a "/"), the 
> final "/" in the DAV:reftarget property is dropped before the remainder 
> of the Request-URI is appended.

I suggest to consider that the value of a DAV:reftarget property MUST
NOT end with a "/".

> /x/ -----> /a/
>            /a/y/ -----> /b/
>                         /b/z.html -----> /c/d.html

Personally, I would prefer a slightly different visualisation that
shows the process of substitution, e.g. something like the following:

/x/y/z.html
    |
    | /x -> /a
    |
    v
/a/y/z.html
    |
    | /a/y -> /b
    |
    v
/b/z.html
    |
    | /b/z.html -> /c/d.html
    |
    v
/c/d.html

> 11 Headers
>
> 11.1 Redirect-Ref Response Header
> ...
> not a plain HTTP/1.1 redirect
> ...

Yet another term for "ordinary redirect reference"?

> 11.2 Apply-To-Redirect-Ref Request Header
>

See the above suggestion for an extension of this header in chapter 7.

See the above discussion on forwarding and direct reference resources
in chapters 4, 5 and section 7.3.

> If the Apply-To-Redirect-Ref header is used on a request to any other 
> sort of resource besides a redirect reference resource, the server 
> SHOULD ignore it. 

This is redundant, as HTTP/1.1 already requires any unrecognized
header to be ignored.

... to be continued ...


     Juergen Reuter

Received on Monday, 14 February 2000 11:33:07 UTC