W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2005

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

From: Jamie Lokier <jamie@shareable.org>
Date: Thu, 17 Feb 2005 19:51:13 +0000
To: Julian Reschke <julian.reschke@gmx.de>
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: <20050217195113.GG18275@mail.shareable.org>

Julian Reschke wrote:
> >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?

You can define the spec that way of course.  It might even be a good idea. :)

But then I'd argue it is not the same as "PUT except that the resource
is created as a server-selected URI, using the request URI to indicate
which container".

> >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.

To double check, 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.

> >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.

Maybe it is a bug (but RFC 2616 doesn't have a SHOULD or MUST, it just
says "the PUT method requests...").

But it exists in practice, so it would be foolish for an intermediary
doing access control to blindly _assume_ the behaviour you expect
based on the method name alone.

And if the intermediary has to look at other things like the server
name and URI, then POST is adequately specified for this because you
can simply define POST to a _known_ URI has having that behaviour.

> >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.

Apache 2 does (assuming authorization); it's what I expected, and
it's occasionally even useful.

> >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.

Yes.  It seems you want an ADDMEMBER which is more tightly specified
than just "PUT with server-selected URI".

In which case, maybe what you really want is a more tightly specified
alternative to PUT with an option for server-selected URI.

-- Jamie
Received on Thursday, 17 February 2005 19:51:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:49:39 GMT