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: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 20 Oct 2008 22:30:37 +0200
Message-ID: <48FCEA6D.5010703@gmx.de>
To: Henrik Nordstrom <henrik@henriknordstrom.net>
CC: HTTP Working Group <ietf-http-wg@w3.org>

Henrik Nordstrom wrote:
> On mån, 2008-10-20 at 22:12 +0200, Julian Reschke wrote:
>> Henrik Nordstrom wrote:
>>> Sorry. A bit tired. Didn't notice the change to POST.
>>>
>>> Switching to POST isn't good either.
>>>
>>> I'll second Brians response here.
>> Which part?
> 
> The whole message with 3 alternatives, all three of them.

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

>>> Additionally allowing for PUT to create a new resoure-URI completely
>>> different from the request-URI would make sense, but needs to be
>>> negotiated by a request header indicating that the client accepts this.
>> Well, I proposed a new method for this in 2005, and the answer to that 
>> was: just use POST. And that is what AtomPub has done.
>>
>> So is this suddenly the wrong advice?
> 
> It's a matter of semantics. POST is meant for application transfers, for
> data being processed by the server, with no direct content mapping to
> the created resource (if any). PUT is a request to store an entity
> "as-is".

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.

> However, creating a new method for this is defenitely not the right
> thing. Better to extend PUT to allow this use case by conditionally
> relaxing the target resource URI requirements, or use POST.

I still do not see how this functionality can be implemented without 
breaking the semantics of 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>).

BR, Julian
Received on Monday, 20 October 2008 20:31:24 GMT

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