Re: HTTP PUT / 201 / Location

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 UTC