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: Fri, 24 Oct 2008 21:22:22 +0200
To: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <1224876142.3231.153.camel@henriknordstrom.net>
Have given this some more thought over the last days, and I now stay
completely by the side that "unnamed" PUT is a completely bad idea and
that POST should be used in those situations if really really needed,
even if it means applications need to learn the actual POST protocol
used.

As Brian correctly points out in most cases applications needing servers
to assign resource names at PUT time is a information management design
error. The name should be assigned prior to the PUT, or you'll lose
idempotence and other aspects which is generally important for this kind
of operation.

Yes, it means one round-trip more to the server in applications needing
such naming assignments if they really want to use PUT for creting the
resource (instead of POST, but that's not the end of the world.

Playing games with redirects et al is nice, but does not solve the
problem in a good manner. Neither is adding a new method for the task.

So the recommendation to anyone needing this is

1. Rethink what you are doing. Are you really really sure it's a good
idea?

2. If you absolutely must operate in this manner use POST for creating
the resource. There is no standard POST application protocol for
creating server named resources so invent your own ontop of POST. This
could be as simple as having the complete payload just as PUT, or a more
elaborate protocol with added meta data such as the forms POST protocol
or something similar, it's up to the application.

Regards
Henrik

Received on Friday, 24 October 2008 19:22:59 GMT

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