Are the PUT, DELETE, HEAD, etc methods available in most web browsers?

245,990

Solution 1

No. The HTML 5 spec mentions:

The method and formmethod content attributes are enumerated attributes with the following keywords and states:

The keyword get, mapping to the state GET, indicating the HTTP GET method. The GET method should only request and retrieve data and should have no other effect.

The keyword post, mapping to the state POST, indicating the HTTP POST method. The POST method requests that the server accept the submitted form's data to be processed, which may result in an item being added to a database, the creation of a new web page resource, the updating of the existing page, or all of the mentioned outcomes.

The keyword dialog, mapping to the state dialog, indicating that submitting the form is intended to close the dialog box in which the form finds itself, if any, and otherwise not submit.

The invalid value default for these attributes is the GET state

I.e. HTML forms 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.

However, GET, POST, PUT and DELETE are supported by the implementations of XMLHttpRequest (i.e. AJAX calls) in all the major web browsers (IE, Firefox, Safari, Chrome, Opera).

Solution 2

HTML forms support GET and POST. (HTML5 at one point added PUT/DELETE, but those were dropped.)

XMLHttpRequest supports every method, including CHICKEN, though some method names are matched against case-insensitively (methods are case-sensitive per HTTP) and some method names are not supported at all for security reasons (e.g. CONNECT).

Fetch API also supports any method except for CONNECT, TRACE, and TRACK, which are forbidden for security reasons.

Browsers are slowly converging on the rules specified by XMLHttpRequest, but as the other comment pointed out there are still some differences.

Solution 3

XMLHttpRequest is a standard object in the JavaScript Object model.

According to Wikipedia, XMLHttpRequest first appeared in Internet Explorer 5 as an ActiveX object, but has since been made into a standard and has been included for use in JavaScript in the Mozilla family since 1.0, Apple Safari 1.2, Opera 7.60-p1, and IE 7.0.

The open() method on the object takes the HTTP Method as an argument - and is specified as taking any valid HTTP method (see the item number 5 of the link) - including GET, POST, HEAD, PUT and DELETE, as specified by RFC 2616.

As a side note IE 7–8 only permit the following HTTP methods: "GET", "POST", "HEAD", "PUT", "DELETE", "MOVE", "PROPFIND", "PROPPATCH", "MKCOL", "COPY", "LOCK", "UNLOCK", and "OPTIONS".

Solution 4

_method hidden field workaround

Used in Rails and could be adapted to any framework:

  • add a hidden _method parameter to any form that is not GET or POST:

    <input type="hidden" name="_method" value="DELETE">
    

    This can be done automatically in frameworks through the HTML creation helper method (e.g. Rails form_tag)

  • fix the actual form method to POST (<form method="post")

  • processes _method on the server and do exactly as if that method had been sent instead of the actual POST

Rationale / history of why it is not possible: https://softwareengineering.stackexchange.com/questions/114156/why-there-are-no-put-and-delete-methods-in-html-forms

Solution 5

I believe those comments refer specifically to the browsers, i.e., clicking links and submitting forms, not XMLHttpRequest. XMLHttpRequest is just a custom client that you wrote in JavaScript that uses the browser as a runtime.

UPDATE: To clarify, I did not mean (though I did write) that you wrote XMLHttpRequest; I meant that you wrote the code that uses XMLHttpRequest. The browsers do not natively support XMLHttpRequest. XMLHttpRequest comes from the JavaScript runtime, which may be hosted by a browser, although it isn't required to be (see Rhino). That's why people say browsers don't support PUT and DELETE—because it's actually JavaScript that is supporting them.

Share:
245,990
John Millikin
Author by

John Millikin

Homepage: John Millikin E-Mail / Jabber: [email protected]

Updated on March 07, 2021

