XHR: Content-Type clobbered

[mnahkies]

---

Migrated from sinonjs/sinon#607
Originally created by @terinjokes on Thu, 20 Nov 2014 00:47:58 GMT

---

FakeXMLHttpRequest's send method currently clobbers the "Content-Type" header if set, by removing anything after the first ";" and forcibly appending ";charset=utf-8".

A real XHR object allows sending binary data via TypedArrays, ArrayBuffers, and Blobs. They also correctly form encode when sent with FormData values. As "Content-Type" might have application-specific behavior, blindingly clobbering them makes it difficult for developers to properly test the functionality.

[mnahkies]

---

Migrated from sinonjs/sinon#607 (comment)
Originally created by @mroderick on Tue, 20 Jan 2015 22:38:18 GMT

---

@terinjokes Thank you for reporting this.

FakeXMLHttpRequest's send method currently clobbers the "Content-Type" header if set, by removing anything after the first ";" and forcibly appending ";charset=utf-8".

Does this behaviour differ from what out-in-the-wild implementations of XMLHttpRequest? Do they all behave the same way?

A real XHR object allows sending binary data via TypedArrays, ArrayBuffers, and Blobs. They also correctly form encode when sent with FormData values. As "Content-Type" might have application-specific behavior, blindingly clobbering them makes it difficult for developers to properly test the functionality.

By real, do you mean IE10 and onwards? ;) IE9 and below doesn't have the FormData global

Do you have a proposal on how to improve FakeXMLHttpRequest to match developers' expectations, without getting to close to one specific real-world implementation?

[mnahkies]

---

Migrated from sinonjs/sinon#607 (comment)
Originally created by @dstillman on Fri, 14 Aug 2015 07:42:37 GMT

---

Not sure why this was marked as a feature request. This is clearly a bug, as @terinjokes's example shows. This requires ";charset=utf-8" to be appended to all tests that check the sent Content-Type header. (Even "text/plain" shouldn't have a charset appended if it wasn't set explicitly in the XHR.)

[mnahkies]

---

Migrated from sinonjs/sinon#607 (comment)
Originally created by @terinjokes on Wed, 21 Jan 2015 01:18:21 GMT

---

Does this behaviour differ from what out-in-the-wild implementations of XMLHttpRequest? Do they all behave the same way?

Just now I've tested the behavior of the following browsers, which were at my easy disposal: IE9, IE10, Chrome 39, Firefox 34, and Safari 8. I created a new XHR object, and set the "Content-Type" header:

var xhr = new XMLHttpRequest();
xhr.open('GET', 'http://httpbin.org/headers', true);
xhr.setRequestHeader('Content-Type', 'application/json');
xhr.onreadystatechange = function() {
  if (this.readyState==4 || this.readyState=="complete") {
    console.log(this.responseText);
  }
}
xhr.send()

In every case, the response body shows that the browser sent the request with "Content-Type" set to "application/json".

IE9 and below doesn't have the FormData global

That's fine. IE8 doesn't support Date.now, but that doesn't stop FakeTimers from detecting if it exists and faking it if it does.

[mnahkies]

---

Migrated from sinonjs/sinon#607 (comment)
Originally created by @moll on Fri, 11 Dec 2015 10:47:57 GMT

---

This is still the case as of Sinon v1.17.2.

[mnahkies]

---

Migrated from sinonjs/sinon#607 (comment)
Originally created by @moll on Sat, 30 May 2015 12:22:59 GMT

---

Just experienced this, too, when using Sinon and its XHR mock on Node. It also lacks the FormData global.

[fatso83]

Thank you!

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[moll]

I've not tried, but I assume this issue would've been closed earlier if it were fixed.