Why are there are no PUT and DELETE methods on HTML forms?

  • HTML4 / XHTML1 allows only GET and POST in forms, now it seems like HTML5 will do the same. There is a proposal to add these two but it doesn't seem to be gaining traction. What were the technical or political reasons for not including PUT and DELETE in HTML5 specification draft?

    HTML is the markup language, HTTP is the protocol

    @ratchet freak: I am aware of that. Nevertheless I'm asking specifically about HTML as it defines only GET and POST as allowed `

    ` methods.

    A typical scenario is a form with tabular data, where user need to PUT more lines or not, as "more lines" are user decision. Using Javascript+POST is artificial, perhaps HTML6 will show an alternative FORM feature to do this kind of operation.

    I answered this question when someone else asked it on Stack Overflow, and feel my contribution there has something to add to the excellent responses above, for anyone reading this far down the page :o) Why don't browsers support PUT and DELETE requests and when will they?

  • This is a fascinating question. The other answers here are all speculative, and in some cases flat-out incorrect. Instead of writing my opinion here, I actually did some research and found original sources that discuss why delete and put are not part of the HTML5 form standard.

    As it turns out, these methods were included in several, early HTML5 drafts (!), but were later removed in the subsequent drafts. Mozilla had actually implemented this in a Firefox beta, too.

    What was the rationale for removing these methods from the draft? The W3C discussed this topic in bug report 10671. Mike Amundsen argued in favor of this support:

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

    This pattern is required so often that several commonly-used Web frameworks/libraries have created a "built-in" work-around. [...]

    Other considerations:

    • Using POST as a tunnel instead of using PUT/DELETE can lead to caching mis-matches (e.g. POST responses are cachable, 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?").
    • [...]

    It's worth reading his entire post.

    Tom Wardrop also makes an interesting point:

    HTML is inextricably bound to HTTP. HTML is the human interface of HTTP. It's therefore automatically questionable why HTML does not support all relevant methods in the HTTP specification. Why can machines PUT and DELETE resources, but humans cannot? [...]

    It's contradictory that while HTML goes to great lengths to ensure semantic markup, it has to date made no such effort to ensure semantic HTTP requests.

    The bug was eventually closed as Won't Fix by Ian Hickson, with the following rationale:

    PUT as a form method makes no sense, you wouldn't want to PUT a form payload. DELETE only makes sense if there is no payload, so it doesn't make much sense with forms either.

    However, that's not the end of the story! The issue was closed in the W3C bug tracker and escalated to the HTML Working Group issue tracker:

    https://www.w3.org/html/wg/tracker/issues/195

    At this point, it seems that the main reason why there is no support for these methods is simply that nobody has taken the time to write a comprehensive specification for it.

    +1 for putting the research effort in place and digging up a number of external references to properly answer the question.

    @mehaase, How it is different than making ajax put/delete request?

    @shivakumar I think what you're really asking is why bother with HTML when JavaScript can already do the job? That's a fair question. I guess the OP's question comes more from a place of curiosity than of practicality. HTML and HTTP are two standards made for each other, and yet HTML seems to be unaware of some of HTTPs most basic properties. "Why?" is a natural question to ask.

    Surely you have to include a payload for PUT and for DELETE it is possible? Also if "doesn't make much sense with forms" then why are people asking for it and why does a lot if software he workarounds built in. Odd how one person can just decide what the rest of world needs or wants...

    So it seems the bug is closed now, with the following rationale: http://lists.w3.org/Archives/Public/public-html/2013Feb/0227.html The editor's draft is here: http://cameronjones.github.io/form-http-extensions/index.html That seems to be the end of the trail though. Can someone else find a place we can look to monitor this specification's track to becoming a standard?

    @Ajedi32 I e-mailed Cameron Jones (the editor of the current draft) and asked him about the status. He wrote, "the spec is still alive and progressing through the W3C process - it's currently in working draft and the next stage is to hopefully move it into Candidate Recommendation (CR)." He also wrote, "The main factor in this is community interest… If you and others have interest in seeing this implemented i would definitely recommend advocating for such through public-html-comments, the whatwg or the vendors own mailing lists."

    @mehaase Awesome! Do you have a link to the Working Draft? Or is that the same as the "editor's draft" I linked (which seems to be hosted on Cameron's personal GitHub account)?

    @mehaase Also, maybe it's just me, but I think mailing lists are a much better place for discussion than for expressing general support of a proposal. I'm not inclined to start a new thread on the public-html-comments mailing list just so I can say "I like this proposal; forms should be able to use other HTTP methods". As someone who grew up on the modern web, what I want to know is: "where's the upvote button?" ;-)

    It's the same thing you already linked to. I think Cameron is going to send out an e-mail asking for vendor interest and community interest. When that happens, he would appreciate if those of us who care would chime in.

    @Ajedi32 here's the post: https://lists.w3.org/Archives/Public/public-html/2015Feb/0000.html I encourage everybody who's interested to reply to this post on the public-html mailing list.

    @mehaase That particular post seems to be asking for feedback from browser vendors, not web devs. Do you still think I (and other interested developers) should chime in there?

    @Ajedi32 Nominally it is a request for vendors to express their interest level, but _anybody_ interested in the standard should voice their support. The more community support, the more likely vendors are to take notice.

    So, it looks like discussion on the mailing list died off around February of last year, with no vendors chiming in. Obviously, Firefox has shown willingness to implement something like this in the past. The draft isn't being maintained. Maybe there needs to be some community rallying around this to breath some life into it?

    There's an issue open to have this implemented in the issue trackers of the major browsers, so a good place to start would be to vote up those issues and explain the importance of this feature. Here's a post listing the issues for major browsers: https://lists.w3.org/Archives/Public/public-html/2015May/0055.html

    why couldn’t `x-www-form-encoded` be a representation of a resource to PUT?

    Why wouldn't I want to PUT a form payload? I cannot understand.

    I don't agree with `DELETE only makes sense if there is no payload`. People don't make delete forms with GET method. But use POST to include CSRF verification. So, there is payload.

    I agree with @MohammedShareefC there is most definitely a payload with put and delete. With put, which records are you changing, and what information within those records are changing, and what are you changing it to? That would all be communicated via a payload. For delete, unless you're deleteing all records, which records are you deleting?

    I must say this is disappointing. Especially with the file form control, more than any other, put and delete are immediately useful. PUT sending one or more file contents, and delete sending a URI

    I can agree with DELETE not having a data-related payload, but that doesn't make sense to me with PUT (specially given that the _formal_ definition of PUT is a complete payload, contrary to PATCH)

License under CC-BY-SA with attribution


Content dated before 6/26/2020 9:53 AM