URLs in request lines

[Sean Conner]

  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/ 

  What's below is my thought process leading up to that.

It was thus said that the Great plugd once stated:
> Sean Conner writes:
> >   So, the upshot (as I see it) is that the gopher URL format is divorced
> > from the RFC-3986 URL and is its own thing.  You can't really say they have
> > the same semantic rules.  This is also reflected in the caps.txt file you
> > will sometimes find on gopher servers to address the bit in RFC-1436 that
> > gopher selectors are opaque and *no* meaning is to be inferred by the
> > client.
> 
> Completely agree that gopher is special here, but my reading of RFC-3986
> section 6.2.3 was that itactually allows for some scheme-dependent
> behaviour anyway.

You are right (now that I'm rereading that section).

> >   As far as Gemini goes, I've been parsing Gemini URLs under RFC-3986, just
> > like http:, https:, ftp: and file:.
> >
> >   -spc (Did that answer your question?)
> 
> You almost certainly have answered my question, but I'm being really
> daft and still not getting it.  (Feel free to give up!) 

  Give up?  Never give up!  Never surrender!  By Grabthar's hammer, by the
suns Worvan, you shall be avenged!

  Oh, sorry.  Got carried away there.

  No, this is good.  I'm having to clarify my own thoughts on this.  You
have no idea how much I've written and deleted in writing this reply.

> I'm not asking
> about what constitutes a valid gemini URL and more about whether it's
> already been decided that a server which responds with a 2x status for
> gemini://example.com/ must also respond with a 2x (and the same
> document) for gemini://example.com - even though they're both valid
> URLs.  Or are you saying that this semantic equivalence is already
> mandated by RFC-3986?

  Technically speaking, these two URLs are NOT the same:

	http://example.com/foo
	http://example.com/foo/

and a webserver could technically serve up different content for the two
requests.  But RFC-3986, section 6.2.3 states that the following are the
same for http:

	http://example.com
	http://example.com/

  The question you are asking is---are the these two examples the same for
Gemini?

	gemini://example.com
	gemini://example.com/

  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.

  The *only* character that can follow the authority section (hostname,
port, etc) of a URL is the slash.  There is no other valid character that
can go there.  So while it is possible for a Gemini server to serve up two
different resources for the example above, that would, in my opinion,
violate the rule of least surprise.  Even with gopher URLs, RFC-4266,
section 2.1 says the following are the same:

	gopher://example.com
	gopher://example.com/
	gopher://example.com/1

  The slash between the authority section and the selector is required not
only by URL parsing rules, but because there are alphaebtic gopher types. 
Also, RFC-1436 (Introduction) states that gopher selectors are opaque and
have no meaning, so the following two are distinct resources:

	gopher://example.com/1
	gopher://example.com/1/

  Addtionally, these *are* already covered by RFC-3986 (first example
above), but I digress.  So while technically what you say is true (two
different resources) I would recommend against it (rule of least surprise).

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

  -spc (Did this answer your question?)

[1]	I tried all other known Gemini servers by just requesting, say:

		gemini://mozz.us

	And they all returned their default page.

[2]	RFC-3986, section 6.2.4.  The Apache web server even has code to
	deal when you give a URL to a filesystem directory that doesn't end
	in a slash:

		A "trailing slash" redirect is issued when the server
		receives a request for a URL http://servername/foo/dirname
		where dirname is a directory.  Directories require a
		trailing slash, so mod_dir issues a redirect to
		http://servername/foo/dirname/.

		http://httpd.apache.org/docs/2.4/mod/mod_dir.html

	I even had to deal with this in GLV-1.12556 to properly handle
	client certificates with respect to the rule of least surprise.