- From: Jamie Lokier <jamie@shareable.org>
- Date: Thu, 17 Feb 2005 22:49:39 +0000
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: algermissen@acm.org, "Roy T. Fielding" <fielding@gbiv.com>, Mark Baker <distobj@acm.org>, HTTP Working Group <ietf-http-wg@w3.org>, CalDAV DevList <ietf-caldav@osafoundation.org>, WebDAV <w3c-dist-auth@w3.org>
Julian Reschke wrote: > OK, to summarize: your point is that PUT doesn't have the strict > semantics (that I claim it has). Let's just agree that we disagree here. Actually I'm saying it isn't implemented with strict semantics in practice. I hope we don't disagree about that ;) Which means there is no point pretending it does have strict semantics for the purpose of access control to an unknown server. > > >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? > > Did I? Ah. It wasn't you who mentioned intermediaries needing to know what the method will do. In response to: >> Why can't you POST to the container resource? >> That's what POST is for, after all. You said this: > Because in general, I will have no idea what the server will do with the > POST. which I took to mean you wanted to be sure of what would happen, perhaps with a view to a security policy or intermediary behaviour. My mistake. So I'll humbly rephrase my question: Even if you do specify ADDMEMBER more tightly (than POST), I still don't see how the difference would benefit you. You say it is useful to have an idea what the server will do with a POST, in general. In general means an arbitrary URI with unknown properties, because if it's a URI with known properties, you know exactly what POST will do. How does specifying ADDMEMBER to have tighter semantics than PUT and POST benefit you when sending the request to an arbitrary URI with unknown properties? Can you give an example? Thanks, -- Jamie
Received on Thursday, 17 February 2005 22:49:54 UTC