PUT and DELETE methods in form@method

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

PUT and DELETE methods in form@method

Dominik Tomaszuk
Hi all,

I wonder why the HTML(5) forms are not supported HTTP methods PUT and
DELETE?
Why to submit PUT or DELETE I must use JavaScript and XMLHttpRequest?

Regards,

Dominik Tomaszuk


Reply | Threaded
Open this post in threaded view
|

Re: PUT and DELETE methods in form@method

Mounir Lamouri
On 03/29/2011 09:57 PM, Dominik Tomaszuk wrote:
> Hi all,
>
> I wonder why the HTML(5) forms are not supported HTTP methods PUT and
> DELETE?
> Why to submit PUT or DELETE I must use JavaScript and XMLHttpRequest?

They were available and have been removed. They were even available in a
Firefox 4 beta (but removed before the final).
You can found here the reasons of the removal:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10671

--
Mounir

Reply | Threaded
Open this post in threaded view
|

Re: PUT and DELETE methods in form@method

Dominik Tomaszuk
On 30.03.2011 00:02, Mounir Lamouri wrote:
> They were available and have been removed. They were even available in a
> Firefox 4 beta (but removed before the final).
I know that. The reason I ask, why it was removed? Why to do something
RESTful I must do enormous tricks such as XMLHttpRequest and JavaScript?
Or why I must use POST to tunnel PUT and DELETE? HTML uses HTTP. PUT and
DELETE is normal methods in HTTP, it is not super-new specials methods.
PUT is very similar to POST. For instance, to create a new entry I use
POST, to replace/update I would like to use PUT. Why I cannot write:
<form method="put" action="...">
</form>
Why must I do it like this:
<form method="post" action="...">
<input type="hidden" name="_method" value="PUT" id="_method">
</form>
Or, why I can write like this:
var client = new XMLHttpRequest();
client.open("PUT", url);
And this:
var client = new XMLHttpRequest();
client.open("POST", url);
But I can't to the same in HTML forms, why?

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

Regards,
Dominik


Reply | Threaded
Open this post in threaded view
|

Re: PUT and DELETE methods in form@method

Mounir Lamouri
On 03/30/2011 02:04 PM, Dominik Tomaszuk 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).

If you disagree with the removal (and the given reasons) you should
reopen the bug and explain why you think these methods should be added back.
You could also send a message to the WHATWG mailing list.

--
Mounir

Reply | Threaded
Open this post in threaded view
|

Re: PUT and DELETE methods in form@method

Julian Reschke
On 30.03.2011 14:33, Mounir Lamouri wrote:

> On 03/30/2011 02:04 PM, Dominik Tomaszuk 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).
>
> If you disagree with the removal (and the given reasons) you should
> reopen the bug and explain why you think these methods should be added back.
> You could also send a message to the WHATWG mailing list.

The reason why I suggested removal was that I found problems in the FF4
beta, and that I felt it was underspecified in HTML5, and shipping it in
FF4 would hurt things in the future.

That being said: let's get it specified properly and then move on.

Best regards, Julian



Reply | Threaded
Open this post in threaded view
|

Re: PUT and DELETE methods in form@method

T.J. Crowder
In reply to this post by Mounir Lamouri
Hi,

On 30 March 2011 13:04, Dominik Tomaszuk <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: PUT and DELETE methods in form@method

Dominik Tomaszuk
On 30.03.2011 14:47, T.J. Crowder wrote:
> But are those RESTful implementations using PUT and DELETE *with HTML
> forms*?
It depends. There aren't any implementations using method="put" because
there aren't any web browser that support it. But of course there are a
lot of frameworks that could support this case, e.g. Limonade [1] or
Sinatra [2].

> 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.
It could be supported in the same way as POST: 200 OK (describing or
containing the result of the action). HTTP in PUT and DELETE allowed 200
if an existing resource is modified in PUT or if it is a successful
response (and it is consistent with the approach RESTful).

Regards,
Dominik


Reply | Threaded
Open this post in threaded view
|

Re: PUT and DELETE methods in form@method

cameronjones
In reply to this post by T.J. Crowder
why can't a 201 just include some body content like a 200? This would allow for any response status to include html content for rendering the response to the user. The response content may not be available through any other uri of method but it seems like thats the way it should work.

cam

On 30/03/2011, at 1:47 PM, T.J. Crowder wrote:

Hi,

On 30 March 2011 13:04, Dominik Tomaszuk <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: PUT and DELETE methods in form@method

Simpson, Grant Leyton
In reply to this post by Dominik Tomaszuk
Right, but this does still does not cover specifying how the user agent
should respond to a HTTP 200 and how that response integrates with a given
application.

On 3/30/11 9:10 AM, "Dominik Tomaszuk" <[hidden email]> wrote:

>It could be supported in the same way as POST: 200 OK (describing or
>containing the result of the action). HTTP in PUT and DELETE allowed 200
>if an existing resource is modified in PUT or if it is a successful
>response (and it is consistent with the approach RESTful).


