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

Re: HTTP PUT / 201 / Location

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 21 Jan 2005 23:02:35 +0100
Message-ID: <41F17BFB.60709@gmx.de>
To: Helge Hess <helge.hess@opengroupware.org>
CC: ietf-http-wg@w3.org

Helge Hess wrote:
> 
> Hi,
> 
> we are currently looking at the creation of resources via HTTP as part 
> of the CalDAV effort. Julian Reschke recommended to contact this list 
> for clarification and further discussion of the topic since the issue at 
> hand is not really CalDAV specific.

Right. Also, we've had similar discussions on the Atom mailing list 
(creating a new feed entry), so this use-case seems to be quite common.

> What we discuss is how to solve resource creation with servers that 
> enforce maintenance of the resource URLs, eg legacy RDBMS based servers 
> which create primary keys as part of the resource creation and use 
> primary keys as the identifiers to locate the object in the database.
> 
> Personally I think that this is already well covered by the base HTTP 
> specification which explicitly allows the use of 'location' in 201 
> Created responses.
> 
> The client would perform a PUT on some arbitary URL with the 
> "if-none-match: *" header. If no resource lives on the mentioned URL, 
> the server would allow the request and attempt to create the resource 
> while assigning it a new server based identifier. The server would 
> return a 201 Created response with the location header set to the new, 
> server generated location of the resource.
> 
> Question is, does that conflict with any PUT related requirement?
> 
> I read the spec like this:
> 
> a) 9.6 PUT states:
> ---snip---
> If a new resource is created, the origin server MUST inform the user 
> agent via the 201 (Created) response.
> ---snap---
> 9.6 doesn't say anything else about that, so I assume that 201 is 
> completely valid for PUT, all strings attached. It also says:
> ---snip---
> ... the origin server can create the resource with that URI. ...
> ---snap---
> While I'm not a native speaker, "with that URI" only says that the 
> server "uses" the URI to create the request, not that it will store the 
> new object "at that URI".

Filling in my concerns... :-). It also *introduces* PUT as:

"The PUT method requests that the enclosed entity be stored under the 
supplied Request-URI."

IMHO, a server that doesn't store the entitiy under the supplied 
Request-URI, but returns a 2xx status code nevertheless, isn't compliant 
to this description.

> b) 10.2.2 201 Created:
> ---snip---
> The newly created resource can be referenced by the URI(s) returned in 
> the entity of the response, with the most specific URI for the resource 
> given by a Location header field
> ---snap---
> 
> Note that we do not want to use a redirect 3xx response, we just discuss 
> the usage of the location header in combination with a PUT request and a 
> 201 response. So the mentioned 3xx issues in combination with PUTs do 
> not apply.

Nobody argues with the definition of the "Location" header. The only 
question here is whether is appropriate to use it in a 201 as a result 
of a PUT.

> I would welcome any insight whether the proposed use of PUT is 
> considered valid and whether there is a flaw in my idea of HTTP PUT / 
> 201 / location.

I'd also appreciate feedback about whether this scenario is common 
enough to warrant a new method such as "PUTNEW" which is the same as 
"PUT", but has the parent collection as Request-URI and returns the 
location of the newly created resource in the Location response header.

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Friday, 21 January 2005 22:03:16 GMT

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