nise icon indicating copy to clipboard operation
nise copied to clipboard

XHR: Content-Type clobbered

Open mnahkies opened this issue 6 years ago • 8 comments


Migrated from https://github.com/sinonjs/sinon/issues/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 avatar Feb 12 '18 09:02 mnahkies


Migrated from https://github.com/sinonjs/sinon/issues/607#issuecomment-70749165 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 avatar Feb 12 '18 09:02 mnahkies


Migrated from https://github.com/sinonjs/sinon/issues/607#issuecomment-131007934 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 avatar Feb 12 '18 09:02 mnahkies


Migrated from https://github.com/sinonjs/sinon/issues/607#issuecomment-70767984 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 avatar Feb 12 '18 09:02 mnahkies


Migrated from https://github.com/sinonjs/sinon/issues/607#issuecomment-163907014 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 avatar Feb 12 '18 09:02 mnahkies


Migrated from https://github.com/sinonjs/sinon/issues/607#issuecomment-107033149 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.

mnahkies avatar Feb 12 '18 09:02 mnahkies

Thank you!

fatso83 avatar Feb 12 '18 11:02 fatso83

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.

stale[bot] avatar Apr 13 '18 11:04 stale[bot]

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

moll avatar Apr 13 '18 18:04 moll