New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider removing the gopher
special-case.
#342
Comments
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 |
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
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 It's cruft that seems very safe to remove. |
We don't have special processing for |
We do have special processing for
I think that the changes to the |
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 |
I didn't mean to imply that we'd drop
Steps 3-6 of https://url.spec.whatwg.org/#url-parsing process |
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. |
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. |
Having it or removing it makes no difference to me. I’ve seen no reported problems involving gopher url parsing |
@jasnell afraid of the 418 pitchfork-wielding mob being reactivated, eh? ;) |
I've implemented this change in https://bugs.webkit.org/show_bug.cgi?id=201852 |
https://bugs.webkit.org/show_bug.cgi?id=201852 Patch by Alex Christensen <achristensen@webkit.org> on 2019-09-16 Reviewed by Simon Fraser. LayoutTests/imported/w3c: * web-platform-tests/url/a-element-expected.txt: * web-platform-tests/url/a-element-origin-expected.txt: * web-platform-tests/url/a-element-origin-xhtml-expected.txt: * web-platform-tests/url/a-element-xhtml-expected.txt: * web-platform-tests/url/url-constructor-expected.txt: * web-platform-tests/url/url-origin-expected.txt: * web-platform-tests/url/url-setters-expected.txt: Source/WTF: There is little meaningful content on gopher servers, and WebKit does not actually support gopher. This makes WebKit match the behavior of Gecko and goes along with a change proposed at whatwg/url#342 * wtf/URLParser.cpp: (WTF::URLParser::defaultPortForProtocol): (WTF::scheme): (WTF::URLParser::copyURLPartsUntil): (WTF::URLParser::parse): Tools: * TestWebKitAPI/Tests/WTF/URLParser.cpp: (TestWebKitAPI::TEST_F): * TestWebKitAPI/Tests/WebCore/URLParserTextEncoding.cpp: (TestWebKitAPI::TEST_F): * TestWebKitAPI/Tests/WebKitCocoa/WKURLSchemeHandler-1.mm: LayoutTests: * fast/url/invalid-urls-utf8-expected.txt: * fast/url/invalid-urls-utf8.html: * fast/url/segments-expected.txt: * fast/url/segments.html: * fast/url/standard-url-expected.txt: * fast/url/standard-url.html: * fetch/fetch-urls.json: * http/wpt/html/browsers/history/the-location-interface/location-protocol-setter-non-broken-async-delegate-expected.txt: git-svn-id: http://svn.webkit.org/repository/webkit/trunk@249941 268f45cc-cd09-0410-ab3c-d52691b4dbfc
FWIW: I'm planning on following @achristensen07's example in https://chromium-review.googlesource.com/c/chromium/src/+/612983. I think we've both just checked-in failing expectations for the existing URL tests. Our results differ due to https://crbug.com/869291 (I think WebKit's correct and Chrome is wrong), but it's probably a good idea to update the test expectations accordingly. |
I'm still not convinced this is a worthwhile endeavor, but as everyone is planning on shipping this it would be nice if someone wrote a PR and updated WPT. |
See whatwg/url#342 for context.
…emes, a=testonly Automatic update from web-platform-tests URL: make gopher behave like unrecognized schemes See whatwg/url#342 for context. -- wpt-commits: 8a9d0ccbeabbec3df4c38a394651d1b53dd2f8c5 wpt-pr: 19770
…emes, a=testonly Automatic update from web-platform-tests URL: make gopher behave like unrecognized schemes See whatwg/url#342 for context. -- wpt-commits: 8a9d0ccbeabbec3df4c38a394651d1b53dd2f8c5 wpt-pr: 19770
…emes, a=testonly Automatic update from web-platform-tests URL: make gopher behave like unrecognized schemes See whatwg/url#342 for context. -- wpt-commits: 8a9d0ccbeabbec3df4c38a394651d1b53dd2f8c5 wpt-pr: 19770 UltraBlame original commit: 993dacde06c1a64aac243210577193125b8948a1
…emes, a=testonly Automatic update from web-platform-tests URL: make gopher behave like unrecognized schemes See whatwg/url#342 for context. -- wpt-commits: 8a9d0ccbeabbec3df4c38a394651d1b53dd2f8c5 wpt-pr: 19770 UltraBlame original commit: 993dacde06c1a64aac243210577193125b8948a1
…emes, a=testonly Automatic update from web-platform-tests URL: make gopher behave like unrecognized schemes See whatwg/url#342 for context. -- wpt-commits: 8a9d0ccbeabbec3df4c38a394651d1b53dd2f8c5 wpt-pr: 19770 UltraBlame original commit: 993dacde06c1a64aac243210577193125b8948a1
https://bugs.webkit.org/show_bug.cgi?id=201852 Patch by Alex Christensen <achristensen@webkit.org> on 2019-09-16 Reviewed by Simon Fraser. LayoutTests/imported/w3c: * web-platform-tests/url/a-element-expected.txt: * web-platform-tests/url/a-element-origin-expected.txt: * web-platform-tests/url/a-element-origin-xhtml-expected.txt: * web-platform-tests/url/a-element-xhtml-expected.txt: * web-platform-tests/url/url-constructor-expected.txt: * web-platform-tests/url/url-origin-expected.txt: * web-platform-tests/url/url-setters-expected.txt: Source/WTF: There is little meaningful content on gopher servers, and WebKit does not actually support gopher. This makes WebKit match the behavior of Gecko and goes along with a change proposed at whatwg/url#342 * wtf/URLParser.cpp: (WTF::URLParser::defaultPortForProtocol): (WTF::scheme): (WTF::URLParser::copyURLPartsUntil): (WTF::URLParser::parse): Tools: * TestWebKitAPI/Tests/WTF/URLParser.cpp: (TestWebKitAPI::TEST_F): * TestWebKitAPI/Tests/WebCore/URLParserTextEncoding.cpp: (TestWebKitAPI::TEST_F): * TestWebKitAPI/Tests/WebKitCocoa/WKURLSchemeHandler-1.mm: LayoutTests: * fast/url/invalid-urls-utf8-expected.txt: * fast/url/invalid-urls-utf8.html: * fast/url/segments-expected.txt: * fast/url/segments.html: * fast/url/standard-url-expected.txt: * fast/url/standard-url.html: * fetch/fetch-urls.json: * http/wpt/html/browsers/history/the-location-interface/location-protocol-setter-non-broken-async-delegate-expected.txt: Canonical link: https://commits.webkit.org/215492@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@249941 268f45cc-cd09-0410-ab3c-d52691b4dbfc
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, andgopher:
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 parsinggopher://hostname.goes.here
like we'd parsehttp://hostname.goes.here
, we'd parse it likenot-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?
The text was updated successfully, but these errors were encountered: