Re: Bodies of redirect reference resources

> 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?

I don't think this term is needed at all ;) But, since you asked, 2616's
"entity-body" seems synonymous with that "what appears... " phrase.

>    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.

To me, the "reference resource" should be a resource in its own right: a
conceptual thingy which say "No, go to URI Y instead", when you apply HTTP
methods to it. If you are trying to store an entity-body at URI X along
with this RR, then that is two separate resources, one which has the "No,
go to URI Y instead" semantics, and one which has the standard "I can
store an entity-body with PUT and give it back with GET" semantics.

Unix symlinks have precedent again here: you can't store a file in a
symlink. Windows shortcuts are the same, I expect.

>    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. 

What "information about the other resource" do you want to store? Why
can't you store it in the properties of the RR? To me the only vital
information you want to store in the RR is the target of the reference,
which you have as the DAV:reftarget property.

> It is useful to give the redirect
> reference additional properties as well, independent of whatever 
> properties are at the (current) target of the reference.

Agreed.

> 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.
[snip]
> 
> That's one vote for choice #3.  Anyone else?

Either you misunderstood, or miscounted :) I vote #2: get rid of any
mention of "resource body", and have PUT + GET fail with 4xx if the
Apply-To-RR header is included.

Regards,

joe

Received on Saturday, 29 January 2000 17:08:33 UTC