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:
http://www.packetizer.com/ws/rest.html
http://www.mail-archive.com/jmeter-user#jakarta.apache.org/msg13518.html
http://www.xml.com/cs/user/view/cs_msg/1098
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?
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).
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.
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".
_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
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.
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. :)
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.
Related
One question may not be valid or I have an answer but, is there a way to change browser document mode with Ajax success response from server? Basically server will add browser compatibility in response header based on segments of URL query string.
My suspect here is, it may not possible as this way security become weak but better to get expert opinion. :)
The browser compatibility mode (quirks mode, etc.) is based on the main HTML document, namely the doctype. Since an AJAX request can do nothing to alter this, no, you cannot change the mode dynamically via an AJAX request.
However, quirks mode is a fallback. It's not something you design for. You should not be relying on specific browser compatibility features.
I can see this site.com/assets/css/screen.css?954d46d92760d5bf200649149cf28ab453c16e2bwhat is this random alpha numeric vales question mark ? i don't think it's taking some value to use or what is it about ?
edit : also on refreshing page the alpha-numeric value is same.
It is for preventing the browser from caching the CSS. When a CSS is requested by some browsers, specifically Internet Explorer, the browser will have a local copy of the CSS.
When a request is given to a server as:
site.com/assets/css/screen.css?skdjhfk
site.com/assets/css/screen.css?5sd4f65
site.com/assets/css/screen.css?w4rtwgf
site.com/assets/css/screen.css?helloWd
The server at site.com sees only:
site.com/assets/css/screen.css
And gives the latest version. But when the HTML page is requesting the browser to fetch the CSS as: site.com/assets/css/screen.css, for the first time, it fetches from the site.com server. There are many possibilities that the content might be changed in the meantime when the next request is sent. So programmers generally add a ?and-some-random-text, which is called Query String. This will force the browser to get a new copy from the server.
Some more detailed explanation:
It is a well known problem that IE caches too much of html, even when
giving a Cache-Control: no-cache or Last-Modified header to
everypage.
This behaiviour is really troubling when working with querystrings to
get dynamic information, as IE considers it to be the same page
(i.e.: http://example.com/?id=10) and serves the cached version.
I've solved it adding either a random number or a timestring to the
querystring (as others have done) like this
http://example.com/?id=10&t=2009-08-06_13:12:56 that I just ignore
serverside.
Is there a better option? Is there another, cleaner way to acomplish
this? I'm aware that POST isn't cached, but it is semanticaly
correct to use GET here.
Reference: Random Querystring to avoid IE caching
I am able to tamper post request parameter with Tamper Data in firefox i.e when i make
post request and i get the popup in firefox to change POST request parameters but in case
of GET request, i get the popup but there is no way to change the request parameter.
So question is Can't we change the request parameter thru Tamper Data/Fiddler?(Yes i agree
we can change it from browser address bar but that will be applicable once first request has been firect but i want to tamper some data in the very first Get Request. So i want to change GET request paramater with Tamer Data/Fiddler.Is it possible?)
You can't do that using Tamper-Data. You could use a more advanced standalone-tool, like Web Scarab which will let you intercept and edit all portions of your web-requests.
Using fiddler, in conjunction with FiddlerScript is also an alternative.
You can easily use Fiddler to tamper with any aspect of a request or response. You can do this using FiddlerScript or manually using breakpoints. To change traffic manually using breakpoints, watch this tutorial video: http://www.youtube.com/watch?v=8bo5kXMAcV0&list=PLvmaC-XMqeBbw72l2G7FG7CntDTErjbHc
You can also use: Live http header addon. Hope it help.
I am going to describe my specific case below, but this might be useful to a number of web-mashups.
My web application POSTs to Twitter by filling a form and then submitting it (via javascript). The target of the form is set to an iframe which has an onload trigger. When the onload trigger is called the application knows that the POST was completed.
This used to work fine until Chrome version 11, which now respects the X-Frame-Options=SAMEORIGIN sent by Twitter in the POST response. The POST goes through, but the iframe's onload is not called anymore.
It still works in Firefox 4, but I suppose that's a bug that will eventually get fixed.
Is there any other way to know the status of the POST? I understand that knowing the contents of the POST response would violate the security policy, but I am not interested in the contents. I would just like the app to be notified when the POST is completed.
If you just need to know when the POST was submitted, and not necessarily whether it succeeded or not, you could poll the iframe's contentWindow and contentWindow.document on an interval. When you can no longer access one of those objects, or when the document has an empty body, that means that the iframe has loaded a page with X-Frame-Options restrictions, which likely means that the submission went through. It's hacky, but it looks like it will work for this purpose. (You'll probably have to go through a few combinations to figure out what the contents of restricted iframes look like in your target browsers.)
You can do it by getting the headers of the page. In php it will be looks like,
$url = 'http://www.google.com';
print_r(get_headers($url));
if the server doesn't send the content-type header, how does the browser tell which kind of content he got? For example, when I get the SO logo with chrome, the image is intact, though the server doesn't state its extension (at least, explicitly)
Most browsers do content sniffing if the type is not explicitly declared in the HTTP header. They are looking for specific signatures they know and thereby guess the media type.
See the section Determining the type of a new resource in a browsing context in the HTML 5 specification or this Draft of Content-Type Processing Model for some examples.
It can guess the content type by inspecting the file.
For example, PNG have "PNG" among the first 4 bytes.
Different browsers handle it in different ways.
Internet Explorer guesses based on content. In fact has often ignored Content-Type headers, instead using its own guess.
Some browsers also take the extension into account.