W3C home > Mailing lists > Public > public-html-comments@w3.org > March 2011

Re: PUT and DELETE methods in form@method

From: Cameron Heavon-Jones <cmhjones@gmail.com>
Date: Wed, 30 Mar 2011 15:58:43 +0100
Cc: "T.J. Crowder" <tj@crowdersoftware.com>, Dominik Tomaszuk <ddooss@wp.pl>, public-html-comments@w3.org
Message-Id: <17B7FB9E-4FDB-456D-9804-D0870B477A5F@gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>


On 30/03/2011, at 3:25 PM, Julian Reschke wrote:

> On 30.03.2011 16:02, Cameron Heavon-Jones wrote:
>> Existing servers don't do this for PUT or DELETE but then existing servers don't currently support these methods from forms anyway.
> 
> What exactly does it *mean* to support these methods "for forms"?

It is so that a user can interact with a resful service using plain html (no ajax) in the same way that automated agents can. 

This means a user must be able to initiate any method of HTTP request, and the only way of doing that in html is through a form. That forms only support GET and POST just precludes real humans from interacting with restful systems. 

That PUT and DELETE are idempotent doesn't mean that forms can't send them, it just means that the service methods must be designed as such. This is the way that this currently works for automated agents, there is nothing special about a user agent which precludes it from sending these types of requests. A form is just a UI element for allowing a user to interact with the same service which everything else already does. 

For a form to send a DELETE doesn't seem to make much sense, but this is only due to the flexibility of the form element in being able to capture any amount of request data. This data seems at odds with a method like DELETE which appears to be a non-configurable operation. However, it does make sense that for an idempotent operation there almost should be some some additional arguments - maybe even just a hidden version number.

> 
>> Servers don't need special cases for requests from forms, they need special cases based on what content type the agent says it can handle.
> 
> I'm not convinced that the Accept: header would be reliable here, but it could be worth a try.
> 
> Best regards, Julian

I think this must be supported... if an agent wants xml it should get xml, if it wants html it should get html. To just give up and not allow or provide any content is to not support anything.

cam
Received on Wednesday, 30 March 2011 14:59:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 1 June 2011 00:14:06 GMT