nise
nise copied to clipboard
XHR: Content-Type clobbered
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 TypedArray
s, ArrayBuffer
s, and Blob
s. 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.
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?
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.)
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.
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.
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.
Thank you!
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.
I've not tried, but I assume this issue would've been closed earlier if it were fixed.