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

Re: Follow-up about PUT and DELETE in form methods

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 13 Dec 2011 18:31:51 +0100
Message-ID: <4EE78C07.9030708@gmx.de>
To: Cameron Heavon-Jones <cmhjones@gmail.com>
CC: thibault <thibault@miximum.fr>, public-html-comments@w3.org
On 2011-12-13 18:21, Cameron Heavon-Jones wrote:
>
> On 13/12/2011, at 5:01 PM, Julian Reschke wrote:
>
>> On 2011-12-13 17:54, Cameron Heavon-Jones wrote:
>>>
>>> On 13/12/2011, at 4:29 PM, Julian Reschke wrote:
>>>
>>>> On 2011-12-13 17:09, Cameron Heavon-Jones wrote:
>>>>> ...
>>>>> Let's leave WebDAV alone. What is the use case we're discussing then if not how WebDAV servers return a status message for WebDAV client and full html representation for browsers over the same "Accept" header?
>>>>> ...
>>>>
>>>> For instance, a UI that allows deleting resource both through a script-less form (where you need a new HTML page to be displayed as result), and a script-driven XHR based UI (where you only want to know success/fail). Note that in both cases the same user agent makes the request, but it has different requirements on the response type.
>>>
>>> This is exactly where "Accept" should be used. Either the script should advertise it wants "text\plain" status message or maybe an "application\json" response.
>>
>> The media type of the response isn't relevant here. "Accept" is the wrong header to negotiate on. Sorry.
>>
>
> What are the "different requirements on response type" if not the media type of the response?

The media type of the response is orthogonal to what *kind* of response 
you want.

For a successful DELETE, all of the following a plausible:

- no response at all (204)

- a short status message ("deleted x and all depending resources")

- a representation of the collection the resource was removed from

- ...

None of these have anything to do with the *media type*.


> No, sorry. With all due respect, I am in complete disagreement with you here. Perhaps others can try different tacks to convince either one of us but this is where we left it last time and looks to be just one of our unresolvable understandings.

Indeed.

 > ...
>> What needs to be negotiated is *what* is represented (a status message as opposed to current state as opposed to...), not the format.
>
> I disagree with negotiating *what* is represented within a single format and that this is of relevance to form specification.
>
> If the Preference token is not enough can you please state what additional problem must be addressed?

Oh, a Prefer token would be enough, we just need to specify it, and make 
sure that forms either send it automatically, or the author of the form 
can specify it.

Best regards, Julian
Received on Tuesday, 13 December 2011 17:32:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 13 December 2011 17:32:33 GMT