Reply | Threaded
Open this post in threaded view
|

Re: PUT and DELETE methods in form@method

Julian Reschke
In reply to this post by cameronjones
On 30.03.2011 15:20, Cameron Heavon-Jones wrote:
> why can't a 201 just include some body content like a 200? This would
> allow for any response status to include html content for rendering the
> response to the user. The response content may not be available through
> any other uri of method but it seems like thats the way it should work.
>
> cam

Well,

existing servers do not do this for PUT and DELETE, as existing clients
do only care about the status.

So servers would need to special-case requests from HTML forms; not good.

BR, Julian

Reply | Threaded
Open this post in threaded view
|

Re: PUT and DELETE methods in form@method

cameronjones
In reply to this post by Simpson, Grant Leyton
A user agent should always respond by rendering whatever content is returned by the server as specified by the Accept header. This defines what response the agent can handle and what the user wants to see.

The response status is a machine code for automated agents, not user agents. To expect a user agent (browser) to handle arbitrary response states for a user removes the user from making their decisions based on the information sent back from the server.

In the case of an automated agent, ie a business process, the response status is usually enough information with which to decide what action to take. Users require a formatted response in order to inform their decision making process.

As a scenario, if a user submits a form for processing and the form contains server-vailidation errors, how else is this to be communicated to the user other than by providing back a html response with the original form, values and errors? It would seem that a unique request dictates the need for a unique response.

Even for automated agents, the need for a customised response as a result of a failed request is desired as it is the only means of informing the agent of the specific nature of the error. Http status codes are too corse grained for anything other than highest-level automation.

cam


On 30/03/2011, at 2:29 PM, Simpson, Grant Leyton wrote:

> Right, but this does still does not cover specifying how the user agent
> should respond to a HTTP 200 and how that response integrates with a given
> application.
>
> On 3/30/11 9:10 AM, "Dominik Tomaszuk" <[hidden email]> wrote:
>
>> It could be supported in the same way as POST: 200 OK (describing or
>> containing the result of the action). HTTP in PUT and DELETE allowed 200
>> if an existing resource is modified in PUT or if it is a successful
>> response (and it is consistent with the approach RESTful).
>
>


Reply | Threaded
Open this post in threaded view
|

Re: PUT and DELETE methods in form@method

cameronjones
In reply to this post by Julian Reschke
Existing servers don't do this for PUT or DELETE but then existing servers don't currently support these methods from forms anyway.

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.

cam


On 30/03/2011, at 2:39 PM, Julian Reschke wrote:

> On 30.03.2011 15:20, Cameron Heavon-Jones wrote:
>> why can't a 201 just include some body content like a 200? This would
>> allow for any response status to include html content for rendering the
>> response to the user. The response content may not be available through
>> any other uri of method but it seems like thats the way it should work.
>>
>> cam
>
> Well,
>
> existing servers do not do this for PUT and DELETE, as existing clients do only care about the status.
>
> So servers would need to special-case requests from HTML forms; not good.
>
> BR, Julian


Reply | Threaded
Open this post in threaded view
|

Re: PUT and DELETE methods in form@method

Simpson, Grant Leyton
In reply to this post by cameronjones


On 3/30/11 10:02 AM, "Cameron Heavon-Jones" <[hidden email]> wrote:

>A user agent should always respond by rendering whatever content is
>returned by the server as specified by the Accept header. This defines
>what response the agent can handle and what the user wants to see.
>
>The response status is a machine code for automated agents, not user
>agents. To expect a user agent (browser) to handle arbitrary response
>states for a user removes the user from making their decisions based on
>the information sent back from the server.

Right. I agree and I'm not advocating that this would be the way to do it.
I was trying to point out that even were it to be done that way, that
still doesn't specify behavior at the level of the user agent's handling
the HTML form.

>
>
>In the case of an automated agent, ie a business process, the response
>status is usually enough information with which to decide what action to
>take. Users require a formatted response in order to inform their
>decision making process.

Agreed.

>
>As a scenario, if a user submits a form for processing and the form
>contains server-vailidation errors, how else is this to be communicated
>to the user other than by providing back a html response with the
>original form, values and errors? It would seem that a unique request
>dictates the need for a unique response.
>
>Even for automated agents, the need for a customised response as a result
>of a failed request is desired as it is the only means of informing the
>agent of the specific nature of the error. Http status codes are too
>corse grained for anything other than highest-level automation.

Absolutely. And that's why I don't think it's a good idea. (But I did a
poor job before of expressing that.)

>
>cam
>
>
>On 30/03/2011, at 2:29 PM, Simpson, Grant Leyton wrote:
>
>> Right, but this does still does not cover specifying how the user agent
>> should respond to a HTTP 200 and how that response integrates with a
>>given
>> application.
>>
>> On 3/30/11 9:10 AM, "Dominik Tomaszuk" <[hidden email]> wrote:
>>
>>> It could be supported in the same way as POST: 200 OK (describing or
>>> containing the result of the action). HTTP in PUT and DELETE allowed
>>>200
>>> if an existing resource is modified in PUT or if it is a successful
>>> response (and it is consistent with the approach RESTful).
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: PUT and DELETE methods in form@method

