To add to the error description, it also doesn't show any indication of the redirect in the Network tab of the Web Inspector, instead just showing that the loading of the original URL failed.

I can reproduce this with a test server. We end up getting an ERR_ABORTED message after the redirect is processed. I will dig further. 

The problem is here:
https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/child_process_security_policy_impl.cc&rcl=1461064657&l=582

The resource loader doesn't let the renderer request this URL for security reasons.

Should we error out sooner in the stack? Could URLRequestJob understand that this is an invalid redirect and show an error? Maybe UNSAFE_REDIRECT?

I don't actually know anything about ChildProcessSecurityPolicy. What's invalid about the redirect?

So, I think the idea is that we're fundamentally suspicious of the renderer process, so if it wants to access an invalid url (i.e. http:///) we kill the request.

"http:///" is an invalid url per GURL::is_invald. It seems like we shouldn't be blaming the renderer for this, though.

ccing a few more people for thoughts.

Oh. I missed that the URL is nonsense. I thought "https:///" was just a placeholder or something.

Having the URLRequest notice the URL is nonsense seems reasonable enough? And/or maybe ChildProcessSecurityPolicy should fail with something other than ERR_ABORTED so we end up surfacing a net error page. ERR_INVALID_URL?

Those suggestions sounds good. Seems like we should error out before we've learned the permanent redirect.

Oh, I see. So URLRequest actually does check this just fine. But we (reasonably) check ChildProcessSecurityPolicy before asking URLRequest to do anything. We could probably make URLRequest check the target URL *before* following the redirect, but that won't handle if the renderer decides to fetch an invalid URL right off the bat. I suspect Blink will stop you, but it seems the ResourceLoader should behave the same in both cases.

I think I'm leaning towards ChildProcessSecurityPolicy codepaths using a better error code, though it means we duplicate more code. The other option is for CanRequestURL to return *true* for URLs (kinda like net::URLRequest::IsHandledURL does, even though it's unreachable in all callers).

Hrm. So, here's what it looks like if I make ChildProcessSecurityPolicy fail with a different error. It's still slightly weird because we report the original URL, but maybe that's fine?

Incidentally, Firefox has the same behavior we currently do in aborting the commit without any visible error.

Deleted: invalid_redirect.png 30.7 KB

	invalid_redirect.png 30.7 KB View Download

Here's a possible fix.
https://codereview.chromium.org/1903133004/

Merging this into  issue #462272  which has more discussion.