Clarify "7.6.1 Navigating across documents" with respect to redirects and javascript: urls #314
Comments
|
I think that ends up working actually. Why would it be a network error? Should a redirect to a |
|
Hmm... let me try working through the steps again. From the perspective of the browser, queuing a task to run the script works differently because it's asynchronous... but I guess that's not a fundamental problem, just annoying. I guess it all works out except that the "If the origin of the source browsing context..." bit doesn't seem to account for the origin of the URL. |
|
Okay, so one problem would be that you navigate to a cross-origin URL, that redirects to a javascript URL, and that ends up executing in the current browsing context. That does indeed seem bad. Do you happen to have tested what browsers do today? |
|
Firefox and IE treat it as a network error. (IE gives "This page can’t be displayed...", Firefox gives "Corrupted Content Error".) Chrome aborts the navigation like a 204 response, regardless of the origin. |
|
How would you like to be acknowledged for reporting this? |
Redirect handling had the following issues that are now fixed: * /a navigating to /b which redirects to /a#test would not unload /a. * Headers set on the initial request were not preserved. * Redirects to javascript URLs would not result in an error. Fixes #314. * Location header was not parsed, and HTTP method was not changed where needed. Fixes #461. Another source of complexity was the "gone async" mechanism, which was used for two steps that could just as easily be factored out and had to be since they were run synchronously, but should not be. Changing that fixes #1446 which discusses the issue around unknown URL schemes in more detail.
Redirect handling had the following issues that are now fixed: * /a navigating to /b which redirects to /a#test would not unload /a. * Headers set on the initial request were not preserved. * Redirects to javascript URLs would not result in an error. Fixes #314. * Location header was not parsed, and HTTP method was not changed where needed. Fixes #461. Another source of complexity was the "gone async" mechanism, which was used for two steps that could just as easily be factored out and had to be since they were run synchronously, but should not be. Changing that fixes #1446 which discusses the issue around unknown URL schemes in more detail.
|
#1476 attempts to fix this. |
|
Just "Eli Friedman" is fine for an acknowledgement. |
Redirect handling had the following issues that are now fixed: * /a navigating to /b which redirects to /a#test would not unload /a. * Headers set on the initial request were not preserved. * Redirects to javascript URLs would not result in an error. Fixes whatwg#314. * Location header was not parsed, and HTTP method was not changed where needed. Fixes whatwg#461. Another source of complexity was the "gone async" mechanism, which was used for two steps that could just as easily be factored out and had to be since they were run synchronously, but should not be. Changing that fixes whatwg#1446 which discusses the issue around unknown URL schemes in more detail. multipart/x-mixed-replace no longer invokes the navigate algorithm halfway through, but instead invokes a dedicated algorithm.
I assume an HTTP redirect to a
javascript:URL should be treated as a network error, but the spec isn't really clear.The text was updated successfully, but these errors were encountered: