URLs in request lines

[Sean Conner]

It was thus said that the Great solderpunk once stated:
> >   The TL;DR of this would be:  the following two URLs SHOULD be the same and
> > serve up the same page:
> > 
> >         gemini://example.com
> >         gemini://example.com/ 
> 
> I'll admit to having not yet done the RFC reading ad thinking required
> to know whether the above is in fact already mandated by RFC-3986, but
> the behaviour above is what I *strongly* think should be correct for
> Gemini, and if it's not RFC-mandated then we should make it so in our
> own spec.
> 
> >   Again, per RFC-3986, they are (unless some document describing Gemini URLs
> > states otherwise).  I naturally assumed they would be as they are for HTTP.
> > That's perhaps an unwarrented assumption, but I would have to think the two
> > *are* the same, because of the nature of URLs.
> 
> Certainly, I want Gemini URLs to be as "generic" as possible, and I
> definitely reject the idea of a Gopher-style approach of having our own
> URL standard which deviates from the rest of the world.  Being able to
> do away with that was (a small) part of the motivation for putting
> content type in the Gemini response header.
> 
> Are HTTP URLs perfectly generic or do they have some scheme-dependent
> details in there?

  It's general.  RFC-3986 states:

	In general, a URI that uses the generic syntax for authority with an
	empty path should be normalized to a path of "/".  Likewise, an
	explicit ":port", for which the port is empty or the default for the
	scheme, is equivalent to one where the port and its ":" delimiter
	are elided and thus should be removed by scheme-based normalization. 

  So treating the two Gemini URLs listed above as semantically identical is
fine by the RFC.

> So far I have basically treated Gemini URLs as following whatever rules
> HTTP URLs do.  This is because the URL (un)parsing tools in the Python
> standard library don't work nicely on schemes they don't recognise (like
> gemini://), 

  That's probably because there are a ton of URL schemes [1] that don't
follow the generic URL format so it's best to only merge URL formats that
are recognized.

> > With that out of the way, I do handle the lack of a trailing slash with
> > the request <gemini://gemini.conman.org> in GLV-1.12556 by sending out a
> > redirect.  I think mine is the only server that actually does something
> > different than serve up the top level page [1]. I also do that for any
> > requests that map to a directory that don't end in a slash [2].
> 
> Something I've written (Gegobi, probably?) sends a redirect to add a
> missing trailing slash for requests that map to directories.  This was
> necessary for relative URL absolutisation to function correctly.  I
> remember thinking at the time it was kind of annoying to have to do
> this, but I guess it's the price we have to pay for all of the nice
> stuff that using URLs provides.

  True.  And the Apache webserver also does a redirect in such cases.  So
it's a known problem with a known solution.

  -spc

[1]	https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml