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

Julian Reschke wrote:
> Because in general, I will have no idea what the server will do with the 
> POST.

In general, you don't know what it will do with ADDMEMBER either.

This is better illustrated with PUT.  Clearly, PUT is intended for
creating or modifying an entity at a client-specific URI.

I have the impression you expect this is literally what PUT should do:
that afterwards, GET from that URI, if permitted, will return the last
entity that was put.

Plenty of HTTP servers which don't work like that.  Often, you can PUT
to a URI ending in ".cgi" or ".php" for example, and (possibly
depending on the put'd content type, possibly not) GET will not return
the same entity; instead it will initiate processing using the
resource now present at that URI.

You can PUT to a URI ending in ".html" and with content-type
"text/html" even, but with some servers, GET from the same URI will
initiate content negotiation and may return that entity, a different
one, a transcoded one, a tidied one, etc., according to server-defined
rules.  (Section 5.4 of WebDAV, RFC 2518 has more to say on this).

Given that PUT has somewhat open-ended semantics - won't ADDMEMBER
have similarly open-ended semantics?

How is an ADDMEMBER whose effect is as open-ended as PUT, but which
creates a resource at a server-selected URI, any different from POST -
even for access control?

It seems to me that if you're considering making access control
decisions on the difference between ADDMEMBER and POST, then you
should really be making those decisions on the known behaviour of the
request URI.  If you don't recognise the request URI, then you don't
really know what ADDMEMMER _or_ POST will do, in general.

-- Jamie

Received on Thursday, 17 February 2005 18:36:34 UTC