-- Leo's gemini proxy
-- Connecting to gemini.bortzmeyer.org:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini; lang=en
There are two issues with the current (january 2021) Gemini specification regarding to fragments.
What to do when redirecting? If original URI is <gemini://foobar.example/#baz> and there is a redirect to <gemini://thing.example/doit>, should the Gemini client consider is has to go to <gemini://thing.example/doit#baz> or to <gemini://thing.example/doit>?
The spec says "The path, query and fragment components are allowed and have no special meanings beyond those defined by the generic syntax." But RFC 3986 just describes a *syntax*, it seems silent about semantics.
Therefore, for HTTP, RFC 7231 has to describe in detail what the client ("user agent", in HTTP parlance) has to do with fragments. Should we consider that "in doubt, do as HTTP does?"
There are many proposals for a semantic for fragments in text/gemini resources.
state that they have no use and no meaning
use the structure of the gemtext (headers, lines) to have fragment identifiers like h2.4 (fourth second level header)
content-addressable text, the fragment would be a hash of part of the text
use fragment identifiers of RFC 5147 (not very robust, any change would break them)
fragment identifier as a search query in the page (Control-F…)
-- Response ended
-- Page fetched on Sat May 18 20:03:34 2024