💾 Archived View for rawtext.club › ~sloum › geminilist › 005258.gmi captured on 2023-09-08 at 17:26:00. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Luke Emmet luke at marmaladefoo.com
Sun Feb 14 23:02:59 GMT 2021
- - - - - - - - - - - - - - - - - - -
On 13-Feb-2021 00:09, Sean Conner wrote:
There's a semantic difference between a URL that ends with a '/' and one
that doesn't. The one that ends with a '/' is semantically a directory, and
to have to add a file per directory to get all URLs to end with a '/' is, in
my opinion, silly. I can see what you are trying to do---skip the silly
".gmi" or ".gemini" extension as being part of the URL, but there should be
better ways of doing that that populating a filesystem with a bunch of
directories containing a single file (I may do a proof-of-concept with
extensionless files---no, wait! I alreay have that---the individual tests
under the Gemini Client Torture Test!)
It may seem like there is a "natural" difference between these two URL forms, but as far as I understand it the semantics of any URL path segment is opaque and determined by the server. The path is an opaque string whose semantics is not intrinsically discernable.
There may be no files or directories involved whatsoever. It happens that there is a simple sort of implementation to serve a folder of files in this way, but that is by no means a universal URL path semantics that we can make inferences about.
gemini://server/foo may or may not serve the same content as gemini://server/foo/ or it can redirect there. Either way it is up to the server to determine the semantics of the resource.
Clean and simple URLs are nice for end users, and maybe authors too. But that's the main reason we all strive for a simple URL structure.
Regards
- Luke