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

HTTP PUT / 201 / Location

From: Helge Hess <helge.hess@opengroupware.org>
Date: Fri, 21 Jan 2005 22:39:49 +0100
Message-Id: <F9CA494B-6BF4-11D9-A47C-000D93C1A604@opengroupware.org>
To: ietf-http-wg@w3.org

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.

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

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.


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.

Thanks a lot,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org
Received on Friday, 21 January 2005 21:40:24 GMT

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