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

On 2011-12-13 14:10, Cameron Heavon-Jones wrote:
>
> On 13/12/2011, at 1:04 PM, Julian Reschke wrote:
>
>> On 2011-12-13 13:48, Cameron Heavon-Jones wrote:
>>> ...
>>>> In my mind, this may be true to some extent. For example, let's say I'm browsing my blog backend, opening the latest post page, and sending a successful DELETE request. If the server replies with a 204 (no content) response, what should my browser do? Nothing? Redirect to post-list?
>>>
>>> There is nothing which specifies that a server *must* respond to a DELETE with a 204. Why is 204 deemed to be the correct response? If a server is communicating with a user through a html-browser it should be returning content for the user to see. If the server isn't currently doing that, it doesn't invalidate the request, it just means the server doesn't implement that.
>>> ...
>>
>> 204 is a plausible response because there's really nothing else to say when a client requests a delete, and the served did it.
>>
>> "If a server is communicating with a user through a html-browser it should be returning content for the user to see."
>>
>> How would it know that?
>
> We started discussing this before and it's good to get back to it :)
>
> The standard means of content-negotiation is the Accept header.

Yes, but that's for the format. An Accept header of

   Accept: text/html

doesn't tell the server *what* kind of HTML content you want (a status 
message vs something that could be used as a next page in a user 
interaction).

> I'm in the process of requesting this be raised as a tracker issue(s). Are you suggesting that escalating is premature before a final proposal is written?

I personally think that without a complete proposal that has some chance 
of getting browser adoption this has zero chance to get through, given 
the fact that we are ~half a year into Last Call.

> ...

Best regards, Julian

Received on Tuesday, 13 December 2011 13:31:18 UTC