342

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?

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
FilipK
  • 3,523
  • 3
  • 15
  • 7
  • 7
    HTML is the markup language, HTTP is the protocol – ratchet freak Oct 13 '11 at 13:57
  • 61
    @ratchet freak: I am aware of that. Nevertheless I'm asking specifically about HTML as it defines only GET and POST as allowed `
    ` methods.
     – FilipK Oct 13 '11 at 14:01
  • A typical scenario is a form with tabular data, where user need to PUT more lines or not, as "more lines" are user decision. Using Javascript+POST is artificial, perhaps HTML6 will show an alternative FORM feature to do this kind of operation. – Peter Krauss Oct 27 '14 at 13:43
  • 4
    is this still valid? https://www.w3.org/TR/form-http-extensions/#http-delete-form – Jeff Puckett Apr 23 '16 at 04:12
  • 1
    I answered this question when someone else asked it on Stack Overflow, and feel my contribution there has something to add to the excellent responses above, for anyone reading this far down the page :o) [Why don't browsers support PUT and DELETE requests and when will they?](http://stackoverflow.com/a/16812862/760706) – Nicholas Shanks Jan 27 '16 at 17:47
  • So that when someone ask if your RESTful website is compatible without javascript you realize you have to rewrite everything. – Rainb Feb 20 '21 at 08:40

7 Answers7

479

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 cachable, 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 (href):

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 (href):

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.

hakre
  • 1,165
  • 12
  • 17
Mark E. Haase
  • 5,175
  • 1
  • 17
  • 11
  • 103
    +1 for putting the research effort in place and digging up a number of external references to properly answer the question. –  Sep 17 '13 at 19:53
  • 3
    @mehaase, How it is different than making ajax put/delete request? – shivakumar Aug 21 '14 at 07:13
  • 8
    @shivakumar I think what you're really asking is why bother with HTML when JavaScript can already do the job? That's a fair question. I guess the OP's question comes more from a place of curiosity than of practicality. HTML and HTTP are two standards made for each other, and yet HTML seems to be unaware of some of HTTPs most basic properties. "Why?" is a natural question to ask. – Mark E. Haase Aug 28 '14 at 17:21
  • 39
    Surely you have to include a payload for PUT and for DELETE it is possible? Also if "doesn't make much sense with forms" then why are people asking for it and why does a lot if software he workarounds built in. Odd how one person can just decide what the rest of world needs or wants... – Jonathan. Sep 02 '14 at 10:30
  • 1
    So it seems the bug is closed now, with the following rationale: http://lists.w3.org/Archives/Public/public-html/2013Feb/0227.html The editor's draft is here: http://cameronjones.github.io/form-http-extensions/index.html That seems to be the end of the trail though. Can someone else find a place we can look to monitor this specification's track to becoming a standard? – Ajedi32 Jan 23 '15 at 19:39
  • 6
    @Ajedi32 I e-mailed Cameron Jones (the editor of the current draft) and asked him about the status. He wrote, "the spec is still alive and progressing through the W3C process - it's currently in working draft and the next stage is to hopefully move it into Candidate Recommendation (CR)." He also wrote, "The main factor in this is community interest… If you and others have interest in seeing this implemented i would definitely recommend advocating for such through public-html-comments, the whatwg or the vendors own mailing lists." – Mark E. Haase Feb 04 '15 at 17:43
  • 1
    @mehaase Awesome! Do you have a link to the Working Draft? Or is that the same as the "editor's draft" I linked (which seems to be hosted on Cameron's personal GitHub account)? – Ajedi32 Feb 04 '15 at 21:46
  • 4
    @mehaase Also, maybe it's just me, but I think mailing lists are a much better place for discussion than for expressing general support of a proposal. I'm not inclined to start a new thread on the public-html-comments mailing list just so I can say "I like this proposal; forms should be able to use other HTTP methods". As someone who grew up on the modern web, what I want to know is: "where's the upvote button?" ;-) – Ajedi32 Feb 04 '15 at 21:53
  • It's the same thing you already linked to. I think Cameron is going to send out an e-mail asking for vendor interest and community interest. When that happens, he would appreciate if those of us who care would chime in. – Mark E. Haase Feb 04 '15 at 23:16
  • 7
    @Ajedi32 here's the post: https://lists.w3.org/Archives/Public/public-html/2015Feb/0000.html I encourage everybody who's interested to reply to this post on the public-html mailing list. – Mark E. Haase Feb 06 '15 at 14:11
  • 1
    @mehaase That particular post seems to be asking for feedback from browser vendors, not web devs. Do you still think I (and other interested developers) should chime in there? – Ajedi32 Feb 06 '15 at 15:27
  • 1
    @Ajedi32 Nominally it is a request for vendors to express their interest level, but _anybody_ interested in the standard should voice their support. The more community support, the more likely vendors are to take notice. – Mark E. Haase Feb 06 '15 at 19:50
  • 1
    is this still valid? https://www.w3.org/TR/form-http-extensions/#http-delete-form – Jeff Puckett Apr 23 '16 at 04:11
  • 1
    So, it looks like discussion on the mailing list died off around February of last year, with no vendors chiming in. Obviously, Firefox has shown willingness to implement something like this in the past. The draft isn't being maintained. Maybe there needs to be some community rallying around this to breath some life into it? – jonnybot Oct 03 '16 at 17:07
  • 1
    There's an issue open to have this implemented in the issue trackers of the major browsers, so a good place to start would be to vote up those issues and explain the importance of this feature. Here's a post listing the issues for major browsers: https://lists.w3.org/Archives/Public/public-html/2015May/0055.html – jncraton Nov 28 '16 at 17:05
  • 1
    why couldn’t `x-www-form-encoded` be a representation of a resource to PUT? – Jonah Dec 22 '17 at 00:38
  • 5
    Why wouldn't I want to PUT a form payload? I cannot understand. – LCB May 03 '18 at 23:55
  • 4
    I don't agree with `DELETE only makes sense if there is no payload`. People don't make delete forms with GET method. But use POST to include CSRF verification. So, there is payload. – Mohammed Shareef C Dec 01 '18 at 07:20
  • I agree with @MohammedShareefC there is most definitely a payload with put and delete. With put, which records are you changing, and what information within those records are changing, and what are you changing it to? That would all be communicated via a payload. For delete, unless you're deleteing all records, which records are you deleting? – Tara Nov 15 '19 at 22:11
  • 1
    I must say this is disappointing. Especially with the file form control, more than any other, put and delete are immediately useful. PUT sending one or more file contents, and delete sending a URI – That Realtor Programmer Guy Jan 18 '20 at 11:10
  • I can agree with DELETE not having a data-related payload, but that doesn't make sense to me with PUT (specially given that the _formal_ definition of PUT is a complete payload, contrary to PATCH) – Ricardo Pedroni May 29 '20 at 19:01
  • 3
    "PUT as a form method makes no sense, you wouldn't want to PUT a form payload". For *editing* a resource that is *exactly* what you'd want to do... for `DELETE` i might see the point, but for `PUT`? Not so much. – Polygnome Jan 11 '21 at 09:22
  • 1
    Here I am spending hours and hours trying to write the most semantically-perfect application and they haven't even bothered to implement the words "PUT" and "DELETE" into literally one of the oldest components on the internet. – c.. Mar 14 '21 at 04:54
  • @Tara for DELETE, presumably you'd be deleting the resource at the URL that you send the request to. It's for deleting one thing that has its own URL, not for deleting a list of records. – bdsl Apr 18 '23 at 12:54
16

This is was raised in 2010 as Bug 10671 consider adding support for PUT and DELETE as form methods.

There was a moderate amount of pushback for this "feature" and some heavy-handedness but eventually this was escalated as two issues on the Working Groups bug tracker:

The issue ISSUE-196 resulted in a concensus decision to perform no change to the specification as the HTML specification does not currently restrict how responses to POST requests are handled. I believe this particular issue was raised in attempting to reconcile POST redirect patterns commonly in use and how ReSTful servers often provide 2xx responses with short messages rather than something useful to be rendered in a browser.

The issue ISSUE-195 was presented to the chairs. Cameron Jones stepped up to volunteer in writing a change proposal on the 18th of January 2012 which he submitted to become the first working draft on the 29th May 2014. The draft will go through the W3C recommendations process.

With any luck, this will soon become a W3C recommendation and implemented by browser vendors, and would be a great forward step in removing the blockers to produce unified, semantic and browser friendly ReSTful services. I imagine this will spark an interesting evolution in service patterns. There's a good talk by Jon Moore - Hypermedia APIs worth watching, this got my interest but fell down at the first hurdle (this one).

Stuart Wakefield
  • 261
  • 2
  • 5
14

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.

David Schwartz
  • 4,676
  • 22
  • 26
  • 25
    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
  • 3
    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
  • 11
    @David: That would be a _feature_. – Donal Fellows Oct 13 '11 at 15:42
  • 4
    @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. –  Oct 14 '11 at 10:40
  • 17
    The rationale is that POST and DELETE have different -- almost opposite -- meanings. You claim that POST completely covers DELETE, yet POST is not idempotent and DELETE is. How do you explain that? http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html – Mark E. Haase Sep 17 '13 at 18:27
  • 1
    @mehaase: Idempotence is the guaranteed absence of the characteristic of having multiple applications behave differently from a single one. Humans have the guaranteed absence of the characteristic "is an elephant" while mammals don't. Yet mammal covers humans. – David Schwartz Sep 17 '13 at 18:41
  • 15
    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. – Mark E. Haase Sep 17 '13 at 18:53
  • 16
    I disagree with this answer. `POST` is **not idempotent** which is why when you click "back" in your browser, it will display an ugly page that says the form needs to be resent. **However**, had it been a `PUT`, it could safely resend the `PUT` request to display whatever page you should get. Provided of course one does not mess up the API by creating a sort of `DELETE /resource/latest`. – arg20 Aug 20 '14 at 02:54
  • 3
    @arg20: For a resource which is only accessed by a single client, `PUT` or `DELETE` are idempotent, but there's often no way a client performing such an operation, *or even a server carrying it out* can know whether another client accessing that same resource will cause the operation not to be idempotent. For example, suppose client "Bob" tests once per second whether a file exists; if it doesn't, it creates the file and updates a count of how many times it has done so. If client "Joe" sends a delete request and then sends another one a minute later, the second request will... – supercat Sep 02 '14 at 16:40
  • 1
    ...end up affecting Bob, even if Joe has done no other operations in the interim. The server would know that "Bob" saw that the file was deleted, and that Bob did a "put" command, but even the server would have no way of knowing whether Bob would have done a "put" command [overwriting the file] even if Joe hadn't deleted the file, and thus can't tell what effect (if any) the second delete really had. – supercat Sep 02 '14 at 16:42
  • 1
    @supercat PUT and DELETE idempotence is not defined for multiple clients. The requests would still be idempotent for the same client unless the API is not well designed. For instance, an api that allows something such as DELETE /resourceFoo/latest is not well designed. – arg20 Sep 02 '14 at 18:26
  • 1
    @arg20: A protocol may only regard an operation as idempotent if repeating it would have no adverse effect *regardless of what anyone else in the universe might be doing*. Operations `put` and `delete` can be implemented so as to satisfy that constraint, but they usually aren't, and without such implementation a protocol handler wouldn't benefit much from such operations being "mostly" idempotent. – supercat Sep 02 '14 at 18:45
  • A typical scenario is a form with tabular data, where user need to PUT more lines or not, as "more lines" are user decision. Using Javascript+POST is artificial... What the rationale for this scenario? – Peter Krauss Oct 27 '14 at 13:46
  • 6
    PUT and DELETE are safe to repeat (either you don't care whether something has changed in the meantime, or you use `If-Match` to make sure it doesn't affect a changed resource). – Jon Hanna Dec 05 '14 at 14:17
  • 3
    According to RFC 2616, [`PUT` and `DELETE` are idempotent](http://tools.ietf.org/html/rfc2616#section-9.1.2). – DavidRR Dec 16 '14 at 16:01
  • 8
    The very fact that this question gets so many votes is reason enough. It is needlessly inconsistent/confusing, not to mention that supporting put and delete would make it easier to make the same RESTful API work both when accessed via JavaScript and when accessed in a browser that has JavaScript disabled. – Michael Aaron Safyan Dec 27 '14 at 01:17
  • 5
    @supercat Worth noting is that this is all convention anyway. Realistically speaking, server side code could generate new data on a `GET`. I believe what arg20 is saying is that HTTP *defines* that repeated, identical, sequential `PUT` and `DELETE` requests must leave the server in the same state as if only one were executed. Whether a server actually adheres to the standard is another matter altogether, and intermixing different requests does not negate the idempotence of the request. That's like saying a function `f(x)` isn't idempotent because I can do `f(g(f(f(x))))`. – jpmc26 Sep 10 '15 at 21:40
  • @jpmc26: Suppose someone opens up two sessions which as far as the server can tell are unrelated, and does a `PUT` in the first session, a `GET` on the second (retrieving the resource created by the first session), a `DELETE` of that resource on the second session, and repeats the `PUT` of the original resource in the first session. Should anyone decide that the second `PUT` should be ignored? If so, why, and what should be done if it's necessary that the resource should exist? – supercat Sep 10 '15 at 21:51
  • 1
    @supercat I repeat: the definition of idempotence only states that repeating the same operation more than once gives the same result as applying it once. Non-identical operations are not a consideration for idempotence. All idempotent means is that `f(f(f(x))) = f(x)` for any arbitrary number of applications of `f` on the left. Idempotence says nothing about what happens if you do `f(g(h(f(x))))`. You're describing mixed operations, not reapplication of a single operation. Idempotence does *not* require a certain result "regardless of what anyone else in the universe might be doing". – jpmc26 Sep 10 '15 at 21:57
  • 1
    @supercat I see your point, though. This fact makes idempotence a relatively useless property for caching whenever multiple connections are allowed. – jpmc26 Sep 10 '15 at 22:06
  • @jpmc26: Exactly. Sometimes features get added to an interface or protocol because it seems like they should logically exist, but in practice there are almost no cases where they're actually *useful*. In general, if a client issues two requests separated in time, it will be possible for another client to issue a request between them. Saying what should happen if two requests from the same client are processed consecutively isn't very meaningful if there's no way to predict whether two requests from the same client will in fact *be* processed sequentially. – supercat Sep 10 '15 at 22:23
  • @supercat Actually, there could be some advantages. All idempotence means is that there's a *possibility* that a response will be the same for a repeated operation. The result is that the client (or any agent that does not have full information about the state of the system) must still send a request for information, but it can also cache operations if the server can respond with a "No change" response to indicate that it should reuse content. Practically, this means we save resending the response body; that is less and less of a saving as bandwidth increases. – jpmc26 Sep 10 '15 at 22:33
  • @jpmc26: Is there any reason the same can't be done with operations that aren't idempotent? If a proxy still has the last response that was sent to a POST request, and the request is repeated but with a header that says "I'm expecting the same response at least time, which (outside the headers) had a hash of ___", is there any reason the proxy can't pass the response back up the line as "Yup, same response, and the hash is still ____"? – supercat Sep 10 '15 at 23:06
  • @supercat all of your arguments would apply equally well to requests made in any way, not just http form requests, correct? so you're arguing that PUT and DELETE are mistakes even to have in the HTTP spec? – Jonah Jul 03 '16 at 17:00
  • @Jonah: In what contexts are they useful? It's entirely possible that they're used ways I don't know about, but even if not it's pretty common for specs to include features which end up never getting used, and whose potential for usefulness quickly diminishes to nothing; such things should only be considered mistakes if the time spent implementing them exceeds the time that would have been required to determine that they couldn't possibly be useful. Since usefulness or lack thereof is sometimes hard to judge outside the context of a fully-implemented system, ... – supercat Jul 03 '16 at 17:50
  • ...it's sometimes easier to implement more features than will be needed and then experiment to see how well various combinations serve various purposes. If one minimizes the implementation costs of features that aren't actually used (e.g. allowing an implementation to simply include them in a list of commands to which it can simply reply "not supported") the cost of including a useless feature may be much less than the cost of failing to include one which can be emulated using other commands, but not as efficiently as it could be implemented directly. – supercat Jul 03 '16 at 17:54
  • @supercat so is your personal preference to delete resources by POSTing to /deleteXXX or similar. I'm not necessarily saying that's wrong just trying to clarify your position and understand your POV. – Jonah Jul 03 '16 at 18:05
  • @Jonah: More likely, something like POSTing to "xyz.com/filemgr" a message like "session=ewi3913x57;op=delete;target=/biz/foo/sillyPage.html", though I really haven't looked into the details of how such things work. – supercat Jul 03 '16 at 18:16
  • @supercat personally I'm torn. what you are saying would certainly work and I think it's legal according to the spec, and you can create extra features and finer grained control with such approaches. that said, it encourages everyone to create proprietary ad hoc standards when a semantically meaningful one (DELETE) already exists as a standard – Jonah Jul 03 '16 at 18:23
  • @Jonah: There doesn't typically need to be any form of authentication on the act of issuing a GET or POST; the code triggered by the POST request may decide not do anything useful for non-authenticated users, but that doesn't prevent the request from triggering that code. What standard means would exist for a server to confirm that a DELETE request was coming from an entity with adequate authority to issue it? Maybe such a thing exists, but I think confining all processing of authentication-related issues in one command type (POST) seems cleaner than distributing it among many. – supercat Jul 03 '16 at 18:50
  • 1
    @supercat I don't follow, why cant the server return 401 for an unauthorized DELETE ? i'm not aware of anything in the spec preventing that and always assumed that was how it was supposed to work – Jonah Jul 03 '16 at 18:53
  • For future readers authentication has literally nothing to do with the HTTP method being sent. GET, POST, PUT/PATCH, and DELETE are all equally capable of being used with authentication – Sampson Crowley Feb 14 '20 at 01:15
  • 1
    −1. This answer is a joke. PUT and DELETE *are* idempotent (cf. the HTTP/1.1 specification: https://datatracker.ietf.org/doc/html/rfc7231#section-4.2.2). And POST *is* cacheable (cf. https://datatracker.ietf.org/doc/html/rfc7231#section-4.2.3). – Géry Ogam May 21 '21 at 15:32
6

History

I think it's worth mentioning the first appearance of HTML forms in RFC1866 (Section 8.1). Here the method attribute is defined as the following:

     METHOD
            selects a method of accessing the action URI. The set of
            applicable methods is a function of the scheme of the
            action URI of the form. See 8.2.2, "Query Forms:
            METHOD=GET" and 8.2.3, "Forms with Side-Effects:
            METHOD=POST".

Further explanations are located in Section 8.2.2 - GET and Section 8.2.3 - POST

Keep in mind, that HTML 2.0 (Nov. 1995) was specified before HTTP 1.0 (May 1996). So everybody used HTTP only with GET (as of HTTP 0.9) or with the extension POST. But only a few web servers supported PUT and DELETE (like stated in the HTTP 1.0 Appendix).

Speculation

If you think about how Berners-Lee's development of the semantic web could have evolved it seems clear that it went from actual problems to a general concept

  1. First he wanted to share documents. Therefore he needed markup.
  2. Then he wanted to query databases for content, so he needed forms.
  3. Then he wanted to put new data into the database. So he used forms with GET and POST.

After that he may have realized that you could do every CRUD operation on data from remote, so HTTP was extended but never HTML because it was too late (only a few servers supported the new CRUD operations in 1996).

schmijos
  • 189
  • 1
  • 5
5

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.

maxpolun
  • 408
  • 2
  • 4
  • 7
    Is there a reason that PUT and DELETE can't or don't redirect the same way as POST? – Ryan H Jun 08 '12 at 00:03
  • 3
    @maxpolun This is probably the mailing list your are referring to: http://lists.w3.org/Archives/Public/public-html-wg-issue-tracking/2010Sep/0039.html – jordanbtucker Aug 02 '12 at 05:22
  • 3
    @RyanH There is not. Every app I have encountered that sends a delete request will reply with a redirect to the index. – Qwertie Aug 28 '18 at 01:06
-3

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"

Joe
  • 481
  • 5
  • 12
  • 6
    -1 "Get and post are are formats of transmitting the the data of the request." No, they are HTTP methods, not "formats". – Mark E. Haase Sep 17 '13 at 18:31
-4

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.

Shadur
  • 175
  • 1
  • 9
  • 13
    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. – Martin York Oct 13 '11 at 14:40
  • 8
    -1 Wild guesses are generally not helpful on SO. – Mark E. Haase Sep 17 '13 at 18:30