Should Gemini clients alert users upon redirect?
linde.philip at gmail.com
Fri Feb 26 10:16:10 GMT 2021
On Wed, 17 Feb 2021 10:16:47 +0100
Stephane Bortzmeyer <stephane at sources.org> wrote:
> On Tue, Feb 16, 2021 at 10:52:47PM -0500,
> Michael Lazar <lazar.michael22 at gmail.com> wrote
> a message of 33 lines which said:
> > gemini://example.com and gemini://example.com/ are canonically the
> > same resource and should always return the same response.
> Are you sure?
> RFC 3986, section 6.2.3 says "In general, a URI that uses the generic
> syntax for authority with an empty path should be normalized to a path
> of "/"." Note the "in general". The rest of section 6.2.3 explains
> that is is scheme-specific.
In my interpretation I make the assumption that the Gemini spec notes
where it deviates from the general shoulds and musts of the standard it
refers to and leaves everything else wihout comment. Otherwise, the
Gemini URI syntax is largely unspecified.
Also because, according o RFC 3986, "The syntax and semantics of URIs
vary from scheme to scheme, as described by the defining specification
for each scheme" with the Gemini spec not noting any variation from
the general case in 6.2.3.
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.
So I think your assumption is fair, but also that the spec should be
updated to be explicit about this case because some server authors
obviously disagreed with us and we have to resort to RFC Sherlock
Holmes type inference to make a point otherwise.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 488 bytes
Desc: not available
More information about the Gemini