My http Accept headers are ignored. How do I set them?

[Martijn Vos]

Hi,

I'm trying to get data from a server that prefers to send XML. I don't think Angular supports that, so I want JSON.

As far as I understand, I should be able to set different headers, right? I'm doing what the docs say I should do,

but it doesn't seem to work. Here's what I do:

$http({

        method: "JSONP",

        params: params,

        url: "http://foo",

        headers: {

            'Accept':'application/json, text/javascript'

        },

        callback: 'JSON_CALLBACK',

        isArray: false

});

I also tried it with a $resource:

$resource('http://foo', {}, {

        fetch: {

            method:'JSONP',

            params: params,

            headers: {'Accept':'application/json, text/javascript', 'Content-Type':'application/json; charset=utf-8'},

            isArray:false,

            callback: 'JSON_CALLBACK'

        }

});

In desperation, I also tried this:

app.config(['$httpProvider', function($httpProvider){

        $httpProvider.defaults.headers.post['Accept'] = 'application/json, text/javascript';

        $httpProvider.defaults.headers.post['Content-Type'] = 'application/json; charset=utf-8';

        $httpProvider.defaults.headers.common['Accept'] = 'application/json, text/javascript';

        $httpProvider.defaults.headers.common['Content-Type'] = 'application/json; charset=utf-8';

}]);

None of this works. Angular keeps using Accept: */* in the request headers.

Am I doing something wrong, or is this simply not supported by Angular (despite the docs suggesting it is)?

I even have a JSFiddle: http://jsfiddle.net/fdZV7/1/

And a question on Stackoverflow: http://stackoverflow.com/questions/20266533/angular-custom-headers-are-ignored-by-http-and-resource-why

I've tried this with both 1.0.7 and 1.2.3.

Regards,

Martijn Vos.

[Michael Bielski]

The app I am working on has a single controller that is available to all of the other controllers (we call it our base controller) and that is where we put the '$http.defaults.headers' lines. This base controller is set on the HTML tag along with the ngApp. All other controllers are below it in scope, so the settings made in that controller cascade (inherit) down to the other controllers as children.

[Martijn Vos]

Thanks Michael, I will try that. I take it this means that using .config() or doing it in the http call itself didn't work for you either?

Still, http://docs.angularjs.org/api/ng.$http suggests that at least the $httpProvider.defaults.headers.common way should work. Is it supposed to work? Is this a bug in Angular or in the docs? Or am I misunderstanding something?

Regards,

Martijn.

On Tue, Dec 3, 2013 at 4:22 PM, Michael Bielski <michael...@yahoo.com> wrote:

The app I am working on has a single controller that is available to all of the other controllers (we call it our base controller) and that is where we put the '$http.defaults.headers' lines. This base controller is set on the HTML tag along with the ngApp. All other controllers are below it in scope, so the settings made in that controller cascade (inherit) down to the other controllers as children.

--
You received this message because you are subscribed to the Google Groups "AngularJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to angular+u...@googlegroups.com.
To post to this group, send email to ang...@googlegroups.com.
Visit this group at http://groups.google.com/group/angular.
For more options, visit https://groups.google.com/groups/opt_out.

[Martijn Vos]

I've got the answer to this problem, and for completeness sake, I'm adding it here. (You never know if someone stumbles across this mailing list googling for a similar issue.)

The answer is that I'm trying to do something that cannot possibly work. JSONP is an ugly hack that doesn't use XHR at all, but instead inserts <script> tags to get the json. This means it can only ever be a GET, and also that I can't control the headers.

More importantly, this means that the server needs to support JSONP, and if the server is meant to be used cross-site, then it's easier to just add the Access-Control-Allow-Origin header. So JSONP is an ugly hack that's obsolete.

This also means that the "JSON Vulnerability Protection" at docs.angularjs.org/api/ng.$http is meaningless when interpreting in terms of regular JSONP. It now sounds like an ugly server-side hack to prevent the exploitation of an ugly hack that the server explicitly supports. Better just let your server not support JSONP at all.

At least, that's what that paragraph sounds like to me. I now understand that it's not discussing regular JSONP, but some browser-side hack to extract data from a JSONP-like call on a non-JSONP-supporting server. I think that should be made more clear, As written, it lead me to believe that JSONP doesn't require server-side support, which lead me on the wild goose chance of my original question.

Regards,

Martijn Vos.

--

[Peter Ansell]

Hi Martijn,

I am working on a fix to support Angular JS and Chrome in my application and this issue came up.

Other javascript frameworks seem to put "type='application/javascript'" on the script element when creating it. Could Angular do that also to give a hint to the browser when making the request so it doesn't assume "Accept: */*" as the backup, as at least Chrome seems to do when using Angular with it? See the examples on Wikipedia for a basic idea of what I mean [1].

Cheers,

Peter

[1] https://en.wikipedia.org/wiki/JSONP#How_it_works