Re: server applying PUT to a resource other than the request-URI

Helge Hess wrote:
> 
> On 20.10.2008, at 20:39, Julian Reschke wrote:
>>> I think this is better, according to what you quoted above:
>>> S: HTTP/1.1 301 Moved Permanently
>>> S: Location: /folder/bar
>>> S:
>>> S: Do it there
>>> C: PUT /folder/bar
>>> C: ...
>> Of course that's not going to work in practice, as Cyrus pointed out.
> 
> Thats exaggerated. Lets see where the requirement comes from. Its 

OK, it's not *always* going to work.

> originated in servers which use an RDBMS as the storage. Such servers do 
> not want to maintain an additional namespace for DAV but just want to 
> use the records primary key as the relative resource name.
> 
> Example: PUT /new.txt => Location: 1.txt, PUT /new.txt => Location: 
> 2.txt, etc.

Yes. Doesn't need to be an RDBMS, but the use case is similar.

> Most applications use SQL sequences to create the primary keys, since 
> you usually need the key anyways to fill up foreign keys in related 
> records. In such a scenario the 301 works OK. The server can preallocate 
> a key from the sequence and then tell the client to use that.

That may work sometimes, but not always. For instance, when the API of 
the underlying store simply doesn't allow you that "preallocate" step.

> Its a bit more difficult with 'SERIAL' keys, primary keys which are 
> allocated by the RDBMS only during the INSERT of the actual record. In 
> this case you indeed need to insert before you get the primary key.
> BUT lets get real:
> a) its not hard to change the SERIAL code to use a real sequence,
>    server compat is hardly affected by such a switch
> b) most RDBMS implement SERIAL with a sequence anyways
> 
> Summary: IMHO the 301+location solution is not great, but OK. Primary 
> disadvantage is the additional roundtrip, but thats acceptable, 
> especially in combination with 100-continue.

301 is IMHO terrible wrong as it indicates a permanent redirect.

The other big question is: what is the request-URI? How do you discover 
server support for this?

>>> If anything, more applications should be switching from POST to PUT.
>> Well, do you have a proposal that uses PUT as allowed by the RFC2616, 
>> and works for the above use case?
> 
> Lets modify RFC2616 to explicitly state that the PUT with 201+Location 
> is allowed. Maybe in a separate RFC, I don't know. Its the obvious thing 
> to do. It works well with existing clients, its already done that way by 
> serveral servers and it fits into the overall design.

It would break existing clients, so I don't see how it could be done in 
HTTP/1.1.

The semantics for PUT are clear from RFC2616: the client picks the URI.

If you don't want that semantics, do not use PUT. One solutions is to 
use POST (as done in AtomPub), another one would be to define a new 
method (as proposed earlier). But changing the semantics of PUT IMHO is 
the wrong choice.

BR, Julian

Received on Monday, 20 October 2008 20:19:17 UTC