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

Re: PUT and DELETE methods in form@method

From: T.J. Crowder <tj@crowdersoftware.com>
Date: Wed, 30 Mar 2011 13:47:25 +0100
Message-ID: <AANLkTikFwsWLM4zx8HjViDOt3fSKjeVQGPAD0rNcbXjY@mail.gmail.com>
To: Dominik Tomaszuk <ddooss@wp.pl>
Cc: public-html-comments@w3.org
Hi,

On 30 March 2011 13:04, Dominik Tomaszuk <ddooss@wp.pl> wrote:

> On 30.03.2011 00:02, Mounir Lamouri wrote:
>
>> You can found here the reasons of the removal:
>
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=10671
>>
> Well, I've seen it. But I do not find there any real reason to removal PUT
> and DELETE (and HEAD?) from spec. The reason that PUT and DELETE have no
> real use case for me is not true, because there are millions of RESTful
> impelemntations that use PUT and DELETE (of course, use of strange solutions
> because browsers do not support them).
>

But are those RESTful implementations using PUT and DELETE *with HTML
forms*? That's the crux of the matter as far as I can tell in the bug
report. With a non-ajax HTML form, the form submission results in the
response page being shown in the browser. Servers reply to these HTTP
methods with little or no response body showing the end user what happened
(as the status -- 201, etc. -- is sufficient). That leaves the question of
what the browser should show the user and whether that should be mandated by
the HTML specification. (Clearly what the *server* replies with is out of
scope for HTML; it's in the  HTTP domain.) The form is either being
submitted with no target, which would mean the user is left with a blank
page or the single word "successful" or something; or it's submitted with a
target, and that target window will be blank or have the single word
"successful" or something.

In contrast, when you use PUT or DELETE with XHR, your code is interpreting
the result, perhaps removing an item from a displayed list, etc.

In other words, the actions make plenty of good sense for HTTP, but what
should they mean in an HTML forms context?

It may well be that there's a good thing that they can and should mean, that
browsers should do. If you have a suggestion in mind, lay it out in detail
for the group and I expect they'll consider it.

FWIW,
--
T.J. Crowder
Independent Software Engineer
tj / crowder software / com
www / crowder software / com
Received on Wednesday, 30 March 2011 12:48:19 GMT

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