W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2005

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 17 Feb 2005 19:42:56 +0100
Message-ID: <4214E5B0.8060302@gmx.de>
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>

Jamie Lokier wrote:
> Julian Reschke wrote:
>>Because in general, I will have no idea what the server will do with the 
> 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.


> 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 

> 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:33 UTC