[Webkit-unassigned] [Bug 125455] Synchronous CORS XHR fails when 302 redirect to same domain

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=125455





--- Comment #1 from James Cready <jcready at gmail.com>  2013-12-09 09:40:19 PST ---
The same request performed asynchronously will not throw an error and the XMLHttpRequest will complete successfully. The synchronous example works as expected in Firefox, but in all WebKit/Blink browsers (Chrome, Opera, etc.) the browser throws the same kind of Network Error.

I looked over the XHR and CORS spec, and the only semi-legitimate failure reason I could find was "If for some reason the user agent does not want to make the request terminate this algorithm and set the cross-origin request status to network error." (with similar wording in the redirect steps). Maybe WebKit/Blink browsers consider a synchronous 302 redirect suitable grounds for termination. That passage I quoted was intended to offer freedom to allow blocking blacklisted URLs or HTTPS-to-HTTP messages (neither of which apply here). The only other cases I know where sync vs. async makes a difference are 1) withCredentials is not allow in sync requests (but that raises an error at property-set-time, not at fetch-time) and also 2) Firefox (at least) disallows Blob, File, and ArrayBufferView objects as the arguments of a synchronous send(), to discourage sending large pieces of binary data synchronously. As far as I can tell there is no such documentation in the spec that allows this specific behavior: <http://www.w3.org/TR/cors/#redirect-steps>.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.