This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
It seems that we currently do not understand how PUT and DELETE will be useful for HTML forms. For DELETE, it's indeed easy to create a useful request. However, server implementations usually respond with 200 and a minimal response body ("deleted") or 204 (no content). So it's not clear how this can be used in a web application. For PUT, it seems there's no real use case as long as the web page doesn't have full control over the payload, and also can set the content type. Please consider removing this feature until there's a clearer understanding about what it's good for.
I think this makes sense. The main reason we added these was because of XForms and that has never really been a good reason.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: see diff given below Rationale: Concurred with reporter's comments.
Checked in as WHATWG revision r5566. Check-in comment: Put method=DELETE and method=PUT to rest. http://html5.org/tools/web-apps-tracker?from=5565&to=5566
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. Typically, devs and frameworks end up creating work-arounds that mimic the HTTP PUT/DELETE + Etag interaction using a "POST FORM" coupled with specialized server-side code to sort out the special case and act as if the proper HTTP Method was used in the request: <!-- typical work-around to support PUT/DELETE --> <form method="post" action="..."> <input type="hidden" name="override_method" value="put" /> <input type="hidden" name="hashtag" value="..." /> ... </form> This pattern is required so often that several commonly-used Web frameworks/libraries[1][2][3][4] have created a "built-in" work-around. Note that some libraries include support for a concurrency value and some do not. Other considerations: - Using POST as a tunnel instead of using PUT/DELETE can lead to caching mis-matches (e.g. POST responses are cachable[5], 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?"). - Tunneling leads to reduced "visibility" of the application protocol over the wire which complicates request auditing, authorization-level security, etc. - Adding support for PUT/DELETE (along w/ inclusion of the If-Match/If-Unmodified-Since headers) can reduce ocurrences of the "Lost Update" concurrency problem. [1] http://guides.rubyonrails.org/form_helpers.html#how-do-forms-with-put-or-delete-methods-work [2] http://book.cakephp.org/view/183/Creating-Forms#options-type-184 [3] http://djangosnippets.org/snippets/174/ [4] http://geekswithblogs.net/michelotti/archive/2010/01/08/implementing-a-delete-link-with-mvc-2-and-httpmethodoverride.aspx [5] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5 [6] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6 [7] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.7
(In reply to comment #4) This seems to be a general comment about the goodness of PUT and DELETE vs doing everything with POST. I agree with this. The tricky question is how to actually *use* PUT and DELETE with HTML forms. The bug was raised because I think the spec (as it was back then) wasn't specific enough to make this work, and thus early adoption (such as in FF4) would make it very hard to do the right thing later on. With respect to cacheability: my understanding is that cacheability is the same for PUT, POST, DELETE and many other methods. You may want to have a look at HTTPbis, Part 6 (http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p6-cache-11.html)
(In reply to comment #5) > (In reply to comment #4) > > This seems to be a general comment about the goodness of PUT and DELETE vs > doing everything with POST. I agree with this. I posted here based on a suggestion to "explain in detail..." my example of a use case for PUT (http://krijnhoetmer.nl/irc-logs/whatwg/20101006#l-662). > > The tricky question is how to actually *use* PUT and DELETE with HTML forms. I think the uses of PUT/DELETE in the four frameworks I cited is clear, correct? > The bug was raised because I think the spec (as it was back then) wasn't > specific enough to make this work, and thus early adoption (such as in FF4) > would make it very hard to do the right thing later on. I understood that it was removed "until there's a clearer understanding about what it's good for." Have I misinterpreted your remark in the bug description? > > With respect to cacheability: my understanding is that cacheability is the same > for PUT, POST, DELETE and many other methods. You may want to have a look at > HTTPbis, Part 6 > (http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p6-cache-11.html) I am familiar w/ this material. It's not clear to me (from your comment here) how the content in Part 6 affects my remarks on POST's cacheability per HTTP 1.1 vs. PUT and DELETE. More to the point, I see no changes in Part 2 (http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-11.html) that indicate a change in the cacheability of POST, PUT or DELETE. Can you help me make sure I understand your point here?
(In reply to comment #6) > I posted here based on a suggestion to "explain in detail..." my example of a > use case for PUT (http://krijnhoetmer.nl/irc-logs/whatwg/20101006#l-662). Ack. And just for reference; I opened this bug because the (now-disabled/removed) implementation in FF4 had two bugs, one of which was about a bad target URI being computed, the other one with respect to handling redirects. The former was a bug with respect to what HTML5 said, the latter isn't specified in HTML5, so the code just reused XMLHttpRequest behavior (which I think is broken as well). This made me nervous about this ever getting be done *right*. > > The tricky question is how to actually *use* PUT and DELETE with HTML forms. > > I think the uses of PUT/DELETE in the four frameworks I cited is clear, > correct? As far as I can tell, these use POST to tunnel PUT/DELETE. There's nothing wrong about that in principle. Maybe the disagreement is based on where we come from? I'm using servers that do support PUT and DELETE all the time. These servers send 200/201/204 with a minimal status message when things go right. How are these supposed to be used from an HTML form? Maybe they aren't supposed to? > > The bug was raised because I think the spec (as it was back then) wasn't > > specific enough to make this work, and thus early adoption (such as in FF4) > > would make it very hard to do the right thing later on. > > I understood that it was removed "until there's a clearer understanding > about what it's good for." Have I misinterpreted your remark in the bug > description? I don't think so. I think what's needed is a story about how PUT and DELETE is going to be used in practice. In particular, whether servers that already support PUT and DELETE need to be modified so this can be used from HTML forms; sending the request is simple, but what's less clear is what response codes are supported and how they affect the web application. > I am familiar w/ this material. It's not clear to me (from your comment here) > how the content in Part 6 affects my remarks on POST's cacheability per HTTP > 1.1 vs. PUT and DELETE. More to the point, I see no changes in Part 2 > (http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-11.html) that > indicate a change in the cacheability of POST, PUT or DELETE. Can you help me > make sure I understand your point here? Work in progress... There shouldn't be special cases except for GET/HEAD. See <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/139> (we may have to re-open this issue, please follow up on the HTTP WG mailing list if you think more needs to be done).
FWIW, I sense a bit of context-switching here in the reasons for dropping this feature: - "implementation in FF4 had two bugs" (Understood) - "There's nothing wrong ... in principle" (I don't share that opinion<g>) - "what's needed is a story about how PUT and DELETE is going to be used in practice." (Provided) - "...servers send 200/201/204 with a minimal status message when things go right. How are these supposed to be used from an HTML form?" (The same as when they returned by POST) - "...whether servers that already support PUT and DELETE need to be modified..." (I don't see why this is an issue and would like to see a worked out case where this is a potential problem). It seems the bug list is not the place for discussion on these items and I don't have standing in W3C to post to html-public in order to pursue this. If you care to pursue it you can contact me in IRC or directly via email (mamund -AT- yahoo -DOT- com). Thanks for your time. MCA (In reply to comment #7) > (In reply to comment #6) > > I posted here based on a suggestion to "explain in detail..." my example of a > > use case for PUT (http://krijnhoetmer.nl/irc-logs/whatwg/20101006#l-662). > > Ack. And just for reference; I opened this bug because the > (now-disabled/removed) implementation in FF4 had two bugs, one of which was > about a bad target URI being computed, the other one with respect to handling > redirects. > > The former was a bug with respect to what HTML5 said, the latter isn't > specified in HTML5, so the code just reused XMLHttpRequest behavior (which I > think is broken as well). This made me nervous about this ever getting be done > *right*. > > > > The tricky question is how to actually *use* PUT and DELETE with HTML forms. > > > > I think the uses of PUT/DELETE in the four frameworks I cited is clear, > > correct? > > As far as I can tell, these use POST to tunnel PUT/DELETE. There's nothing > wrong about that in principle. > > Maybe the disagreement is based on where we come from? I'm using servers that > do support PUT and DELETE all the time. These servers send 200/201/204 with a > minimal status message when things go right. How are these supposed to be used > from an HTML form? Maybe they aren't supposed to? > > > > The bug was raised because I think the spec (as it was back then) wasn't > > > specific enough to make this work, and thus early adoption (such as in FF4) > > > would make it very hard to do the right thing later on. > > > > I understood that it was removed "until there's a clearer understanding > > about what it's good for." Have I misinterpreted your remark in the bug > > description? > > I don't think so. > > I think what's needed is a story about how PUT and DELETE is going to be used > in practice. In particular, whether servers that already support PUT and DELETE > need to be modified so this can be used from HTML forms; sending the request is > simple, but what's less clear is what response codes are supported and how they > affect the web application. > > > I am familiar w/ this material. It's not clear to me (from your comment here) > > how the content in Part 6 affects my remarks on POST's cacheability per HTTP > > 1.1 vs. PUT and DELETE. More to the point, I see no changes in Part 2 > > (http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-11.html) that > > indicate a change in the cacheability of POST, PUT or DELETE. Can you help me > > make sure I understand your point here? > > Work in progress... > > There shouldn't be special cases except for GET/HEAD. See > <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/139> (we may have to re-open > this issue, please follow up on the HTTP WG mailing list if you think more > needs to be done).
My main concern is the inconsistency with GET/POST with regard to cross-origin requests on top of these being used far less than GET/POST. If they did not require the special handling the choice would be easy, but now it is not clear whether the additional complexity is justified. So in my opinion we should punt on this feature for now until it is more clear what exactly is needed.
(In reply to comment #9) > My main concern is the inconsistency with GET/POST with regard to cross-origin > requests on top of these being used far less than GET/POST. If they did not > require the special handling the choice would be easy, but now it is not clear > whether the additional complexity is justified. > > So in my opinion we should punt on this feature for now until it is more clear > what exactly is needed. i an no expert on cross-origin requests or the implementation complexity, however i would hazard that these are being using far less than PUT and DELETE. in response to an open question on public-html-comments, this bug has been reviewed and is requested to be reopened based on the feedback provided in the thread: http://lists.w3.org/Archives/Public/public-html-comments/2011Mar/0006.html To paraphrase the fundamental requirement for supporting these methods on forms: so that a real human is able to interact natively with a Restful system using plain html, no ajax or other workarounds. The form is the only user interface element capable of initiating custom HTTP requests, without the full spectrum of methods being supported no other means are available for interacting with HTTP-conformant services.
Quickly writing this off the top of my head... I've always thought about it like this with the methods in HTML forms - quick recap: POST: form data is collected (as defined by HTML), encoded in the given "enctype" and submitted as the request body to the URL in the "action" attribute. GET: this method, as defined by HTTP, must not have a request body (I think servers are advised to even discard any body, if I remember correctly), so the form data will be submitted as the query string of the URL given in the "action" attribute. The encoding format "defaults" to "application/x-www-form-urlencoded". So basically _GET_ is the special case, because the natural way of sending data to a server would be as the request body. Which basically means for the methods PUT and DELETE: PUT: virtually the same as POST, from the form's point of view. DELETE: just like GET, this method must not have a request body. Should be handled the same way as GET (lump the form data into the query string). Here are my brainstormed ideas for enriching HTML forms: Since HTTP defines a couple of standard methods, but adding custom methods is absolutely allowed, I think HTML forms should not restrict the methods in the "method" attribute. Unknown methods (not in the original HTTP specification) should be handled the same way as POST or PUT. This would eg. allow the PATCH method defined in RFC 5789 to basically work (but which probably needs a new "enctype" anyway). We could also add an attribute that defines "where" the form data is sent, something like <form where="query-string" method="FOO"> (GET/DELETE methods imply "query-string") <form where="body" method="BAR"> (POST/PUT methods imply "body") and maybe even <form where="header" method="BAR"> (to send form data as additional HTTP headers instead; haven't thought about security implications with this, just an idea) This would allow for custom methods to be sent via query string as well (we could also call the attribute "via", "position" or something). I also consider DELETE a special case, that could be handled in an alternate way. Since a user-triggered GET request in HTML is also made by clicking on a hyperlink (a functionality which can be emulated using a GET HTML form), and DELETE requests will probably mostly point to a specific resource where it makes no sense to add a query string (eg. http://example.com/users/42), maybe we could extend button/input elements: <button type="delete" url="http://example.com/users/42">Delete User Douglas</button> Such an element needs not be contained inside a form element and just sends the DELETE request to the specified URL. Clients could by default show a confirmation dialog before actually submitting a DELETE request. Other things I've thought about are how it could be done to eg. send a file (let's say an "image/png") to a URL with its correct MIME type using forms in HTML (without wrapping it inside a "multipart/form-data" body), which might be interesting for PUT. Maybe an attribute like "only": <form method="PUT" action="..." enctype="image/png" only="foobar"> <input type="file" name="foobar" accept="image/png" /> <button type="submit">Upload</button> </form> "enctype"/"accept" could be omitted to allow arbitrarily formatted data to be sent (and let the client make his best efforts to guess the MIME type of the uploaded file). With this we could start to build interfaces in HTML forms for easy interaction with RESTful webservices. One last thing about the server's response: replying with a "200 OK" status is perfectly valid for PUT and DELETE requests. BTW, last time I checked, Firefox honors the "204 No Content" status as defined by HTTP, by sending the form and not resetting the document view. I know of the "onsubmit" event triggered by browsers to use with JavaScript, but is there something like an "onsubmitcomplete" event as well? Would be interesting to know how other browsers handle this or similar response statuses. Browsers should definitely somehow notify the user on "204 No Content" by displaying an asynchronous notification box.
> To paraphrase the fundamental requirement for supporting these methods on > forms: > so that a real human is able to interact natively with a Restful system using > plain html, no ajax or other workarounds. Speaking as a developer, I think this is reason enough to have PUT/DELETE in forms. This feature would be useful in documenting, debugging, prototyping, manual testing and automated testing. The ramifications for the domain of web services could range quite far. Self-documentation in particular is perceived as a weak spot of REST services when compared with SOAP services. I also see another advantage of PUT/DELETE in forms: they let the browser know that you're doing something idempotent. When you issue a POST through a form and then hit the "back" button (or you hit "refresh" before the response has come through), the browser has no choice but to show you a scary confirmation dialog, that regularly perplexes non-technical users. With PUT/DELETE, browsers could choose to just re-submit, or at least show you a dialog that's more informative. Ajax wouldn't help there, because it happens behind the browser's back. Just my 2 cents.
Additional Proposal Submitted: http://lists.w3.org/Archives/Public/public-html/2011Apr/0259.html This proposal introduces the manipulation of HTTP headers via form fields, construction of HTTP Authentication headers and support for HTTP CONNECT method.
*** Bug 12647 has been marked as a duplicate of this bug. ***
mass-move component to LC1
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change 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.
> Rationale: PUT as a form method makes no sense, you wouldn't want to PUT a form > payload. (...) Why not? > (...) DELETE only makes sense if there is no payload, so it doesn't make > much sense with forms either. That doesn't make any sense, otherwise GET wouldn't work from forms, either.
> 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. instead of having to justify why PUT is valid you should explain in what way the http specification 'doesn't make much sense'. a specification is either correct or incorrect, given the number of existing services using PUT and it is, at the very least, proven correct in this case by field use. DELETE requires the same support as GET to enable parametric construction of the request URI. For example: <form action="http://example.org/user" method="delete" if-match="*"> <input name="hat-size" type="text" value="" /> <input type="submit" /> </form> In order for the user to DELETE the following hats: DELETE /user?hat-size=small HTTP/1.1 Host: www.example.org If-Match: "*" a lot of collaborative work has gone on since this bug report was reopened including the introduction of new information and the development of the implementation complexities and requirements of the case. this work should be engaged and referenced otherwise the resolution of this bug report is premature and ill-informed.
Through further discussion on public-html-comments[1] I request that this bug is escalated into the tracker issue process. I recommend that the following two identified issues are created as separate concerns: Issue 1: Enhance http request generation from forms Forms should be capable of defining and constructing full http request representations for all methods in order for html to interact with conformant http services. Issue 2: Define user agent http response handling behaviour User agent handling of http responses is currently undefined which has lead to divergent behaviour[2] through independent interpretation of the http specification. The expected behaviour should be defined within html to enable servers to return correct responses per http specification with confidence that they will be processed uniformly across agents. [1] http://lists.w3.org/Archives/Public/public-html-comments/2011Dec/0003.html [2] http://www.cmhjones.com/browser-http-test-matrix.html
Opened <https://www.w3.org/html/wg/tracker/issues/195> and <https://www.w3.org/html/wg/tracker/issues/196>.
First, I'm surprised at the seemingly unjustified dismissal of this enhancement request. Ian, it would be helpful if you would elaborate on your current position. I'm personally in favor of adding support for the PUT and DELETE methods to the HTML specification, in fact, I'd personally like to see support for any and all HTTP request methods. 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? HTML forms play the very important role of allowing a user to send data to a HTTP server - data that's relevant to the action being performed. The action that is performed as a result of the submission is determined not by the user, but by the forms method, as defined by the designer of the form. If you we are to assume that the form designer had no control over the HTTP server, then how does the form designer allow the user of the form to DELETE or PUT a resource? It should be possible to put a HTML form in front of any HTTP server supporting GET, POST, PUT, and DELETE, and have that form be able to performing any of those actions without the need for server-side code that falls outside the HTTP specification. It's only because of server-side programming languages and programmers who have made special provisions, that we have managed to get by without PUT and DELETE support in HTML. If anyone has a static/traditional HTTP server that depends on the available HTTP methods to fulfil requests, then HTML does not allow for full interaction with the resources on that server, and I think that points to a fundamental problem with the HTML spec. With the popularity of REST, application architects want to provide a single interface for machines and humans. Applications should not have to determine who or what made the request. The HTTP method should tell the server what action should be performed, and the headers should communicate what the client expects in response. The current HTML specification does not allow for such a unified interface, at least not without work-arounds employed by application frameworks. As a human interface for HTTP, HTML has failed. 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. If this is not reason enough for including at least the PUT and DELETE methods in the HTML specification, then it needs to be explained why. Minor implementation details like how the client should behave under certain conditions should not get in the way of determining the validity or relevance of this suggested enhancement to the HTML specification. Though I'm not entirely sure why or how PUT and DELETE would introduce any client implementation problems not already addressed by support for the POST method. It's obvious this bug report has yet to reach a resolution, I've therefore changed the status to REOPENED.
(In reply to comment #21) > ... > It's obvious this bug report has yet to reach a resolution, I've therefore > changed the status to REOPENED. Tom, see comment 20. This issue has been escalated, so it's correct that the state over here is "RESOLVED". (In doubt see the WG's decision policy document). A general remark: I don't think there's strong opposition to this in general; the tricky thing is to find out how far to go and to get the interaction with HTTP right and whether HTML5 is (being post Last Call) is the right version to apply it to.
I somehow missed that comments, my apologies. The proposal you have put together seems well thought out. I initially thought it was too complex, but the rationale was sound.
*** Bug 22695 has been marked as a duplicate of this bug. ***