Subject: Bodies of redirect reference resources

From: Joe Orton <[email-masked]>
Date: Wed, 26 Jan 2000 22:08:18 +0000

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"

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?

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. Except that these two resources share the same
URI, and the same DAV properties. Is this really the intent of the
authors? Is there a need to store an extra resource along with every RR
resource?

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? Maybe this was supposed to say "the
body of the reference resource is ..."?

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.

Regards,

joe

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Thu, 27 Jan 2000 16:45:28 -0500

From: Joe Orton <[email-masked]>

Note: That "in one collection" phrase should be deleted.  It is irrelevant
to the functionality of redirect references.

   Then it says this:

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:

   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.

   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.

That's one vote for choice #3.  Anyone else?

Cheers,
Geoff

---

From: Joe Orton <[email-masked]>
Date: Sat, 29 Jan 2000 22:06:13 +0000

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

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

> 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

Agreed.

> 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

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Sun, 30 Jan 2000 23:45:03 -0500

methods to it.

I agree.

   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.

The presence of properties makes this a bit more ambiguous.  If you try
to get the properties of X, it will say "no, go to URI Y instead".  But
the RR X does have properties of its own, that you can obtain with the
Apply-To-RR header.  By analogy, it would be reasonable for X to have
an entity-body that you can obtain with the Apply-To-RR header. 
This doesn't convince me that RR resources should have entity-bodies,
but it is argument that it is reasonable to do so.

Yes.  I think this is a good argument against giving them a body ...
people will find this confusing, and experience in other domains indicate
that an entity body is not needed or appropriate for references.

   >    Is there a need to store an extra resource along with every RR
   >    resource?
   > 

I misunderstood you the first time.  By "extra resource", I meant the
RR resource itself.  You were talking about an extra resource *in addition*
to the RR resource.  I agree that there is no need for an extra resource
beyond the RR resource.  But the RR resource could have an entity body,
in addition to its properties.

   > - keep the statement, and change the example to say the PUT
   >   updates the body  of the RR resource.

   > That's one vote for choice #3.  Anyone else?

   Either you misunderstood, or miscounted :)

Neither ... mistyped (:-).

   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.

So we've got a vote for *2*.  Anyone else?

Cheers,
Geoff