Hrm...Actually, if we properly escape-encode %'s in file names, we could probably just fail in this case.  Don't think that's worth the effort, though.

This is a consequence of FtpNetworkTransaction::GetRequestPathForFtpCommand() calling UnescapeURLComponent() and not tge canonicalization being done internal to GURL right?

Correct.  Simple fix is to just not unescape path separators.  FtpDirectoryListingResponseDelegate does the same thing, though haven't dug into just what the implications are there yet.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0a2a0e15f6741225fbce75cfc4fa07db0a00190d

commit 0a2a0e15f6741225fbce75cfc4fa07db0a00190d
Author: mmenke <mmenke@chromium.org>
Date: Wed Mar 23 23:06:49 2016

Fix handling of escaped slashes ("%2f") in FTP paths.

Chrome was unescaping them before sending requests to the server, which
would map "ftp://foo/bar%2f..%2fblah" to requesting path "/bar/../blah"
from the FTP server, which is weird.  It now requests the file named
"bar%2f..%2fblah" instead.  Worth noting that GURL considers this to be
a separate url from ftp://foo/blah, so its best to be consistent with
that behavior.  Also, when Chrome sees an FTP file with %'s in its name,
it unescapes them, so Chrome would never generate a URL with "%2f" in
it, but they could still come from external sources.

This CL also fixes the title of directory listings of paths with "%2f"
in them - ftp://foo/bar%2f/baz will now say "Index of /bar%2f/" instead
of "Index of /bar//".

BUG= 597056 

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

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

[modify] https://crrev.com/0a2a0e15f6741225fbce75cfc4fa07db0a00190d/content/child/ftp_directory_listing_response_delegate.cc
[modify] https://crrev.com/0a2a0e15f6741225fbce75cfc4fa07db0a00190d/net/ftp/ftp_network_transaction.cc
[modify] https://crrev.com/0a2a0e15f6741225fbce75cfc4fa07db0a00190d/net/ftp/ftp_network_transaction_unittest.cc