Bugzilla – Bug 14773
Investigate if synchronous XHR in window context should not support new XHR responseTypes
Last modified: 2012-10-11 11:15:31 UTC
and WebApps mailing list
So should this also happen for all cross-origin requests that do not use withCredentials as sicking seemed to suggest on the mailing list? Is that what is being implemented?
I'm not sure I understand the question. Here is what I proposed a few days ago and what I still think should be specified:
That is already defined. The question is whether invoking open() with a cross-origin URL should throw if async is false.
cross-origin XHR has been supported for ages.
I don't think we can break it easily.
Oh, crap, I worded that wrong. Yes, I think we should make it throw. We should be able to get data on if that is web compatible.
(In reply to comment #5)
> Oh, crap, I worded that wrong. Yes, I think we should make it throw. We should
> be able to get data on if that is web compatible.
Throw always when cross-origin sync XHR is used?
I would be surprised if that doesn't break some websites.
Use of CORS is still fairly new. And use of synchronous CORS requests doesn't work at all cross browser since IE doesn't have a sync mode for XDR. So I think there's a good chance that it would work.
Jonas, Olli, what is your current opinion on this? I can make the specification say this, but if it's not going to be implemented, there's not much point :-)
And looks like https://bugs.webkit.org/show_bug.cgi?id=72154 also.
Or do you mean only the CORS part?
That is not what this bug is about.
I assume it might be too late to change CORS handling.
Thank you Olli!
Since the anonymous flag is new I made open() throw for that. The only scenario where you can still do sync requests is same-origin requests and cross-origin requests where you have not set timeout/withCredentials/...
Apart from the new thing about the anonymous flag I think the specification matches Gecko now.