Handle backslashes when resolving relative URLs on data URLs.

This was causing an assertion failure. The problem was that the path parsing was treating backslash as a path separator/terminator, but the relative URL resolving code did not. The reason is that the relative URL code assumed the input is canonicalized already. This is true in normal cases but not when the relative URLs are non-standard like "data:".

BUG=456148

Review URL: https://codereview.chromium.org/934733005

Cr-Commit-Position: refs/heads/master@{#316732}

2 files changed, 12 insertions, 3 deletions

diff --git a/url/url_canon_relative.cc b/url/url_canon_relative.cc
index 9436245..06ca99c 100644
--- a/url/url_canon_relative.cc
+++ b/url/url_canon_relative.cc
@@ -170,8 +170,8 @@ bool DoIsRelativeURL(const char* base,
 // up until and including the last slash. There should be a slash in the
 // range, if not, nothing will be copied.
 //
-// The input is assumed to be canonical, so we search only for exact slashes
-// and not backslashes as well. We also know that it's ASCII.
+// For stardard URLs the input should be canonical, but when resolving relative
+// URLs on a non-standard base (like "data:") the input can be anything.
 void CopyToLastSlash(const char* spec,
                      int begin,
                      int end,
@@ -179,7 +179,7 @@ void CopyToLastSlash(const char* spec,
   // Find the last slash.
   int last_slash = -1;
   for (int i = end - 1; i >= begin; i--) {
-    if (spec[i] == '/') {
+    if (spec[i] == '/' || spec[i] == '\\') {
       last_slash = i;
       break;
     }
diff --git a/url/url_util_unittest.cc b/url/url_util_unittest.cc
index 17c1b0f..73ff93b8 100644
--- a/url/url_util_unittest.cc
+++ b/url/url_util_unittest.cc
@@ -273,6 +273,15 @@ TEST(URLUtilTest, TestResolveRelativeWithNonStandardBase) {
       // any URL scheme is we might break javascript: URLs by doing so...
     {"javascript:alert('foo#bar')", "#badfrag", true,
       "javascript:alert('foo#badfrag" },
+      // In this case, the backslashes will not be canonicalized because it's a
+      // non-standard URL, but they will be treated as a path separators,
+      // giving the base URL here a path of "\".
+      //
+      // The result here is somewhat arbitrary. One could argue it should be
+      // either "aaa://a\" or "aaa://a/" since the path is being replaced with
+      // the "current directory". But in the context of resolving on data URLs,
+      // adding the requested dot doesn't seem wrong either.
+    {"aaa://a\\", "aaa:.", true, "aaa://a\\." }
   };
 
   for (size_t i = 0; i < arraysize(resolve_non_standard_cases); i++) {