- From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
- Date: Thu, 27 Jan 2000 16:45:28 -0500
- To: w3c-dist-auth@w3.org
From: Joe Orton <joe@orton.demon.co.uk> I am trying to understand the redirectref-02 spec, and feel I've missed something fundamental. It starts with: "A redirect reference resource is a resource in one collection whose purpose is to forward requests to another resource" Note: That "in one collection" phrase should be deleted. It is irrelevant to the functionality of redirect references. This makes sense to me; we have a special type of resource, which, when we try and do things to it, it will respond with "No, go away and do it to this other resource instead". Enough said. Then it says this: "A redirect reference is a resource, and so can have properties and a body of its own." Okay, a resource can have properties defined on it; this is WebDAV. But, "a body of its own". What does that mean? Have resources become confused with HTTP messages? The term "resource body" is often used as a shorthand for "what appears in a GET response body when applied to that resource". That's what is intended here. Is there a better term to use? On to section 6: "A redirect reference resource MAY have a body, though none is defined for it in this specification. The PUT method can be used, with Apply-To-Redirect-Ref, to create or replace the body of a redirect reference resource.". So, if we have a redirect reference resource at URI X, when we try and access it as any normal resource, it tells us to go to URI Y instead. But, we can also, using a PUT with the Apply-To-RR header, submit an entity-body, have it stored at this URI, then fetch it again later with a GET and the same header. So, there are actually *two* separate resources identified by URI X; the special RR resource, and the extra one we submitted with the PUT. Yes, there are two separate resources, the one at URI X and the one at URI Y. Except that these two resources share the same URI, and the same DAV properties. No, the two separate resources have two separate URI's (X and Y) and two separate sets of properties. The resource at X tells you to go look at the resource at Y, but X and Y are two separate URI's (unless X happens to be Y, which is possible, but not very useful :-). Is this really the intent of the authors? Is there a need to store an extra resource along with every RR resource? The extra resource is minimally needed to store the information about what other resource to redirect to. It is useful to give the redirect reference additional properties as well, independent of whatever properties are at the (current) target of the reference. Now sec 6.2, with an example of a PUT to a RR resource with the Apply-to-RR header: "The result in this case is that the reference resource is replaced by a non-reference resource having the content submitted with the request." This seems to imply that in a PUT to an RR resource, the RR resource is removed, and another one replaces it, losing the "302" stuff, and contradicting the above semantics? Yup, that's a contradiction, all right! We could do any of: - get rid of the "an RR resource can have a body" statement - get rid of this statement and change the example to say the PUT MUST fail. - keep the statement, and change the example to say the PUT updates the body of the RR resource. I could live with any of these choices. To me, a PUT or a GET to a RR resource, *with* the Apply-to-RR header, should fail, since this is a special resource, with special semantics, in the same way that a collection resource is. A 4xx response will do fine in this case. That's one vote for choice #3. Anyone else? Cheers, Geoff
Received on Thursday, 27 January 2000 16:45:30 UTC