New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
jaswant-ghuraiya opened this Issue Mar 13, 2013 · 28 comments

Comments

Projects
None yet
@jaswant-ghuraiya

jaswant-ghuraiya commented Mar 13, 2013

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

This comment has been minimized.

Show comment
Hide comment
@kdekooter

kdekooter Apr 9, 2013

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

kdekooter commented Apr 9, 2013

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

@michelsalib

This comment has been minimized.

Show comment
Hide comment
@michelsalib

michelsalib May 2, 2013

Contributor

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

Contributor

michelsalib commented May 2, 2013

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

@davejamesmiller

This comment has been minimized.

Show comment
Hide comment
@davejamesmiller

davejamesmiller Jul 20, 2013

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

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

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

davejamesmiller commented Jul 20, 2013

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

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

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

@arciisine

This comment has been minimized.

Show comment
Hide comment
@arciisine

arciisine Aug 8, 2013

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.

arciisine commented Aug 8, 2013

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

This comment has been minimized.

Show comment
Hide comment
@david-driscoll

david-driscoll Aug 13, 2013

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.

david-driscoll commented Aug 13, 2013

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

This comment has been minimized.

Show comment
Hide comment
@Grummle

Grummle Aug 14, 2013

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?

Grummle commented Aug 14, 2013

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

This comment has been minimized.

Show comment
Hide comment
@mikeobrien

mikeobrien commented Aug 14, 2013

👍

2 similar comments
@mariussoutier

This comment has been minimized.

Show comment
Hide comment
@mariussoutier

mariussoutier commented Aug 22, 2013

+1

@muratcorlu

This comment has been minimized.

Show comment
Hide comment
@muratcorlu

muratcorlu commented Sep 5, 2013

+1

@muratcorlu

This comment has been minimized.

Show comment
Hide comment
@muratcorlu

muratcorlu Sep 5, 2013

xhr.send(post || null);

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

muratcorlu commented Sep 5, 2013

xhr.send(post || null);

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

@eranation

This comment has been minimized.

Show comment
Hide comment
@eranation

eranation commented Sep 16, 2013

👍

1 similar comment
@srawlins

This comment has been minimized.

Show comment
Hide comment
@srawlins

srawlins Sep 17, 2013

Contributor

+1

Contributor

srawlins commented Sep 17, 2013

+1

@kdekooter

This comment has been minimized.

Show comment
Hide comment
@kdekooter

kdekooter Sep 17, 2013

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

kdekooter commented Sep 17, 2013

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

@muratcorlu

This comment has been minimized.

Show comment
Hide comment
@muratcorlu

muratcorlu Sep 17, 2013

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.

muratcorlu commented Sep 17, 2013

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

This comment has been minimized.

Show comment
Hide comment
@kdekooter

kdekooter Sep 17, 2013

Excellent!

kdekooter commented Sep 17, 2013

Excellent!

@ejain

This comment has been minimized.

Show comment
Hide comment
@ejain

ejain Sep 21, 2013

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

ejain commented Sep 21, 2013

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

This comment has been minimized.

Show comment
Hide comment
@mariussoutier

mariussoutier Sep 22, 2013

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

mariussoutier commented Sep 22, 2013

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

@ejain

This comment has been minimized.

Show comment
Hide comment
@ejain

ejain Sep 22, 2013

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

ejain commented Sep 22, 2013

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

@jroper

This comment has been minimized.

Show comment
Hide comment
@jroper

jroper Sep 23, 2013

Contributor

PR that tests and fixes this:

#4021

Contributor

jroper commented Sep 23, 2013

PR that tests and fixes this:

#4021

btford added a commit to btford/angular.js that referenced this issue Oct 1, 2013

fix($httpBackend): don't send empty string bodies
The XMLHttpRequest.send spec defines different semantics for `null`
than for an empty String: an empty String should be sent with a
`Content-Type` of `text/plain`, whereas null should have no
`Content-Type` header set.

Closes angular#2149

@btford btford closed this in 0d0330a Oct 1, 2013

@johann-sonntagbauer

This comment has been minimized.

Show comment
Hide comment
@johann-sonntagbauer

johann-sonntagbauer Jan 16, 2014

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

johann-sonntagbauer commented Jan 16, 2014

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

jamesdaily added a commit to jamesdaily/angular.js that referenced this issue Jan 27, 2014

fix($httpBackend): don't send empty string bodies
The `XMLHttpRequest.send` spec defines different semantics for `null`
than for an empty String: an empty String should be sent with a
`Content-Type` of `text/plain`, whereas `null` should have no
`Content-Type` header set.

Closes angular#2149

jamesdaily added a commit to jamesdaily/angular.js that referenced this issue Jan 27, 2014

fix($httpBackend): don't send empty string bodies
The `XMLHttpRequest.send` spec defines different semantics for `null`
than for an empty String: an empty String should be sent with a
`Content-Type` of `text/plain`, whereas `null` should have no
`Content-Type` header set.

Closes angular#2149
@brutto

This comment has been minimized.

Show comment
Hide comment
@brutto

brutto Jul 7, 2015

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

brutto commented Jul 7, 2015

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

@Ravireddy1076

This comment has been minimized.

Show comment
Hide comment
@Ravireddy1076

Ravireddy1076 Sep 4, 2015

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

Ravireddy1076 commented Sep 4, 2015

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

This comment has been minimized.

Show comment
Hide comment
@BespalovAV

BespalovAV commented Sep 5, 2015

@idf

This comment has been minimized.

Show comment
Hide comment
@idf

idf commented Sep 8, 2015

+1

@aegrey

This comment has been minimized.

Show comment
Hide comment
@aegrey

aegrey commented Oct 27, 2015

+1

@gkalpak

This comment has been minimized.

Show comment
Hide comment
@gkalpak

gkalpak Oct 28, 2015

Member

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.

Member

gkalpak commented Oct 28, 2015

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

This comment has been minimized.

Show comment
Hide comment
@vniche

vniche Dec 18, 2015

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.

vniche commented Dec 18, 2015

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

This comment has been minimized.

Show comment
Hide comment
@gkalpak

gkalpak Dec 21, 2015

Member

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

Member

gkalpak commented Dec 21, 2015

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment