💾 Archived View for rawtext.club › ~sloum › geminilist › 005691.gmi captured on 2024-02-05 at 11:08:03. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Stephane Bortzmeyer stephane at sources.org
Fri Feb 26 13:26:45 GMT 2021
- - - - - - - - - - - - - - - - - - -
On Fri, Feb 26, 2021 at 11:16:10AM +0100, Philip Linde <linde.philip at gmail.com> wrote a message of 63 lines which said:
I've raised this issue at least twice before, because there are some
(or one) Gemini server implementations that do not follow this, and
will serve a redirect on "gemini://host" to "gemini://host/", and
the expected content only on "gemini://host/". Even ignoring the
normalizations in RFC 3986, I don't know that there are any good
reasons to do this, but last I checked even gemini.circumlunar.space
does.
And these implementations are right, since the point is currently notspecified (one of the holes in the specification).
A possible way to address a lot of such holes (though not all of them)would be to just state in the specification:
"For path, query and fragments semantics, just do like the httpscheme." This would solve this problem and would be reasonable sincemany people assume that all schemes behave like http.