Chrome Version       : Version 59.0.3071.115 (Official Build) (64-bit)
URLs (if applicable) : n/a

This relates to: https://www.chromestatus.com/feature/5669008342777856

What steps will reproduce the problem?
(1) Navigate to a site, specifying http://user:pass@url/
(2) The site calls in subresources using relative URLs
(3) The site fails with the message "[Deprecation] Subresource requests whose URLs contain embedded credentials (e.g. `https://user:pass@host/`) are blocked. See https://www.chromestatus.com/feature/5669008342777856 for more details."

What is the expected result?

That the site should pass the username and password to the root URL, but that the relative URL calculations should strip out the username and password, and then be attempted anyway.

What happens instead?

The relative URL calculations include the username and password, and are therefore blocked.

Please provide any additional information below. Attach a screenshot if
possible.

This is causing sites on our intranet to fail. I would expect the username and password to be passed to the root URL, but not passed as part of the URL to the subresources (they might still be passed anyway, since the browser is sending a username and password to the domain, based on the root URL). The error is that the username and password are being treated as part of the sub-url even though they are not (they have been added to it during the relative URL calculation). I would still expect that any attempt to explicitly specify a username and password for a subresource would be blocked. The error (I believe) is to ADD a username and password to a relative URL for subresource (because the root URL has it), and then to block it. The browser should simply not add it (and use whatever default behaviour should apply, which may include passing the username and password anyway, or may not, depending on the situation).