URLs in request lines

[solderpunk]

>   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?

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://), and they won't convert relative URLs to absolute URLs
correctly.  So, I have written some fairly ugly code where "gemini://"
is replaced by "http://" before doing stuff using those tools, and then
this is reversed at the end.  I don't really like doing this, but I
dislike it less than writing my own URL-mangling code.  Because of this
limitation, practically speaking Gemini URLs had better act identically
with *some* standard URL scheme that Python is aware of, and HTTP seems
a much more sensible choice than, say, FTP.

> 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.

-Solderpunk