Re: [Ietf-caldav] [Fwd: draft-reschke-http-addmember-00]

Julian Reschke wrote:
> >Read section 5.4 "Source Resources and Output Resources" in RFC 2518, 
> >WebDAV.
> >(That part's not specific to WebDAV; it's a just a good explanation).
> 
> In fact, it says:
> 
> "However, if remote editing of the source resource(s) is desired, the 
> source resource(s) should be given a location in the URI namespace. This 
> source location should not be one of the locations at which the 
> generated output is retrievable, since in general it is impossible for 
> the server to differentiate requests for source resources from requests 
> for process output resources."

Indeed, it's not a requirement though, and people do actually use PUT
to update source resources using the output URI space.

> >>From the client's point of view, once you have PUT an entity, in
> >general you have no way to retrieve that exact entity.  Many servers
> >will process the resource you created to produce the response to GET,
> >instead of merely returning the entity you sent earlier.
> >
> >Because you can't necessarily retrieve the entity sent, you can't make
> >assumptions about what the server stores.  It might store only part of
> >what you sent, or a transformed version.  What it actually stores --
> >and the side effects of doing so -- are quite open.
> 
> You keep saying this, but it would be nice if you could point out where 
> that kind of behaviour is described.

I don't know if it is explicitly described.  Section 5.4 of WebDAV
seems to come closest.

> RFC2616 says:
> 
> "The PUT method requests that the enclosed entity be stored under the 
> supplied Request-URI."

Yes, it's a request, not a SHOULD or MUST.  It also doesn't say what
the server will actually do with the entity when it's stored URI.

As a test, I just tried it on my Apache 2 server with CGI execution
enabled.  PUT to a .cgi URI overwrites a CGI script; GET runs it and
returns the parsed output.

That's a fairly standard configuration, and I think that mode of
operation is quite widely used too (updating a web site with scripts
using PUT).

> And that's certainly what today's WebDAV servers implement and WebDAV 
> clients do expect.

Sure, but forget about WebDAV for a moment, I only brought up that
document because of the nice text on source and output resources.

Real servers do sometimes store the sent entity using PUT, but return
a processed output from GET at the same URI -- and people do actually
use that feature sometimes.

And so you can't have an intermediary _assume_ PUT will stick to the
behaviour you think it should - even if we had a consensus that it
should.

And so, for ADDMEMBER to be useful, you need to specify it more
tightly than "PUT except the created resource URI is selected
differently".

If you do that, it makes sense.  If you don't, then ADDMEMBER is no
different from POST.

That said, even if you do specify ADDMEMBER more tightly, I still
don't see how the difference would benefit you.  You say it could be
useful to an intermediary, but can you give a plausible example?

-- Jamie

Received on Thursday, 17 February 2005 20:30:50 UTC