Comment by 🎵 random-elephant

=> Re: "Server best practices for routing and relative links" | In: s/Gemini

@stack Only if your server shows a list of files when accessing a directory, which I think is in itself a bad feature. And when that option is enabled by default as you suggest, then it's a security risk.

=> 🎵 random-elephant

2024-12-17 · 7 weeks ago

7 Later Comments ↓

=> 🎵 random-elephant · Dec 17 at 07:56:

@satch I couldn't agree less regarding file extensions ! As a human I need to be able to look at a file name (and at a uri) and go "OK, that's gemtext" or "OK that's a picture". By removing the file extensions from paths, you're removing that capacity from me. I can't tell what type of content is hosted at a URL unless I view it.

=> 🎵 random-elephant · Dec 17 at 08:05:

The fact a server can send back any mimetype regardless of what the requested URL was is a weakness of the protocol, not a feature. If I ask for a Jpeg, I should get a Jpeg back.

=> 🐐 satch · Dec 17 at 09:05:

As a human I need to be able to look at a file name (and at a uri) and go "OK, that's gemtext" or "OK that's a picture".

I totally get wanting to do that, and I could even be persuaded that the fact a server can send back any MIME type is a weakness of the protocol.

But given the way things are, all I'm saying is sometimes the filename extension is convenient or aesthetically nice, other times it's not. Having the option is a good thing.

If I was designing a protocol which like nex used filename extensions but gemtext as the default content type, I would specify that without any filename extension, getext should be assumed. That way people get more aesthetic choice.

=> 🎵 random-elephant · Dec 17 at 10:02:

@satch fair enough ! As it happens I'm also implementing my own gemini server at the moment (only out of interest, there's plenty already that would fit my needs), it's interesting to see we're making different design choices (which justifies the fact we need more than one Gemini server so people can choose what they like most).

=> 🚀 stack · Dec 17 at 16:10:

@alice-sur-le-nuage, agreed, but every gemini server I've used (on tildes) dumps directories as links. It makes it very simple to get started, and a simple 'touch index.gmi' disables this behavior when required... I believe this is a defacto expected behavior.

I don't think it's a security threat by itself unless you actively insert the links or files you don't want to see into the directory

=> 🚀 sy · Jan 05 at 23:09:

The way your examples resolved the first segment that starts with a tilde confused me.

AFAIR tilde is not any different than other alphabetic characters. I would expect ~foo to resolve like ./~foo, not like /~foo.

Shells or servers may interpret them specially, but for path resolution it shouldn't matter.

=> 🚀 sy · Jan 07 at 07:04:

@skyjake: I think Lagrange should not be platform dependent when parsing gemtext. Is this a bug?

=> — absolute url check in Lagrange | — tilde check in the_Foundation

Original Post

=> 🌒 s/Gemini

Server best practices for routing and relative links — I'm writing a gemini server and ran into some gotchas when it comes to relative linking from within gemtext. The server will route gemini requests to paths on the filesystem. i.e. a url "index.gmi" would route to a file named "index.gmi" As a convenience, the server will also resolve requests that correspond to a directory on the filesystem iff the directory contains a file named "index.gmi" Let's say there's a file at the subpath ~subspace/...

=> 💬 bjnaved · 13 comments · 2024-12-16 · 7 weeks ago