domenic
commented
3 years ago Couldn't Chromium change their URL parsing logic to match the spec, but add some URL-encoding logic on the output of the parser before calling into the OS?
Open TimothyGu opened 3 years ago
domenic
commented
3 years ago Couldn't Chromium change their URL parsing logic to match the spec, but add some URL-encoding logic on the output of the parser before calling into the OS?
annevk
commented
3 years ago It can indeed be separated from parsing, though it would still be good to define as all browsers have to do this presumably. (Probably in HTML as that would do the dispatching.)
Is this not a security issue for other schemes that could be dispatched?
Currently per spec, mailto: paths are treated the same way as other "opaque" URLs. That is, weird characters in the "path" part of a mailto URL are kept verbatim. However, Chromium's implementation experience in their bug 711020 was that this could expose the surrounding operating system and other apps to arbitrary characters, and opted instead to percent-encode some characters. The specific encoding set is described in url/url_canon_mailtourl.cc, and is equivalent to
Though introducing new scheme-specific logic is generally frowned upon, I wonder if other implementors may have the appetite for introducing something similar in the spec. On the Chromium side, it would understandably be quite difficult to revert this behavior (a security patch) just for interop.