Why HTML5 forms support only GET and POST methods?

Question

What are the technical reasons to not have PUT, DELETE, etc.. as possible values of the attribute 'method' in HTML5 forms? Is the rationale to limit to GET and POST available anywhere?

I fail to see the problem in having something like

<form method="DELETE" action="/item/1">
    <button type="submit">delete item 1</button>
</form>

Answer 1

There are some reasons why PUT and DELETE has been removed from Forms, yes you read it right. PUT and DELETE methods were included in first but they removed it because of some concerns

Here is one point from Julian Reschke;

It seems that we currently do not understand how PUT and DELETE will be useful for HTML forms.

For DELETE, it's indeed easy to create a useful request. However, server implementations usually respond with 200 and a minimal response body ("deleted") or 204 (no content). So it's not clear how this can be used in a web application.

For PUT, it seems there's no real use case as long as the web page doesn't have full control over the payload, and also can set the content type.

Please consider removing this feature until there's a clearer understanding about what it's good for.

And another point from Mike Amundsen;

Executing PUT and DELETE to modify resources on the origin server is straight-forward for modern Web browsers using the XmlHttpRequest object. For unscripted browser interactions this not so simple. Typically, devs and frameworks end up creating work-arounds that mimic the HTTP PUT/DELETE + Etag interaction using a "POST FORM" coupled with specialized server-side code to sort out the special case and act as if the proper HTTP Method was used in the request:

...

This pattern is required so often that several commonly-used Web frameworks/libraries[1][2][3][4] have created a "built-in" work-around. Note that some libraries include support for a concurrency value and some do not.

Other considerations:

• Using POST as a tunnel instead of using PUT/DELETE can lead to caching mis-matches (e.g. POST responses are cachable[5], PUT responses are not[6], DELETE responses are not[7])
• Using a non-idempotent method (POST) to perform an idempotent operation (PUT/DELETE) complicates recovery due to network failures (e.g. "Is is safe to repeat this action?").
• Tunneling leads to reduced "visibility" of the application protocol over the wire which complicates request auditing, authorization-level security, etc.
• Adding support for PUT/DELETE (along w/ inclusion of the If-Match/If-Unmodified-Since headers) can reduce ocurrences of the "Lost Update" concurrency problem.

You can continue to read it via: https://www.w3.org/Bugs/Public/show_bug.cgi?id=10671