Julian Reschke
In reply to this post by cameronjones
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"?

> 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

Reply | Threaded
Open this post in threaded view
|

Re: PUT and DELETE methods in form@method

cameronjones


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
Reply | Threaded
Open this post in threaded view
|

Re: PUT and DELETE methods in form@method

cameronjones
In reply to this post by Simpson, Grant Leyton
I'm struggling to see what the problem with forms using other HTTP methods is....

On 30/03/2011, at 3:13 PM, Simpson, Grant Leyton wrote:

>
>
> On 3/30/11 10:02 AM, "Cameron Heavon-Jones" <[hidden email]> wrote:
>
>> A user agent should always respond by rendering whatever content is
>> returned by the server as specified by the Accept header. This defines
>> what response the agent can handle and what the user wants to see.
>>
>> The response status is a machine code for automated agents, not user
>> agents. To expect a user agent (browser) to handle arbitrary response
>> states for a user removes the user from making their decisions based on
>> the information sent back from the server.
>
> Right. I agree and I'm not advocating that this would be the way to do it.
> I was trying to point out that even were it to be done that way, that
> still doesn't specify behavior at the level of the user agent's handling
> the HTML form.
>
>>
>>
>> In the case of an automated agent, ie a business process, the response
>> status is usually enough information with which to decide what action to
>> take. Users require a formatted response in order to inform their
>> decision making process.
>
> Agreed.
>
>>
>> As a scenario, if a user submits a form for processing and the form
>> contains server-vailidation errors, how else is this to be communicated
>> to the user other than by providing back a html response with the
>> original form, values and errors? It would seem that a unique request
>> dictates the need for a unique response.
>>
>> Even for automated agents, the need for a customised response as a result
>> of a failed request is desired as it is the only means of informing the
>> agent of the specific nature of the error. Http status codes are too
>> corse grained for anything other than highest-level automation.
>
> Absolutely. And that's why I don't think it's a good idea. (But I did a
> poor job before of expressing that.)
>
>>
>> cam
>>
>>
>> On 30/03/2011, at 2:29 PM, Simpson, Grant Leyton wrote:
>>
>>> Right, but this does still does not cover specifying how the user agent
>>> should respond to a HTTP 200 and how that response integrates with a
>>> given
>>> application.
>>>
>>> On 3/30/11 9:10 AM, "Dominik Tomaszuk" <[hidden email]> wrote:
>>>
>>>> It could be supported in the same way as POST: 200 OK (describing or
>>>> containing the result of the action). HTTP in PUT and DELETE allowed
>>>> 200
>>>> if an existing resource is modified in PUT or if it is a successful
>>>> response (and it is consistent with the approach RESTful).
>>>
>>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: PUT and DELETE methods in form@method

Julian Reschke
In reply to this post by cameronjones
On 30.03.2011 16:58, Cameron Heavon-Jones wrote:

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

So for PUT, where do you want the form fields to go? URI? request body?

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

Re: PUT and DELETE methods in form@method

cameronjones
in the request body, encoded as specified by the enctype attribute.

this can be differentiated on the server as is already done for POST by dispatching based on content type, automated agents can upload xml, json, etc and user agents can upload form-data or x-www-form-urlencoded.

cam

On 30/03/2011, at 4:06 PM, Julian Reschke wrote:

> On 30.03.2011 16:58, Cameron Heavon-Jones wrote:
>>
>>
>> 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.
>> ...
>
> So for PUT, where do you want the form fields to go? URI? request body?
>
> Best regards, Julian


Reply | Threaded
Open this post in threaded view
|

Re: PUT and DELETE methods in form@method

cameronjones
if no further debate on public-html-comments, what is the current procedure for reviewing this issue in the specification?

thanks,
cam


On 30/03/2011, at 4:15 PM, Cameron Heavon-Jones wrote:

> in the request body, encoded as specified by the enctype attribute.
>
> this can be differentiated on the server as is already done for POST by dispatching based on content type, automated agents can upload xml, json, etc and user agents can upload form-data or x-www-form-urlencoded.
>
> cam
>
> On 30/03/2011, at 4:06 PM, Julian Reschke wrote:
>
>> On 30.03.2011 16:58, Cameron Heavon-Jones wrote:
>>>
>>>
>>> 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.
>>> ...
>>
>> So for PUT, where do you want the form fields to go? URI? request body?
>>
>> Best regards, Julian
>


Reply | Threaded
Open this post in threaded view
|

Re: PUT and DELETE methods in form@method

Mounir Lamouri
On 03/31/2011 03:23 PM, Cameron Heavon-Jones wrote:
> if no further debate on public-html-comments, what is the current procedure for reviewing this issue in the specification?

Reopen the bug and/or send a comment to the WHATWG list.

--
Mounir

12