Re: GETSRC & MULTIPUT

> > On Tue, Oct 30, 2001 at 12:19:27PM -0800, Eric Sedlar wrote:
> > > The fundamental question that must be addressed is whether or
> > not the source
> > > resource and the output resource are the same.  To me, the
> > question boils
> > > down to wanting to have symmetry in my methods.  If I call
> > PROPPATCH, I can
> > > then use PROPFIND to see the properties I just wrote.  We need the same
> > > thing for PUT.  If I call PUT on a URL, I want a method that
> > gets me back
> > > the stuff I just PUT at that URL.
> >
> > GET already provides that -- if you can successfully invoke PUT on a
> > resource, then a GET on that same resource will be the stuff that you PUT
> > (assuming no other actions occurred in-between).
> >
> > However, PUT is not allowed on many resources, specifically those
> > resources
> > that only exist as a synthesis of other resources.  The source
> > links, which
> > were present in the original HTTP/1.1 proposal and later transformed into
> > a property in 2518, tell the client how it can edit that resource
> > given that
> > authoring on the same URI is not possible, period.
> 
> Well, that's interesting to know, but -- from looking at RFC2518 this is
> just "hear-say". What you say makes sense, but it's certainly not what
> RFC2518 says (or doesn't say: that when a resource has a source property it
> can't be PUT to).

It is theoretically possible for a synthetic resource to be edited by
GET and PUT of its representation, assuming that the server is smart
enough to derive the individual source changes from the modified
representation.  However, that is not an issue, since from the client's
perspective it seems to be editing a static representation.  The whole
point of the source links is to allow the server to tell the client
that "Hey, I'm not smart enough to figure out editing on this interface,
you need to go over to this list of things and edit them individually."
That is a condition of interoperability that is necessary to communicate
between the server and client due to the nature of Web resources.

There are other conditions in which the source URI would differ from the 
"normal" GET URI, such as when authoring is only allowed on a staging
server.  In those cases as well, a GETSRC method or Translate header field
simply will not work.  I cannot understand why it would even be considered.

I am sure that the RFC can be improved to spell this out in more detail,
but that is not unusual for this stage of the standardization process.

....Roy


It doesn't say that, and nothing I said implies it would.  You are reversing
the implication of what I said, which isn't valid logic.

Received on Tuesday, 30 October 2001 19:55:51 UTC