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

On Mon, 20 Oct 2008, Julian Reschke 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.

When you know that /new.txt will generate new URIs, the correct method to 
trigger is is POST and clearly not PUT.
What's wrong with
POST /give_me_a_new_URI
=> 303 See Other
    Location: /new1.txt
=> PUT /new1.txt
...

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

Well, everytime underlying implementation surface at the URI level, you 
run into that kind of issue, nothing new there.

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

Yep 307 is far better. (I bet that the HTTP stacks are all supporting it 
by now, no ?)

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

+1 (meaning that I should read the entire email before replying :) )

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Tuesday, 21 October 2008 07:47:08 UTC