๐Ÿ’พ Archived View for bbs.geminispace.org โ€บ u โ€บ bjnaved โ€บ 22863 captured on 2024-12-17 at 15:21:54. Gemini links have been rewritten to link to archived content

View Raw

More Information

-=-=-=-=-=-=-

Comment by ๐Ÿ•๏ธ bjnaved

Re: "Server best practices for routing and relative links"

In: s/Gemini

the directory index could be something else, maybe not even a page at all

That's a great point that I hadn't considered. Thanks for the insight! I was only thinking about the redirect-to-index behaviour, not file listings, etc. I think I'll do as you suggest and only perform the append-slash redirect for directory paths.

๐Ÿ•๏ธ bjnaved [OP]

24 hours ago

9 Later Comments โ†“

๐ŸŽต alice-sur-le-nuage ยท 22 hours ago:

I don't think anything is gained by having a URL pointing to a directory return the content of <directory name>/index.gmi . If you want the content of index.gmi, just add that to your link. I know it's common practice on the web - but only because it looks neater, not because it's useful.

๐Ÿš€ stack ยท 22 hours ago:

There is a great reason -- you can hide the contents of your directories by dropping in a blank index.gmi .

As well as providing access to some files but not allowing the user to snoop.

Also, that is the expected behavior.

๐Ÿ satch ยท 21 hours ago:

@alice-sur-le-nuage it looks neater, and that matters! Aesthetics are important. Sometimes leaving index.gmi in the link is the preferred aesthetic, other times not.

Often, it's nice to make all urls on the site point to directories, so every page ends up being called index.gmi.

I do wish more servers supported omitting the file name extension from html/gmi files. I think they should be the default types for their associated protocols, not plain text. While it's useful in some contexts, you don't *need* the extension, that's what MIME type is for - and anyway, you can serve any kind of file with any extension you want, so it's not good to assume you know the file type of a resource when all you have is an filename extension.

๐ŸŽต alice-sur-le-nuage ยท 12 hours ago:

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

๐ŸŽต alice-sur-le-nuage ยท 12 hours ago:

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

๐ŸŽต alice-sur-le-nuage ยท 12 hours ago:

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 ยท 11 hours ago:

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.

๐ŸŽต alice-sur-le-nuage ยท 10 hours ago:

@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 ยท 4 hours ago:

@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

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 ยท 11 comments ยท Dec 16 ยท 1 day ago