Open denislins opened 9 years ago
I managed to solve the problem with a hacky fix:
I added the highlighted line, and it works now. It works because request.url
is a string, but an "object string", apparently. When the request is strip
ed, it eliminates all functions and objects from the request object. Because typeof request.url
is returning object
, it eliminates the key from the returned object.
I know that this check fails if we create a string by instantiating the class string, as in new String('test')
. Knowing that, I think that the request url should always be present, so the fix I made above seems to be correct.
What do you guys think?
What version of XDomain are you using?
On Tuesday, May 12, 2015, Denis Lins notifications@github.com wrote:
I managed to solve the problem with a hacky fix:
[image: image] https://cloud.githubusercontent.com/assets/832802/7566662/8591fc76-f7ce-11e4-8ceb-7b37f095ef2f.png
I added the highlighted line, and it works now. Of course, this isn't a solution, it's just more information about the problem. Could this a bug in the library?
— Reply to this email directly or view it on GitHub https://github.com/jpillora/xdomain/issues/149#issuecomment-100920720.
Latest, 0.7.3
Ah I understand, strip
wasn't copying over the request.url
, are you sure it was "object string"
not "[object String]"
?
request.url
is set in two places:
xhr = new XMLHttpRequest(); xhr.open("GET", "http://this.is.the.request.url/");
before
hook and modify it thereIs your code changing request.url
to an object?
Yes, I meant exactly that. To be even clearer, request.url
in this context is an instance of the class String, and request.url instanceof String
returns true
. This is why typeof request.url
returns object
.
I double checked my code, and as far as I could see it doesn't change the request URL, it just requests it. But I'm using AngularJS, so I guess it could manipulate the url string after I pass it.
A simple solution would be to add another check in the strip()
function, something like || value instanceof String
.
Hi @denislins sorry for the delay, happy to fix this though I can't replicate it. Does it only happen in the modern.ie VM? or all IE9s? Could you make a demo of this or create a gist of a simple index.html
where this occurs?
I had the same issue in IE9 (local install). v9.0.8112.16421. Adding the highlighted line from above fixed it for me. Strangely, I then removed that line, cleared cache and closed/reopened the browser and it continues to work. I didn't change anything else. Looking in dev tools, I can see that it's loading the most updated version of xdomain.js and that the line of code is no longer there. I'm gonna reboot and see if it stops working. I'll report back.
After rebooting it still works. I'm was wondering if maybe it was a charset issue or something (I've seen this before). So I tried copying the original file and it still works. Very strange.
Hey guys. I'm adding support for IE9 in my Angular app, and I'm using xdomain to help me querying the API, which is in a different server (and address).
I managed to get it working for a while, but now it has stopped and I just can't get it working again. This is the debug output from the slave:
Looking at the debug info, it looks like the request URL is not being sent. I confirmed this by hacking into the library's code and outputing the request object.
The annoying part is that it only happens in certain requests, and I wasn't able to identify the error pattern. It happens in my login page, and in a simple resource request, for instance. One is a POST request, with a body and stuff, while the other is a dead simple GET request, like
/stores/1
.If it helps, I'm using
modern.ie
's VM of IE9 on Windows 7, with the frontend and backend servers running in my mac machine (host machine). I'm using bridged network, and using my network IP instead of localhost (e.g. 192.168.3.110 instead of 127.0.0.1).This is the code that runs first-thing in the front-end app:
And this is the code that lives in my backend server:
I tried googling this before I post it here, so I'm sorry if this a duplicate. So, have you ever seen this before? Could this be a bug?