Scheme Section 2 quibble

[Ali Fardan]

On Tue, 17 Nov 2020 10:19:52 +0100
Philip Linde <linde.philip at gmail.com> wrote:
> With respect to RFC3986, it's not a matter of opinion.
> 
> It's very much not an implementation specific hack. It's defined in
> RFC 3986 as "relative-ref", a "network-path reference" specifically.
> Non-URIs of the "example.com/hello" style on the other hand are an
> implementation specific hack, as you've noted, discouraged by RFC 3986
> and not specified in any of the syntaxes it defines. It's obviously
> unsuitable for links because it's ambiguous with relative-ref.

I don't know about that, section 3.2 states that authority should be
preceded by a "//", not that it is a part of the authority component,
also, the ABNF representation has no "//" in it.

Suffix references (section 4.5) are only discouraged because of
possible misinterpretation, however in the case of Gemini requests,
people can write their code to handle them just like they write their
code to handle "//example.tld", it's not that hard and looks much much
cleaner, the argument that it could be interpreted as path should also
apply for "//example.tld" too, because it could be interpreted as a
path too, however if the author decided to handle such case, it'll be
handled just fine, you can have your parser treat the text before the
first occurrence of '/' as host subcomponent of authority component if
scheme is not specified just like you have your parser treat the first
occurrence of '/' after the "//" prefix as host subcomponent in the
current way of handling schemeless requests in Gemini, the Gemini
protocol requires passing full URL in requests, therefore, such should
not be interpreted as path because Gemini requests don't allow path
without stating host.

So yeah, I'm not changing my mind, "//example.tld" is a hack because
that is not a valid URI and "//" is supposed to be only present when
scheme is specified, however, "example.tld" is while discouraged,
acceptable for this use case and the RFC even acknowledged it.

Let me quote to you why it is that RFC 3986 discourages its use:

> Although this practice of using suffix references is common, it
> should be avoided whenever possible and should never be used in
> situations where long-term references are expected.

In the case of Gemini requests, they are not a 'long-term' reference,
they're one-time requests, I don't see any downside to not doing it.

> Last I checked, if you connect to gemini://gemini.circumlunar.space
> and request "gemini.circumlunar.space/" you get an error. You may
> however request "//gemini.circumlunar.space/" and get the appropriate
> 20 response. Should gemini.circumlunar.space be considered to be
> running a canonical implementation of Gemini?

You shouldn't look at any particular implementation as a reference for
the spec, I'm assuming gemini.circumlunar.space is running molly-brown,
do you know that molly-brown treats single '\n' as valid request
terminators instead of explicit '\r\n'? (see:
https://tildegit.org/solderpunk/molly-brown/src/branch/master/handler.go#L138),
do you know that if a transaction is finished, molly-brown waits for
the client to close the connection instead of closing it from the
server side, is that spec compliant?

The reason I think molly-brown accepted "//example.tld" in the first
place is because the Go standard library URL parser implementation
accepted this, I don't know if this was a bug or it is intended design,
but that's what it is, other URI parsers that are more strict with
compliance to the RFC will refuse to parse a URI without scheme
present, here is an excerpt from the library's documentation that might
give an idea of how they treat URLs:

> A URL represents a parsed URL (technically, a URI reference).
>
> The general form represented is:
>
> [scheme:][//[userinfo@]host][/]path[?query][#fragment]
>
> URLs that do not start with a slash after the scheme are
> interpreted as:
>
> scheme:opaque[?query][#fragment]

Notice that [scheme:] is enclosed in brackets implying that it is
optional, while [//host] is optional too, the "//" is considered a part
of the authority component by the Go URL parser implementation, this is
why "//example.tld" is accepted while "example.tld" is not, try passing
both strings to url.Parse() and see what you get.