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

7

635

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?

Athematic answered 3/10, 2008 at 5:26 Comment(5)
It's not just the client you need to worry about, lots of server side frameworks only support GET and POST.Boomer
John, any reason you don't want the REST tag?Hieronymus
Although people who read this are likely to be investigating RESTful APIs.Holst
Related: Why are there are no PUT and DELETE methods on HTML forms?Adjudication
No, all browser don't supports PUT/DELETE methods, and also not all server side technologies don't supports PUT/DELETE. Only HTML 5 supported browser supports PUT/DELETE.Ostap
S
476

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).

Sheenasheeny answered 3/10, 2008 at 12:2 Comment(17)
"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).Alwitt
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)Sheenasheeny
@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?Katusha
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).Sheenasheeny
@Katusha (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.Waiver
@porneL Yes, HTML5 allows these methods in forms, but sadly no browser seems to support them yet (two years later).Disarm
@porneL @Alan HTML5 added them, and then removed them. Currently only GET and POST are allowed. goo.gl/8EuZkWilks
@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=10671Caenogenesis
@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?Overtime
@Overtime 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.Adjudication
@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?Overtime
@Overtime 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.Adjudication
@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.Overtime
@Overtime 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.Adjudication
@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.Overtime
@Overtime 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).Adjudication
@Overtime The HTTP Verb is semantic information about the intent of the request, even if it's transient.Golden
B
90

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.

Bawcock answered 3/10, 2008 at 5:27 Comment(8)
The latest HTML5 draft seems to have dropped PUT and DELETE support: dev.w3.org/html5/spec/Overview.html#attr-fs-methodXenophanes
A draft has been proposed to get them back: amundsen.com/examples/put-delete-formsHambley
CHICKEN? The bird? I suppose you mean CHECKIN. That's a funny vowel swap.Barretter
No I meant CHICKEN, illustrating it can be whatever you like. Agreed about the vowel swap being funny though :-)Bawcock
Note: IE6/7/8 allow only "standard" HTTP methods, they won't allow the CHICKEN method. You'll get an "Illegal argument" exception.Alienage
For those just as bewildered as I was with this CHICKEN business .... w3c-test.org/XMLHttpRequest/open-method-case-sensitive.htmCallow
BREW or nothin’.Duma
What are the security concerns of letting client-side JavaScript use the CONNECT method?Buttonhole
R
44

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".

Rhachis answered 3/10, 2008 at 9:59 Comment(1)
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. ThanksMalawi
P
25

_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

Pluperfect answered 12/11, 2014 at 21:49 Comment(6)
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) :)Wexler
@Wexler 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.Pluperfect
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? :)Wexler
@Wexler yup, I think you've gotten the idea.Pluperfect
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 :)Wexler
@Wexler I didn't know anything changed in HTML5. I don't know the rationale, google leads me to: softwareengineering.stackexchange.com/questions/114156/…Pluperfect
B
18

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.

Basting answered 3/10, 2008 at 9:49 Comment(3)
XMLHttpRequest is a standard object in the JavaScript Object model.Saxony
@Jacob True, but different browsers have different JavaScript engines. Knowing which ones support PUT is still helpful.Griffey
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.Doty
D
11

YES, PUT, DELETE, HEAD etc HTTP methods are available in all modern browsers.

To be compliant with XMLHttpRequest Level 2 browsers must support these methods. To check which browsers support XMLHttpRequest Level 2 I recommend CanIUse:

http://caniuse.com/#feat=xhr2

Only Opera Mini is lacking support atm (juli '15), but Opera Mini lacks support for everything. :)

Doty answered 21/7, 2015 at 20:52 Comment(0)
I
8

Just to add - Safari 2 and earlier definitely didn't support PUT and DELETE. I get the impression 3 did, but I don't have it around to test anymore. Safari 4 definitely does support PUT and DELETE.

Inlaid answered 31/7, 2009 at 14:39 Comment(2)
Can anyone confirm which version of Safari gained support for PUT and DELETE?Dichroism
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...?Kellam

© 2022 - 2024 — McMap. All rights reserved.