Skip to content

Commit

Permalink
Handle backslashes when resolving relative URLs on data URLs.
Browse files Browse the repository at this point in the history
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}
  • Loading branch information
brettw authored and Commit bot committed Feb 18, 2015
1 parent 655c22f commit e66ce87
Show file tree
Hide file tree
Showing 2 changed files with 12 additions and 3 deletions.
6 changes: 3 additions & 3 deletions url/url_canon_relative.cc
Original file line number Diff line number Diff line change
Expand Up @@ -170,16 +170,16 @@ 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,
CanonOutput* output) {
// 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;
}
Expand Down
9 changes: 9 additions & 0 deletions url/url_util_unittest.cc
Original file line number Diff line number Diff line change
Expand Up @@ -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++) {
Expand Down

0 comments on commit e66ce87

Please sign in to comment.