Scheme Section 2 quibble

Sean Conner sean at conman.org
Tue Nov 17 02:19:16 GMT 2020


It was thus said that the Great Ali Fardan once stated:
> On Mon, 16 Nov 2020 23:39:19 +0000
> acdw <acdw at acdw.net> wrote:
> > > The authority component is preceded by a double slash ("//") and is
> > > terminated by the next slash ("/"), question mark ("?"), or number
> > > sign ("#") character, or by the end of the URI.  
> > 
> > Meaning that the scheme does not, in fact, include a "//" at the end,
> > but rather that "//" is a separator between the scheme and the
> > authority.  In fact, to actually encode a scheme-agnostic URL in a
> > link, an author needs to write "//example.com/path".  For an example,
> > see the links in flounder.online.
> > 
> > I bring this issue up because there have been instances of geminauts
> > linking like this:
> > 
> > => example.com/path An example link  
> > 
> > Which resolves, not to gemini://example.com/path, but
> > to ./example.com/path on the current server.
> 
> This is wrong, even by web standards, when referencing to a different
> host, one must explicitly write a valid URL, you DON'T see:
> 
> >	<a href="example.tld/index.html"></a>
> 
> > To resolve this confusion, I propose is to either
> > 
> > (a) strip the "//" (and probably ":", though I found no particular
> > reference to it in the spec) from the "scheme of gemini:// is
> > implied" portion of the above paragraph, or
> 
> In my humble opinion, I think that "//example.tld/" is an
> implementation specific hack and has no place in the protocol, a URI
> like that is invalid and should not be respected by servers, 

  It *is* allowed though---it's a schemeless URI and in a given context, it
can be inferred.  Check out RFC-3986 section 5.2.2 (Transforming
Rreferences, aka, resolving a URL with a base URL) and section 5.3
(Component Recomposision) where ':' is appended to the scheme, and '//' is
prefixed to the authority (host) section.

  So, given a URL like this:

	//example.net/path/to/resource

in a resource, if the resource was served up via HTTP, then the scheme is
'http:'; if HTTPS, then 'https:' and if gemini, 'gemini:'.  

  A URL like this:

	example.net/path/to/resource

is, again, per RFC-3986 parsing rules, to be interpreted as a path, not an
authority section then path.  Need I create an example to show this?  I can.

  -spc



More information about the Gemini mailing list