Consider removing the `gopher` special-case.

[mikewest]

gopher is called out as a special scheme with a default port of 70 (https://url.spec.whatwg.org/#url-miscellaneous). Browsers generally implement this bit of the spec. I'd suggest that it's time we stopped doing so.

So far as I can tell, Chrome's support for gopher is limited to URL parsing. The protocol itself isn't supported, and gopher: URLs in the address bar are treated as searches. Gecko looks like it has similar behavior.

Perhaps we could consider dropping the special-casing in URL, and just treating gopher: like any other scheme that the browser doesn't understand. That is, instead of parsing gopher://hostname.goes.here like we'd parse http://hostname.goes.here, we'd parse it like not-a-scheme://hostname.goes.here. This wouldn't preclude user agents from supporting the protocol with external handlers, of course, but it would allow them to stop pretending that they understand the scheme when they clearly don't.

WDYT, @annevk, @mcmanus, @sleevi, @travisleithead, @achristensen07?

[annevk]

Would you also argue that once we drop support for FTP, we start parsing those URLs differently? I guess I don't care too strongly either way, but it seems a little strange just in order to get rid of lookup entry.

cc @valenting

[mikewest]

Would you also argue that once we drop support for FTP, we start parsing those URLs differently?

Yes. I can't think of a good reason to treat protocols that user agents don't actually understand differently than other protocols that user agents don't understand. We don't have special processing for ssh:, for instance, and I'd suggest that that's more widely used than gopher:.

I guess I don't care too strongly either way, but it seems a little strange just in order to get rid of lookup entry.

It's certainly not much code, and has little practical impact either way. But removing it will mean that I never have to reassure myself that Chromium's net stack doesn't actually support Gopher even through kGopherScheme is defined in Chromium's URL library, nor will gopher: come up when discussing UI treatment of various schemes in the context of various stages of HTTP BAD with good folks like @estark37.

It's cruft that seems very safe to remove.

[annevk]

We don't have special processing for blob: either, yet that is used. That's not really an argument one way or another in my opinion. If I have a JavaScript application that parses URLs or implements Gopher suddenly gopher:///test/ would end up parsing differently and perhaps break things. It's probably okay, but not great.

[mikewest]

We don't have special processing for blob: either, yet that is used.

We do have special processing for blob: in URL, both in parsing and in mapping the URL to an origin. Moreover, blobs are in active use with semantics interoperably implemented by user agents. They're a little different than gopher:. :)

If I have a JavaScript application that parses URLs or implements Gopher suddenly gopher:///test/ would end up parsing differently and perhaps break things. It's probably okay, but not great.

I think that the changes to the gopher: test results in https://github.com/w3c/web-platform-tests/tree/master/url would cause some churn. I'd be pretty surprised if that churn broke any applications, because I'd be surprised if gopher: was in anything resembling wide use.

[annevk]

I don't really see the point of breaking the parser behavior, especially since you indicate you plan on continuing to do so. I don't think that's a good idea as it erodes trust in stability of standards.

(There's no parsing for blob: URLs in the URL Standard. That should be handled by a higher processing layer (same as with data: URLs). What some browsers have as URL parser is not generic and considered a bug as that's rather hard to reconcile with the idea of the parser being mostly scheme-agnostic.)

[mikewest]

I don't really see the point of breaking the parser behavior, especially since you indicate you plan on continuing to do so. I don't think that's a good idea as it erodes trust in stability of standards.

I didn't mean to imply that we'd drop ftp: URL parsing the instant we dropped support for the FTP protocol. Given the usage, I expect that to take some time to be able to do safely, as with many other deprecations. Still, it seems like the right eventual direction, doesn't it? If there's no special behavior, special-casing the scheme is just cruft.

There's no parsing for blob: URLs in the URL Standard.

Steps 3-6 of https://url.spec.whatwg.org/#url-parsing process blob: distinctly from other scheme types. But I think I agree with the wider claim that the parser should be scheme-agnostic.

[annevk]

If there's no special behavior, special-casing the scheme is just cruft.

But there is special parsing behavior and there's no security risk associated with it. It seems weird to change the parsing of URLs over time. The whole idea of this effort is to put a stop to that and give folks consistent behavior.

[jasnell]

In general, I'd prefer to keep the current special casing in place unless there's enough of a significant justification for breaking, and I don't believe the reason given here meets that bar.

[achristensen07]

Having it or removing it makes no difference to me. I’ve seen no reported problems involving gopher url parsing

[mnot]

@jasnell afraid of the 418 pitchfork-wielding mob being reactivated, eh? ;)

[achristensen07]

I've implemented this change in https://bugs.webkit.org/show_bug.cgi?id=201852
Firefox already doesn't parse gopher as a special scheme. Let's change the spec.