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

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

From: Cameron Heavon-Jones <cmhjones@gmail.com>
Date: Tue, 13 Dec 2011 12:48:13 +0000
Cc: public-html-comments@w3.org
Message-Id: <06EC3AD4-2884-45E9-AA6C-A7F4DEC01EDA@gmail.com>
To: thibault <thibault@miximum.fr>
On 12/12/2011, at 9:50 AM, thibault wrote:

> Hi Cameron,
> Thank you for your reply.
> As far as I understand, the bug was closed because the editor stated that some interactions between browsers and web servers were not really defined, and that there would be conflicting use cases, in the case of a PUT or a DELETE request.

User Agent behaviour in handling response status codes is not defined in the http specification. The description of the status code does hint to an expected behaviour yet this is a matter of interpretation within the context of a UA target and any inference within a single context, while sensible, is not a mandate and can not be expected universally.

This isn't a problem with http specification or html for that matter, it's just an area which hasn't been specified before. It seems increasingly likely that html may become a harbour for this, however this is a separate issue from the application of form methods since UA processing is the same for GET and POST through forms and through any type of XHR requests. 

If PUT and DELETE have highlighted another issue this is a good thing, but existing UA behaviour in response handling is no refection on the validity of form methods.

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

> Is there a list of conflicting use-cases? What is the state of the draft proposal? Can I help in some way?

A list of use cases and concerns to address is really useful, the work Mike has started contains the most up to date state of a proposal. 

With some further thought, instead of reopening the bug i will just request for it to be raised as a tracker issue as it will require the full attention of the working group. From there proposals are solicited as a means of applying changes to the specification. 

I hope that you and everyone else who has been involved so far will remain engaged in the issue and that this will progress united and with as much community help as can be provided. 

> Regards.
> --
> Thibault Jouannic
> Ingénieur web freelance
> +33 (0) 6 30 47 30 50
> http://thibault.jouannic.fr

Cameron Jones

> On Fri, 9 Dec 2011 15:14:57 +0000
> Cameron Heavon-Jones <cmhjones@gmail.com> wrote:
>> I reopened the bug earlier this year prompted by requests from this mailing list. since we've been working on a draft proposal and also addressing concerns from Julian who initially created the bug. the most recent discussion can be found on public-html[1] which was started by yet another request to revisit.
Received on Tuesday, 13 December 2011 12:48:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:28 UTC