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

Issue 895041 link

Starred by 3 users

Issue metadata

Status: ExternalDependency
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , iOS , Chrome , Mac , Fuchsia
Pri: 3
Type: Bug



Sign in to add a comment

Remove support for the gopher scheme from the URL parsers in the codebase.

Project Member Reported by nasko@chromium.org, Oct 13

Issue description

gopher is not a supported protocol in Chromium. The URL parsing code however still supports such URLs, which leads to subtle bugs. We should remove all support for the gopher scheme in the code.

 
Cc: mkwst@chromium.org
Owner: nasko@chromium.org
Status: Assigned (was: Untriaged)
Apparently, mkwst@ tried that before :) https://chromium-review.googlesource.com/c/chromium/src/+/612983. So let's try it again!
Owner: ----
Status: ExternalDependency (was: Assigned)
Uncovering more of the history behind why we haven't removed it yet, there is a spec bug filed for its removal - https://github.com/whatwg/url/issues/342. However, the issue has not been resolved and removing gopher as a scheme from the code will result in spec violation.

Since I don't have many cycles to chase spec change at this time, I'm unassigning myself from the bug.
Components: Internals>Network Internals
Labels: OS-Android OS-Fuchsia OS-iOS
nasko: Can you be more specific about the subtle bugs?
 Issue 894426  is an example where a simple usage of gopher: caused renderer CHECK. It is due to us making changes in how origins are implemented internally to better be able to track where opaque origins have come from. This particular bug was caused due to multiple URL parsers disagreeing (KURL, GURL), since one had a default port assigned to gopher: and the other one didn't.

Yes, it isn't super often that we do those types of changes, but when we do, the chances of bugs/regressions are non-trivial and very hard to discover. Had it not been ClusterFuzz, this might not have even been found and in all honesty, I'd be surprised if it was ever found by users.

One could argue that we don't need multiple URL parsers and I would totally agree with that. However, our reality is that we can't trivially drop one and if I'm not mistaken, we have deliberately kept both due to the complexity of eliminating one of them (and associated risks of regressions/security issues).
Labels: Enterprise-Triaged

Sign in to add a comment