Menu
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?
382
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.
You cannot make a POST request by using a web browser, as web browsers only directly support GET requests.
The HTTP DELETE method is used to delete a resource from the server. Unlike GET and HEAD requests, the DELETE requests may change the server state. Sending a message body on a DELETE request might cause some servers to reject the request. But you still can send data to the server using URL parameters.
HTML forms (up to HTML version 4 (, 5 Draft) and XHTML 1) only support GET and POST as HTTP request methods. A workaround for this is to tunnel other methods through POST by using a hidden form field which is read by the server and the request dispatched accordingly.
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:
<img src=…> tag — it should have been <image source=…>fallback</image>.
129
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
