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: Tue, 21 Oct 2008 10:58:52 +0200
Message-ID: <48FD99CC.4030505@gmx.de>
To: Helge Hess <helge.hess@opengroupware.org>
CC: HTTP Working Group <ietf-http-wg@w3.org>

Helge Hess wrote:
> You don't know that the specific new.txt will generate new URIs, it was 
> just an example. Of course you need to do the same If-None-Match: * 
> iterations as usual.
> And yes, of course new.txt is a very bad choice, high potential for 
> conflict. Most CalDAV/CardDAV client would start with the UID of the 
> item and then proceed.
> Again: why is POST a bad choice? Because a client using POST wouldn't be 
> able to create items in a regular WebDAV server. The suggestion has very 
> bad downgrade behaviour. IMHO it has very little chance for adoption.

A client can discover via OPTIONS, status codes, and the Allow response 
header whether they can use PUT-for-create.

There is no compatibility problem for servers that want to support both.

The only reason not to support PUT-for-create is when the server needs 
select the final URI. We're discussing only that use case.

> But anyways, I don't think this thread will lead anywhere, as usual ..., 
> I'll quit :-)
> Well, actually it gave (me) one new insight, so it apparently _was_ 
> worth the annual PUT-redirect posting :-)
> A 307+Location is apparently accepted by everyone (?) as a method for 
> producing server generated URLs in a HTTP compliant way. (might be a 
> little harder for the server and client, but its a starting point).

307 is better than 301, but:

"If the 307 status code is received in response to a request other than 
GET or HEAD, the user agent MUST NOT automatically redirect the request 
unless it can be confirmed by the user, since this might change the 
conditions under which the request was issued."

BR, Julian
Received on Tuesday, 21 October 2008 08:59:36 UTC

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