commit d4cc4979350da590de902a8da63154c5d5325592
author Matt Menke <mmenke@chromium.org> Mon May 06 19:36:47 2019
committer Commit Bot <commit-bot@chromium.org> Mon May 06 19:36:47 2019
tree 1a87c99f33c1404516d87d3d26df71d1ba21804c
parent 5d10441ea9dd9737b52b361969518a276a3761c1

Switch a pair of devtools classes over to UnescapeBinaryURLComponent().

They were using UnescapeURLComponent(), which leaves certain characters
that are unsafe to display to the user escaped for display, which
doesn't make sense in the context of creating a URL for internal use.

The two modified calls were of the form GURL(UnescapeURLComponent())
before, so the differences shouldn't have mattered before, anyways.

UnescapeBinaryURLComponent() unescapes all escaped characters passed
to it, including %00. GURL's constructor, however, will then re-escaped
such characters, so this CL shouldn't affect behavior - with one
exception. GURL removes terminal characters it doesn't like, so
GURL(UnescapeBinaryURLComponent("http://foo/%01")) will become
"http://foo/". GURL(UnescapeBinaryURLComponent("http://foo/%01a")),
on the other hand, will remain "http://foo/%01a". This changed behavior
seems not to matter in this context, since the "%" itself should be
escaped when passed through these APIs, anyways. If this is a problem,
though, perhaps we should re-visit GURL's behavior, or implement some
one-off solution for this particular use case.

This CL is part of a project to cleaning up uses of
UnescapeURLComponent(), as it's been used for wildly disparate
purposes, and much of its logic is only suitable for cases where
we want to format a URL for safe display to the user. We want
to make it leave more weird characters escaped, but need to
eliminate usage of it in other contexts before we can do that.

UnescapeBinaryURLComponent() unconditionally unescapes all escaped
characters, and should be used instead in most cases, particulars where
URL_SPECIAL_CHARS_EXCEPT_PATH_SEPARATORS is in use. The primary cases
where it shouldn't be used (without additional checks), are cases where
unescaping path separators or funky characters (like %01) is a problem.
In those places, we should generally fail, instead of partially
unescaping a URL.

Change-Id: I2b95ffd0fd42c26ffb6f84773d8e94457660a3ac
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1594822
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
Commit-Queue: Matt Menke <mmenke@chromium.org>
Cr-Commit-Position: refs/heads/master@{#656914}