Using netcat with gemini (was Re: A question regarding the spec)

[Philip Linde]

On Wed, 28 Oct 2020 17:59:21 -0400
Sean Conner <sean at conman.org> wrote:

>   The specification should say:
> 
> 	If the scheme of the URL is not specified, a scheme of gemini: is
> 	implied.
>

The colon also isn't part of the scheme, but the URI as a whole. If one
can omit both the scheme and the colon, then the slightly adjusted
"absolute URL" becomes what RFC 3986 calls a "relative reference",
e.g. "//gemini.circumlunar.space". Omitting the scheme from an absolute
URI (which I assume is what the Gemini spec refers to with
"absolute URL") would leave us with "://gemini.circumlunar.space".

Both our conclusions require similarly liberal interpretation of the
Gemini spec, though your interpretation is easier to describe in terms
of modifications to the rules already defined in RFC 3986.

>   I'm not aware of any server that does otherwise.  There are servers out
> there that play around with trailing '/'  elsewhere in the URL [3], but not
> at the root.

As demonstrated by Sudipto Mallick above, gemini.circumlunar.space does
otherwise. Request "gemini://gemini.circumlunar.space" and you get one
response (a 31 redirect code), but if you request
"gemini://gemini.circumlunar.space/" you get a code 20 response with
the landing page. The URIs are not treated as equivalent, which they
should be after normalization.

The path isn't normalized in the same way, so it's not a concern there.

> [2]	The URI-reference rule is listed third---I think this is a mistake
> 	on the part of the RFC,

The order of the ABNF rules in the appendix bears no significance to
their interpretation. The rule named "URI" defines the URI syntax. The
rule named "URI-reference" defines a syntax for a sequence that is
either a URI or a relative reference. Gemini requests by my
interpretation uses neither, but the rule named "absolute-URI" (to
disallow fragments?), modified so that

  authority = host [ ":" port ]

and with the note about implied scheme, which interpreted literally
would normalize "://example.com" to "gemini://://example.com" and would
accept neither "example.com" nor "//example.com".

By your interpretation (which I agree makes most sense) it is more
succinct and correct to describe the Gemini URL as an RFC 3986 "URI"
with the rules modified so that

  URI           = [ scheme ":" ] hier-part [ "?" query ]
  authority     = host [ ":" port ]

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201029/0b5b9bec/attachment-0001.sig>