Why don't browsers support PUT and DELETE requests and when will they?

pixelearth picture pixelearth · May 29, 2013 · Viewed 12.6k times · Source

I'm seeing many frameworks recently that have decided to "fake" PUT and DELETE requests. 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?

Answer

Nicholas Shanks picture Nicholas Shanks · May 29, 2013

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