- From: Julian Reschke <julian.reschke@gmx.de>
- Date: 2005年2月17日 19:42:56 +0100
- To: Jamie Lokier <jamie@shareable.org>
- CC: "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>
- Message-ID: <4214E5B0.8060302@gmx.de>
Jamie Lokier wrote: > 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. I do, because I'll make the assumption that a server that advertises support for ADDMEMBER indeed implements what the spec says. Are you saying that I can't make that assumption? > 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. Yes. > 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. I'd consider that a bug. > 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). In which case the server shouldn't have supported PUT on that URI in the first place. > Given that PUT has somewhat open-ended semantics - won't ADDMEMBER > have similarly open-ended semantics? I don't agree that it has open-ended semantics. But it's good that you raise this issue, because it's essential to understand the rational for ADDMEMBER. > 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. See above. Best regards, Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Thursday, 17 February 2005 18:43:29 UTC