Unable to set content-type request header for delete method.

[jaswant-ghuraiya]

I tried as below approach-

$httpProvider.defaults.headers["delete"] = {'Content-Type': 'application/json;charset=utf-8'};

My request doesn't have any body. And the actual request header is always taking "content-type" as "text/plain".

[kdekooter]

Having similar issues with put and post. Content-Type of the request is always set as application/xml

[michelsalib]

I am having the exact same issue. Impossible to change the Content-Type of a DELETE request.

[d13r]

I think if there is no request body (data parameter) the Content-Type header is deliberately removed:

angular.js/src/ng/http.js

Line 638 in b99d064

if (lowercase(header) === 'content-type') {

The code above worked for me when the data parameter is set.

[arciisine]

Running into the same issue as well. When working with a framework that expects content-type for all HTTP verbs, this is an issue.

Also, since neither GET and DELETE support content, I would expect them both to work the same way.

[david-driscoll]

I wonder if there is a specific reason the content-type is stripped? JQuery doesn't make that assumption for example. This was a frustrating little feature to find out.

[Grummle]

Is DELETE supposed to have Content-Type always set?

When using $http.delete(url) we've been seeing the following:

Chrome 28 (and some lower):

Content-Type:application/xml

FireFox 22:
Content-Type text/plain; charset=utf-8

IE 10:
Content-Type text/plain;charset=UTF-8

The Content-Type header throws our conneg for a loop. Perviously using:

$.ajax({url:url,type:'DELETE'});

We didn't have this issue and no 'Content-Type' was specified.

Accept:*/*
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:no-cache
Connection:keep-alive
Host:localhost
Pragma:no-cache
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.95 Safari/537.36
X-Requested-With:XMLHttpRequest

The issue seems to be with this piece of code in $httpBackend:

      xhr.send(post || '');

If you simply change that to something like:

if(post) xhr.send(post);
else xhr.send();

Then all is well with the world. I've tested it on the 1.1.5 tag and all the tests pass in Mac Chrome/Safari include e2e, but I haven't a clue how to write tests for it or I'd submit a pull request. Currently we are forced to run a modifed version of angular, but we'd like to run the google cdn version. Any suggestions?

[mikeobrien]

👍

[mariussoutier]

+1

[muratcorlu]

+1

[muratcorlu]

xhr.send(post || null);

works too. I hope somebody merges this fix to master.

[eranation]

👍

[srawlins]

+1

[kdekooter]

OK. It's been 5 months now. It would be nice to get some kind of feedback from one of the core committers.

[muratcorlu]

My pull request about this issue has been included in milestone 1.2.0-rc3: #3897 I hope, it will be merged in next release.

[kdekooter]

Excellent!

[ejain]

Just ran into this issue with 1.0.8; hope the fix will be included in a 1.0.9 release! Until then, it appears that AngularJS won't work with the current version of the popular Play framework (2.2)...

[mariussoutier]

@ejain Yes it does, just add parse.empty to your Actions.

[ejain]

@mariussoutier Thanks for the workaround; unfortunately there does not appear to be an equivalent of parse.empty in Play's Java API.

[jroper]

PR that tests and fixes this:

#4021

[johann-sonntagbauer]

one question about the changes concerning

xhr.send(post || null);

and

forEach(headers, function(value, key) {
    if (isDefined(value)) {
        xhr.setRequestHeader(key, value);
    }
});

That makes problems when an empty POST request is made in an CORS enabled environment.

Because CORS will interpret the Content-Type header and with that changes there is absolutely no way to define an Content-Type header for an empty POST.

Problem reproduced with angular 1.2.9

[brutto]

Still can not set content type with $resource on GET (empty POST have not check yet). =\

[Ravireddy1076]

I just migrated from 1.2 to 1.4. It seems the issue is back. Default Content-type set to text/* for Delete request.

[BespalovAV]

[idf]

+1

[aegrey]

+1

[gkalpak]

If you are still experiencing buggy behaviour, I suggest opening a new issue (providing the necessary info - preferrably along with a live demo, using CodePen, Plnkr etc).

It's hard to interpret +1s on an issue that (is supposed to) have been fixed.

[vniche]

I'm having the same issue, tried to reproduce it in a Plunk (v1.4.8), but no success, and locally (also v1.4.8), i'm facing it, don't know if it makes any difference, but my request is to a rest application in a local hosted VirtualBox VM.

Punkler Request info:

POST /posts HTTP/1.1
Host: jsonplaceholder.typicode.com
Connection: keep-alive
Content-Length: 46
Accept: application/json, text/plain, */*
Origin: http://run.plnkr.co
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36
Content-Type: application/json;charset=UTF-8
Referer: http://run.plnkr.co/eLPXRF5pvhFsXNKK/
Accept-Encoding: gzip, deflate
Accept-Language: pt-BR,pt;q=0.8,en-US;q=0.6,en;q=0.4

My local Request info:

OPTIONS /zabbix/api_jsonrpc.php HTTP/1.1
Host: 192.168.22.114
Connection: keep-alive
Access-Control-Request-Method: POST
Origin: http://localhost:8888
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36
Access-Control-Request-Headers: accept, content-type
Accept: */*
Referer: http://localhost:8888/
Accept-Encoding: gzip, deflate, sdch
Accept-Language: pt-BR,pt;q=0.8,en-US;q=0.6,en;q=0.4

I'm using the same method locally, a lot Headers are different, i don't know why.

[gkalpak]

@vniche: This seems to be a different issue (and one not related to Angular).
Since I see that there is an OPTIONS request, I assume this is CORS related. The browser probably doesn't send a Content-Type header with the "preflight" request, since no data is sent.

In any case, this is not something caused or affected by Angular.