X-Requested-With causes CORS requests to trigger preflight checks which complicates things for many simple things.
The header is not very useful except for certain edge-cases (e.g. I think that Rails uses the header to switch full page and page fragment rendering).
better then completely dropping the header would be to send it only for same-domain requests. this will require moving the header from the default header config into a filter or something similar.
unsurprisingly this is exactly what jquery does: https://github.com/jquery/jquery/blob/81c7b83d645d2f151e9e40f9f98cc4b70e81a62a/src/ajax/xhr.js#L84
I agree, I was having the same problem and I had to change server headers.
I had a chat with Misko about this. It might be easier to completely remove this header and let people add it on demand. Otherwise we would need to keep two sets of default headers - headers.common and headers.commonCrossDomain, which would add more complexity and documentation.
Let's just remove it as it makes the documentation and expectations easier to manage. Adding the header to the defaults is trivial.
For the record, here is the snippet to reenable the previous behavior that Igor mentioned:
$httpProvider.defaults.headers.common['X-Requested-With'] = 'XMLHttpRequest';
Since a few days, with this header all CORS requests to Google APIs fail, causing an "Origin [...] is not allowed by Access-Control-Allow-Origin" error.
You can see the error in Vojta's Task Manager : http://task-manager-angular.appspot.com/app/index.html
It it does no longer work, as any AngularJS application making $http requests to Google APIs.
+1 to only sending for same-domain requests. -1 to removing it.
I realize that this header can be added back and that it's just being removed by default, but there are some good reasons everyone might want to use it: for some basic CSRF protection: https://nealpoole.com/blog/2010/11/preventing-csrf-attacks-with-ajax-and-http-headers/#comment-1675
Are you using something different for CSRF protection?
Yes, Angular provides X-XSRF-TOKEN specifically for that purpose (see http://docs.angularjs.org/api/ng.$http). It will require some collaboration from your server, but it is a more robust solution.
I just updated to version 1.1.4 and my Angular app does not work with my Rails backend anymore.
There are more people with this issue as you can see on this stackoverflow question.
Dropping this header is really the right thing to do?
I added some more background on the Rails interaction in this comment.
seems removing this has caused some problems. the docs should at least state that this was removed as the default. only way i found this was the cause of my api requests failing is that i examined the request in detail, with old and updated ngcore code.
Nette Framework also uses this header.
@eddiemonge I agree with you. I spent hours trying to debug what happened to the httpProvider because it was not working. Turns out they removed the default http headers and I had to search the change log to see why they removed it. Please update the docs!
Django also uses this in it's request.is_ajax() method. IMO the better solution is what jquery does. Yes, it is simple to add that single line but identifying the problem as 'X-Requested-With' may not be so easy for some people. I personally found it pretty easy, but I enjoy tracing through my (and everyone elses) code with the debugger ;)
this is quite weird for me, as many cases Backend, use is_xhr, or is_ajax etc to check whether user is made requests from browser with ajax, or not.
Symfony2 2.3.x also can't detect if the request is XHR without this header
Fortunately, anyone is free to add this header to the default headers sent with every request 😄