URLs in request lines

[Sean Conner]

It was thus said that the Great Bradley D. Thornton once stated:
> On 9/14/2019 3:36 PM, Sean Conner wrote:
> > 
> >   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.
> > 
> > 
> >   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.
> 
> And that does happen sometimes in the real world, and confuses people.
> To me, the trailing slash forces the implication that you're looking for
> an index file in that particular directory, whatever kind is specified
> by httpd, rather than a file named foo.
> 
> After all, there could exist, both a directory *AND* a file named 'foo'.

  That would be a good trick.  I don't know of any filesystem that will
allow you to have a file *and* a directory with the same name in the same
location.  


  I had to do that with a custom non-filesystem handler.

> > But RFC-3986, section 6.2.3 states that the following are the
> > same for http:
> > 
> > 	http://example.com
> > 	http://example.com/
> >
> 
> And IMO, they should be treated as such, but are sometimes not. I've
> received 404's on occsion when omitting the trailing slash, and just got
> into the habit of (most often) putting it there when I type in an URL.

  That sounds like a webserver that hasn't been set up to automatically
redirect when it sees a resource that is an actual directory but the request
doesn't include a trailing slash.

> >   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.
> 
> What about:
>      gemini://example.com/foo
>      gemini://example.com/foo/

  What about it?

	gemini://gemini.conman.org/foo
	gemini://gemini.conman.org/foo/

> In the first example, couldn't that refer to either a request for either
> an index.gmi in foo/ or a file in / called foo?

  Try it.  [1]

> I'm not proposing anything. I'm just asking.

  And I'm answering 8-P

  But seriously, I don't think this should be done, even if it can be done.

> I've been invited over to another farm tonight to do some Drinkin'
> Lincoln, and I know they've got good sippin' whiskey there lolz.
> 
> I've finished fiddling with the main gophermap on gopher://Vger.Cloud
> and one client is giving me errors about:
> 
> <snip>
> sh: 1: Syntax error: "(" unexpected
> </snip>

  It's the server.  My own gopher client is failing to show the output. 
Doing it manually reveals the issue:

[spc]lucy:~/source/gopher>nc vger.cloud 70

sh: 1: Syntax error: "(" unexpected
iWelcome to Vger!       TITLE   null.host       1
i               null.host       1

  I only mention in case it wasn't clear if the error was in the client or
server.

  -spc 

[1]	I had to write a custom handler to do that.  I don't have a file
	named 'foo' or a directory named 'foo'.