Should Gemini clients alert users upon redirect?

Sandra Snan sandra.snan at
Tue Feb 16 20:58:12 GMT 2021

Luke wrote:
> 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.

I don't wanna disagree with someone who is in my own corner on this♥,

It's tree semantics, which is evidenced in practice by the way relative
links work. (Especially since .. and co exist).

A link to bar/baz from gemini://server/foo leads to
gemini://server/bar/baz while a link to bar/baz from
gemini://server/foo/ leads to gemini://server/foo/bar/baz.

I've now implemented 31s and 301s from the slashed to unslashed so now I
can start using relative links again. Except they'll have to be written
to reflect the reality that /foo is a leaf node and not a directory
node, i.e. the leaf node is no longer a file named "" (the empty

It's also something that might be good to reflect in culture and

I could see if, for example "gemini://",
instead had the url been gemini://,
how that would make sense in some way.

I've kept my own web page & capsule having all flat URLs in one huge
name space for a while. It's a tradeoff…


More information about the Gemini mailing list