From HTML WG Wiki
Defer complex form feature proposal to HTML.next
Allowing non-GET-or-POST HTTP verbs in
<form method> requires complex, potentially error-prone additions to several parts of the Web platform, and no implementors have expressed plans to implement, despite PUT and DELETE having been in the spec for years. Given where we are in the HTML5 process, we should defer such a feature addition to HTML.next.
This is for ISSUE-195 (form-http-req).
Lack of provided use cases
The Enhance HTTP request generation from forms Change Proposal does not give use cases for each HTTP verb it proposes to allow in
formmethod="". In particular, it is unclear why a UA would want to expose the CONNECT method to Web content.
The proposal says that we should "extend [
<form>'s] supported HTTP methods to include the entire range of non-client-hazardous methods from HTTP/1.1," and in justification appeals to the abstract design architecture of the World Wide Web. Improving the design purity of
<form> is appealing, but theoretical purity is at the bottom of our Priority of Constituencies.
Complexity of change
The Enhance HTTP request generation from forms Change Proposal describes a complex set of features to be added to HTML forms. It's hard to get these details right; Gecko had an implementation of PUT and DELETE for
<form> that was pulled just before the release of Firefox 4 due to this. Given the complexity, lack of clear use cases, and that Web authors can already use these HTTP verbs with XHR, the costs of adding such a complex feature outweigh the benefits at this time.
Lack of UA implementor interest
A solicitation of UA implementor interest from the Editor has gone unanswered for a month. Moreover, the spec allowed PUT and DELETE in
<form method> for years. They were dropped after the failed Gecko implementation mentioned above.
- We avoid adding a complex feature this late in the game.
- Web authors will continue to have to use XHR to use the other HTTP verbs.
Conformance Classes Changes