<-- back to the mailing list

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

Sean Conner sean at conman.org

Wed Oct 28 21:59:21 GMT 2020

- - - - - - - - - - - - - - - - - - - 

It was thus said that the Great Philip Linde once stated:

On Wed, 28 Oct 2020 12:04:28 -0400
"Chris Vittal" <chris at vittal.dev> wrote:
A properly formed gemini request is a fully qualified URL with a scheme
and authority.
Not in this case. In a request, it is only necessary to specify the
authority and optionally a path. From the spec (0.14.2):
If the scheme of the URL is not specified, a scheme of gemini:// is
implied.
So the server really should treat both requests as equivalent.

The specification is technically incorrect, at least in my reading of theRFC and specifically of the BNF of the URL (I say, having written a URLparser based closely on the BNF [1]). The BNF starts [2]

URI-reference = URI / relative-ref

URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

hier-part = "//" authority path-abempty / path-absolute / path-rootless / path-empty

relative-ref = relative-part [ "?" query ] [ "#" fragment ]

relative-part = "//" authority path-abempty / path-absolute / path-noscheme / path-empty

The specification should say:

If the scheme of the URL is not specified, a scheme of gemini: is implied.

Furthermore, I think it's wrong of the server not to serve the same
resource for "gemini.circumlunar.space" and "gemini.circumlunar.space/".

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

-spc

[1] https://github.com/spc476/LPeg-Parsers/blob/master/url.lua

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

[3] gemini://gemini.conman.org/test/doc1 gemini://gemini.conman.org/test/doc1/