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

[Sean Conner]

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 the
RFC and specifically of the BNF of the URL (I say, having written a URL
parser 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 out
there that play around with trailing '/'  elsewhere in the URL [3], but not
at 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/