New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 788244 link

Starred by 1 user
Status: Assigned
Owner:
█ mgiuca@chromium.org
Long OOO (go/where-is-mgiuca)
Cc:
elawrence@chromium.org
benwells@chromium.org
ios-bugs@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , iOS , Chrome , Mac , Fuchsia
Pri: 3
Type: Bug



Sign in to add a comment

GURL constructor should remove illegal characters

Project Member Reported by mgiuca@chromium.org, Nov 24 2017 
Chrome Version: 64
OS: all

What steps will reproduce the problem?
(1) GURL url("alert:test \"message\"")
(2) LOG(INFO) << url.spec()

What is the expected result?
alert:test%20%22message%22

What happens instead?
alert:test "message"

Note that if you use mailto, it does behave as expected, because this is special-cased for mailto. Also, ExternalProtocolHandler includes code to escape the URL characters so an unescaped URL isn't sent to an external program. However, I think this logic should be pushed up to the GURL constructor, and not have to be handled in ExternalProtocolHandler.

These characters are simply illegal according to both RFC 3986 [1] and URL Standard [2], so no GURL should contain them without being escaped.

[1] https://www.ietf.org/rfc/rfc3986.txt
[2] https://url.spec.whatwg.org/

Comment 1 by mgiuca@chromium.org, May 30 2018 

I recently learned that this is no longer considered illegal by the URL Standard ([2] above) because the "alert" scheme is considered "non-special".

This is parsed as a "cannot-be-a-base-URL" in the URL Standard which means it is escaped using the C0 Control percent-encode set, not the path percent-encode set. I believe this is intentional, but I'm still trying to understand why, since it doesn't encode obviously-bad characters like ' ' and '"'.

It is not supposed to be special-cased for mailto (which is not treated specially by URL Standard).
►

Sign in to add a comment