Subject: HTTP PUT / 201 / Location

From: Helge Hess <[email-masked]>
Date: Fri, 21 Jan 2005 22:39:49 +0100

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

---

From: Julian Reschke <[email-masked]>
Date: Fri, 21 Jan 2005 23:02:35 +0100

Helge Hess wrote:
> 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.

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

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

> considered valid and whether there is a flaw in my idea of HTTP PUT / 

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