Re: Bodies of redirect reference resources

   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