W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2008

Re: server applying PUT to a resource other than the request-URI

From: Henrik Nordstrom <henrik@henriknordstrom.net>
Date: Mon, 20 Oct 2008 22:44:15 +0200
To: Julian Reschke <julian.reschke@gmx.de>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <1224535455.13334.8.camel@henriknordstrom.net>
On mån, 2008-10-20 at 22:30 +0200, Julian Reschke wrote:
> Proposal 2 and 3 were specific to the Vcarddav WG in general, not this 
> specific technical issue.
> Proposal 1 IMHO breaks the PUT semantics (that's why I started this thread).

Not if negotiated imho.

> But POST can do that as well. The only missing piece is that the client 
> needs to know that it will. For instance in AtomPub, this is by the 
> definition of the AtomPub collection resource.

POST can do anything any other method can do. It's just a matter of
defining the context.

> I still do not see how this functionality can be implemented without 
> breaking the semantics of PUT.

Maybe. Not so sure. Depends on what one puts into the strict semantics
of a PUT.

> It *can* be implemented using POST, but requires a way for the client to 
> find out that it actually can use POST for it. That can be by contract 
> (AtomPub), by inspection of the error response for PUT, or by some other 
> way of discovery (WebDAV properties, Link header, whatnot). The latter 
> cases are covered by my (currently WebDAV-specific) proposal at 
> <http://greenbytes.de/tech/webdav/draft-reschke-webdav-post-01.html>).

I don't like relying on round-trip discovery and application protocols
for simple storage, especially for use cases like "I want to store this
at this approximate location". And not having support for this family of
requests opens up for a myriad of different POST protocols for
performing this kind of action. There is already too many of those.


Received on Monday, 20 October 2008 20:45:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:47 UTC