current community

your communities

more stack exchange communities

Stack Exchange
tour help
Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 26 down vote favorite
5

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?

share|improve this question
3  
HTML is the markup language, HTTP is the protocol –  ratchet freak Oct 13 '11 at 13:57
8  
@ratchet freak: I am aware of that. Nevertheless I'm asking specifically about HTML as it defines only GET and POST as allowed <form> methods. –  FilipK Oct 13 '11 at 14:01
add comment

5 Answers

up vote 22 down vote accepted

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

share|improve this answer
5  
+1 for putting the research effort in place and digging up a number of external references to properly answer the question. –  GlenH7 Sep 17 '13 at 19:53
add comment
up vote 11 down vote

GET and POST have a clear content-neutral rationale. GET is to retrieve the content of an URL in a way that is safe to repeat and possibly cache. POST is to do something in a way that is not safe to repeat, execute speculatively, or cache.

There was no similar rationale for PUT or DELETE. They are both completely covered by POST. Creating or destroying a resource are operations that are not safe to repeat, not safe to execute speculatively, and should not be cached. There are no additional special semantics needed for them.

So basically there is no benefit.

share|improve this answer
5  
Although POST covers PUT and DELETE, I can still see the benefit of having separate methods. All of them are covered in HTTP specification and their usage is encouraged in REST. –  FilipK Oct 13 '11 at 13:23
2  
The problem with using them for REST is that PUT and DELETE are quasi-idempotent. Two PUTs or two DELETEs are supposed to do the same thing as one. But with on locking or synchronization, it's almost useless. Consider: I PUT, you see my PUT and DELETE. I repeat my PUT. Ooops, I undid your DELETE. –  David Schwartz Oct 13 '11 at 14:02
6  
@David: That would be a feature. –  Donal Fellows Oct 13 '11 at 15:42
2  
@David Yes I undid your delete. This is how it is supposed to work. Here is not enough room to elaborate on RESTful APIs but it is perfectly doable to make safe interface with PUT and and DELETE. –  Petr Gladkikh Oct 14 '11 at 10:40
3  
Clever analogy, but you're re-defining what "covers" means. In your original answer, you mean "covers" as in, "supports all of the same use cases". Here you are redefining "covers" to mean some sort of taxonomical relationship. Let's cut through language: POST does not support the same use cases as DELETE due to the difference in idempotence. GET does not support the same use cases as DELETE due to the different semantics. Support for DELETE would increase user agent functionality. –  mehaase Sep 17 '13 at 18:53
show 2 more comments
up vote 2 down vote

My understanding is that browsers don't know what to do once they send a PUT or a DELETE. A POST will redirect to an appropriate page usually, but PUT and DELETE typically don't. This makes them appropriate for calling via ajax or a native program, but not from a web browser form.

I can't hind it right now, but I remember reading one of the html5 mailing lists when they were discussing this.

share|improve this answer
2  
Is there a reason that PUT and DELETE can't or don't redirect the same way as POST? –  Ryan H Jun 8 '12 at 0:03
1  
@maxpolun This is probably the mailing list your are referring to: lists.w3.org/Archives/Public/public-html-wg-issue-tracking/… –  Jordan Aug 2 '12 at 5:22
add comment
up vote 0 down vote

Just throwing out a wild guess, but probably because HTTP isn't terribly good with access control at the best of times, and the last thing everyone needs is even more ways for malicious URLs to compromise a poorly secured website and/or application.

HTTP isn't really a good protocol for file transfers other than downloading from server to client. Use FTP - or better yet, SFTP.

share|improve this answer
7  
Security has no bearing on this. You can still make PUT/Delete requests via HTTP. curl --request PUT http://A.B.c/index The question is why can you access these commands via HTML. –  Loki Astari Oct 13 '11 at 14:40
2  
-1 Wild guesses are generally not helpful on SO. –  mehaase Sep 17 '13 at 18:30
add comment
up vote -3 down vote

Get and post are are formats of transmitting the the data of the request.

I suppose you are asking about making form submission into a RESTFUL service. But it does not make sense to change the http request standard to make assumptions the purpose of the http request. Information of about the purpose that the request fills is best handled in the input fields.

Having an address and get and post allows the server to interpret the request and it's input values correctly. From there the input values allow you to make open ended requests to the server and do what ever you want. For example, you can have a field whose values are "put" and "delete"

share|improve this answer
1  
-1 "Get and post are are formats of transmitting the the data of the request." No, they are HTTP methods, not "formats". –  mehaase Sep 17 '13 at 18:31
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.