Doesn't auto choose XDR when making a cross-domain request
As a user of XHR, I would expect it to realize when the request will require CORS and choose to use XDR. This is mostly an issue on browsers like IE8 and IE9 where a CORS request requires the usage of XDomainRequest.
Thanks for reporting. I had that issue too. Over a year ago, when I was not involved with this project yet.
It's a wontfix kind of issue. It only (not mostly) affects really old IEs and if you are using xdr you have to be aware of a lot of limitations anyway. Eg. Can't set or read any headers.
Detecting if the request is cross domain is also not as easy as we'd want to. So it'd be a big chunk of code added for eberyone while only very few users have any doubts if they are crossing domain boundaries or not on a particular request.
Having said all that, I'm open to pull requests with a small and elegant solution I couldn't come up with ;) But it'd have to be complete. No half measures like handling only absolute urls or so. It should require no documentation.
Do you think something like https://github.com/videojs/video.js/blob/stable/src/js/xhr.js#L80-L84 is sufficient or are there some more usecase you can think off that won't be covered?
There's a better implementation than what I linked above in videojs/video.js#2633
That's still a lot of code for a library of the size of xhr anyway. We could distribute a separate library with that feature (assuming it doesn't exist already)
it's like with the qs package. We got requests to include that too, but it's better off as an optional thing you can add.
What about making it in an require('xhr/ie')? or require('xhr/cors')?
Yes, xhr/ie was considered before. This is yet another reason to finally do that.
Dropping all that ie-induced mess to a separate file would be such a relief.
Should this be closed?
I'm keeping it open because people don't search closed issues and this is a wontfix. I'll close it when we separate out old IE support