39

I'm seeing many frameworks recently that have decided to "fake" PUT and DELETE requests in form submissions (not ajax). Like Ruby on Rails. They seem to be waiting for browsers to catch up. Are they waiting in vain?

Is this even slated to be implemented anywhere?

pixelearth
  • 13,674
  • 10
  • 62
  • 110
  • 1
    Which browser-level actions would require `PUT` and `DELETE` semantics? You can already generate HTTP `PUT` and `DELETE` actions in a programmatic manner. It's just that I can't imagine how one would expose these to a user in a browser (what would it do? `PUT` when you drag a file into your browser?) – Gian May 29 '13 at 05:16
  • They are supported in HTML5 and Ajax requests. – n1xx1 May 29 '13 at 05:17
  • @N1xx1 so in html5 i could do
    ? Sweet. I'll look into this.
    – pixelearth May 29 '13 at 05:30
  • @N1xx1 seems you can't use put/delete in form elements. http://www.w3.org/TR/2010/WD-html5-diff-20101019/#changes-2010-06-24 – pixelearth May 29 '13 at 05:33

1 Answers1

75

Browsers do support PUT and DELETE, but it's HTML that doesn't.

For example, a browser will initiate a PUT request via Javascript (AJAX), but not via HTML <form> submission.

This is because HTML 4.01 and the final W3C HTML 5.0 spec both say that the only HTTP methods that their form elements should allow are GET and POST.

There was much discussion about this during the development of HTML 5, and at one point they got added to HTML 5, only to be removed again. The reason the additional methods were removed from the HTML 5 spec is because HTML 4-level browsers could never support them (not being part of HTML at the time they were made); and there is no way to allow them to do so without a JavaScript shim; thus, you may as well use AJAX.

Web pages trying to use forms with method="PUT" or method="DELETE" would fall back to the default method, GET for all current browsers. This breaks the web applications' attempts to use appropriate methods in HTML forms for the intended action, and ends up giving a worse result — GET being used to delete things! (hello crawler. oh, whoops! there goes my database)

Changing the default method for HTML <form> elements to POST would help (IMO the default should have always been POST, ever since Moasic* debuted forms in 1993), but to change the default would take at least a decade to percolate through the installed base. So in two words: ‘because legacy’. :-(

To support current browsers, authors will have to fake it with an override. I recommend authors use the widely knowna, b _method argument by including <input type=hidden name=_method value=DELETE> in their HTML; switch the form method to POST (since the request is unsafe); then add recognition of _method on the server side, which should then do whatever's necessary to mutate the request and forward it on as if it were a real DELETE request.

Note also that, since web browsers are the ultimate HATEOAS client, they need to have a new state to be transferred to them for DELETE requests. existing APIs often return 204 No Content for such requests. You should instead send back a hypermedia response with links so that the user can progress their browser state.

Also see the answers to these similar/identical questions:


* Mosaic, created by Marc Andreessen, also introduced the compound mistake of the <img src=…> tag — it should have been <image source=…>fallback</image>.
Cœur
  • 37,241
  • 25
  • 195
  • 267
Nicholas Shanks
  • 10,623
  • 4
  • 56
  • 80