W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2008

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

From: Helge Hess <helge.hess@opengroupware.org>
Date: Mon, 20 Oct 2008 22:08:00 +0200
Message-Id: <17E8AE7C-C37B-49A1-B029-43BCFB02D495@opengroupware.org>
To: HTTP Working Group <ietf-http-wg@w3.org>

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

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.

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.

>>>
>> It is a bad idea to switch to POST just for this. There is already a
>> standard way of making PUT idempotent but there is no standard way  
>> of making
>> POST idempotent, and you can easily recover from a broken  
>> connection with
>> PUT (just HEAD the same URI; if you get the old validators, issue  
>> another
>> Conditional PUT). However, there's no standard way to recover from  
>> a failed
>> connection during POST.
>> 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.

Thanks,
   Helge
-- 
Helge Hess
http://helgehess.eu/
Received on Monday, 20 October 2008 20:08:42 GMT

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