URLs in request lines

[Bradley D. Thornton]

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


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

But your example above isn't the same as the example above that ;)

I do my very best when referring to directory structure to practice this
too. If nothing else, I get to omit the word, "directory" in Howto's and
tuts or procedural documents I write. After all, without using the word
'directory', or using the trailing slash, one *could* be referring to a
regular file type instead of a directory file type ;)


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

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?

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

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

Hm... I don't know that I know the difference there.Perhaps I should
read up in the appropriate section of the RFC below. If that URI were
for HTTP, it would be saying, "Give me the file named '1'. Actually,
before I over think this, it would mean the same thing in HTTP.

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

ANYWAY...

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>

And I have no idea where the heck that is. It's the only client slinging
that error to me and it was giving me two of those, so I apparently, and
somehow inadvertently, fixed one of those errors. I see no open paren's
without a corrsponding closing paren, and then, only in the raw text of
a sentence.

I also Gave Tim a good plug for Elpher both there and on V'Ger's Gemini
site. I really like that browser :)

I also botched my install of Elpher, so maybe could use a little guidance ;)

While upgrading from 2.2.0 yesterday, I found out that I got a little
impatient and didn't terminate the upgrade with an 'x', after the 'u' to
upgrade, and C-Xc'd out. That left both versions installed, and now,
even though I've ripped it out and reinstalled it several times
(including at one point to del the directory (elpher, IIRC) in emacs.d/
and now I am forever not able to get anything but:

<snip>
LOADING GEMINI... (use 'u' to cancel)
</snip>

At least gemini://vger.cloud gives me a definitive 51 error :)

<snip>

---- ERROR -----

When attempting to retrieve gemini://vger.cloud/:
Gemini server reports PERMANENT FAILURE for this request: "51	Not Found".

----------------

Press 'u' to return to the previous page.

</snip>

It's frustrating, because I'm not sure why, and every other single
client brings both sites up just dandy like. And I'm not trying to
access my server w/Elpher from localhost, if that's relevant.

That should answer your question too from yesterday about the errors
with your site Sean ;)

I promise to be patient from now one when updating Melpa packages, and
would like to avoid ripping out Emacs by it's fdisking throat and
re-installing, so if someone's got any clues to fix it in situ, please,
do let me know. I promise to be good next time lol.

-- 
Bradley D. Thornton
Manager Network Services
http://NorthTech.US
TEL: +1.310.421.8268