Comments

  • John Millikin
    John Millikin over 3 years

    I've seen a couple questions around here like How to debug RESTful services, which mentions:

    Unfortunately that same browser won't allow me to test HTTP PUT, DELETE, and to a certain degree even HTTP POST.

    I've also heard that browsers support only GET and POST, from some other sources like:

    However, a few quick tests in Firefox show that sending PUT and DELETE requests works as expected -- the XMLHttpRequest completes successfully, and the request shows up in the server logs with the right method. Is there some aspect to this I'm missing, such as cross-browser compatibility or non-obvious limitations?

  • Admin
    Admin over 15 years
    "HTML (up to version 4 and XHTML 1)" <- I suppose you meant to say HTTP. Remember: HTML is a file format (such as .exe, .doc or .psd) and HTTP is a protocol for information exchange (such as HTML web pages, images or word .doc files).
  • Kingo
    Kingo over 15 years
    No, I definitely mean HTML (I'm talking about HTML forms capabilities although that may not be clear from the text - I'll edit it)
  • Jacob Krall
    Jacob Krall over 15 years
    XMLHttpRequest is a standard object in the JavaScript Object model.
  • Pure.Krome
    Pure.Krome over 15 years
    @Matthew: does this mean that if i use IE6 or IE7, with the following :- <form .. method="PUT" >...</form> it will not work because PUT is not valid for HTML 4?
  • Kingo
    Kingo over 15 years
    Without trying it I couldn't say for certain. The specification (and the HTML 4 strict and transitional DTDs) only support POST/GET forms. It is quite possible that IE will handle PUT forms which are invalid with respect to the spec (e.g. in an HTML document which doesn't contain a doctype).
  • Max Jacobson
    Max Jacobson over 14 years
    Can anyone confirm which version of Safari gained support for PUT and DELETE?
  • Jarrett Meyer
    Jarrett Meyer over 14 years
    @Pure.Krome (only 14 months later) No, you cannot do <form method="put"> or <form method="delete"> under the HTML 4.01 spec. Only GET and POST are supported by IE8, Chrome3, or FF3.5.
  • Alan Plum
    Alan Plum over 14 years
    @porneL Yes, HTML5 allows these methods in forms, but sadly no browser seems to support them yet (two years later).
  • Stefan Tilkov
    Stefan Tilkov over 13 years
    The latest HTML5 draft seems to have dropped PUT and DELETE support: dev.w3.org/html5/spec/Overview.html#attr-fs-method
  • senfo
    senfo over 13 years
    @Jacob True, but different browsers have different JavaScript engines. Knowing which ones support PUT is still helpful.
  • Adam Lassek
    Adam Lassek about 13 years
    @porneL @Alan HTML5 added them, and then removed them. Currently only GET and POST are allowed. goo.gl/8EuZk
  • Joost Baaij
    Joost Baaij almost 13 years
    A draft has been proposed to get them back: amundsen.com/examples/put-delete-forms
  • Emil Lerch
    Emil Lerch over 12 years
    @porneL HTML5 added them, and then removed them, and now the bug is reopened. Interestingly, I've seen some documentation that still has them in there. Here's the bug if you want to follow along at home: w3.org/Bugs/Public/show_bug.cgi?id=10671
  • naugtur
    naugtur over 12 years
    I hoped to see some pieces of documentation for further reading, I dodn't say I don't belive you. The links on wikipedia are quite nice actually. Thanks
  • JayC
    JayC about 12 years
    CHICKEN? The bird? I suppose you mean CHECKIN. That's a funny vowel swap.
  • Anne
    Anne about 12 years
    No I meant CHICKEN, illustrating it can be whatever you like. Agreed about the vowel swap being funny though :-)
  • Cody
    Cody almost 10 years
    Can anyone elaborate on if all browsers NOW support PUT & DELETE -- and roughly how long this has been available. Noting on the "CHICKEN" example, does this mean that its entirely up to the server to interpret which method is used AND that JavaScript does not restrict the method type...?
  • Pacerier
    Pacerier over 9 years
    @EmilLerch, Seriously people need to leave it alone. The web doesn't need PUT DELETE PATCH and CAPRINE. We can do fine with just GET and POST. What value does CAPRINE add?
  • Ajedi32
    Ajedi32 over 9 years
    @Pacerier How do you update a resource without PUT or PATCH though? And how do you DELETE one without DELETE? POST is only meant to be for creating new resources.
  • Pacerier
    Pacerier over 9 years
    @Ajedi32, How? GET and POST and POST and GET. Everyone's doing it and everything's working fine. POST is only meant to be for creating new resources, just like how the internet is only meant to be for doing military communications. I don't see you complaining about how the purpose of the internet has been changed to fit new needs, so why are you complaining when the GET and POST are reworked?
  • Ajedi32
    Ajedi32 over 9 years
    @Pacerier It's a bit like using <table>s for layout in HTML, or using the <font> tag for styling. You can do it that way, but it's semantically and/or structurally incorrect. Many web frameworks these days use a special "method override" field in their forms, which allows them to send requests which are interpreted as PUT or DELETE by the server. This is a hack which can only be fixed by allowing forms to use these methods for real.
  • Pacerier
    Pacerier over 9 years
    @Ajedi32, Tables are rejected because they take longer for browsers to parse and take longer to code by hand. PUT and DELETE gives you no possible runtime speed advantage nor development speed advantage.
  • Ajedi32
    Ajedi32 over 9 years
    @Pacerier That doesn't explain <article>, <aside>, <nav> and <section> though. Like I said, it's about semantics. The same goes for HTTP methods. Read the spec: w3.org/Protocols/rfc2616/rfc2616-sec9.html Also, if you need a more practical reason, note that PUT and DELETE are idempotent. POST is not.
  • Pacerier
    Pacerier over 9 years
    @Ajedi32, You are confusing semantics with protocol conventions. Semantic data only make sense when there's a robot crawling through those data automatically without any extra information feeded. The whole point of <section> and <nav> is to allow crawlers to crawl them. PUT and DELETE are not semantic data because there is no one-size-fit-all crawler that crawls the entire web's PUT and DELETE requests. Also, who told you that POST cannot be idempotent? I've seen plenty of idempotent POSTs. PUT, DELETE, and POST are protocol conventions, not semantic data.
  • Ajedi32
    Ajedi32 over 9 years
    @Pacerier Actually, for servers which correctly implement all the HTTP methods, it is possible to "crawl" PUT and DELETE requests (or at least determine which pages support them), using the OPTIONS method. Also, I didn't mean that POST cannot be idempotent, just that HTTP clients cannot assume that it is, as with PUTS and DELETE. (Hence the "confirm resubmission" prompts you often see in browsers).
  • rustyx
    rustyx over 9 years
    Note: IE6/7/8 allow only "standard" HTTP methods, they won't allow the CHICKEN method. You'll get an "Illegal argument" exception.
  • Stijn de Witt
    Stijn de Witt almost 9 years
    it's actually JavaScript that is supporting them. Not really true. XMLHttpRequest is a 'host-object', meaning that it's an object that exposes functionality from the host to Javascript code. It's not a part of JS itself.
  • n0nag0n
    n0nag0n about 8 years
    For those just as bewildered as I was with this CHICKEN business .... w3c-test.org/XMLHttpRequest/open-method-case-sensitive.htm
  • Namrata Das
    Namrata Das almost 8 years
    @Pacerier The HTTP Verb is semantic information about the intent of the request, even if it's transient.
  • Joe Dargie
    Joe Dargie about 7 years
    BREW or nothin’.
  • Mirich
    Mirich almost 6 years
    Santilli, hi dude well it has been a long time since you offered this solution, and since I am a beginner in web development I have a question which I hope you will answer. So, you said that "processes _method on the server and do exactly as if that method had been sent instead of the actual POST" you meant that if hidden method with PUT(or DELETE) is put in the view, it would actually mean PUT(or DELETE) request right? if yes then why to use POST method at the beggining and then use hidden PUT or DELETE. What's the connection between POST and PUT(or DELETE) :)
  • Ciro Santilli OurBigBook.com
    Ciro Santilli OurBigBook.com almost 6 years
    @Mirich the form only supports POST. So we send POST with extra data, which the server knows means: ah, I should treat this like a PUT.
  • Mirich
    Mirich almost 6 years
    Thank you Ciro for your attention and reply, so can I consider this scenario like this:POST is a universal thing which holds actual POST, PUT, PATCH and DELETE inside itself and if you use POST at the beginning without hidden then it would mean actual POST. But if you use POST with hidden(PUT or DELETE) then you let server know that you want to use PUT or DELETE which are inside POST as its children inside I know a bit strange analogy but is that correct? :)
  • Ciro Santilli OurBigBook.com
    Ciro Santilli OurBigBook.com almost 6 years
    @Mirich yup, I think you've gotten the idea.
  • Mirich
    Mirich almost 6 years
    sorry Ciro just last thing, I wonder why PUT and DELETE were removed from HTML5 since wouldn't it better if you could just use PUT or DELETE at the beginning of form tag and just not use hidden. Please can you explain shortly and clearly what was the actual reason for the removal of PUT and DELETE. Thank you in advance :)
  • Ciro Santilli OurBigBook.com
    Ciro Santilli OurBigBook.com almost 6 years
    @Mirich I didn't know anything changed in HTML5. I don't know the rationale, google leads me to: softwareengineering.stackexchange.com/questions/114156/…
  • Shruggie
    Shruggie over 5 years
    What are the security concerns of letting client-side JavaScript use the CONNECT method?