Philip Linde linde.philip at gmail.com
Fri Feb 26 10:16:10 GMT 2021
- - - - - - - - - - - - - - - - - - -
On Wed, 17 Feb 2021 10:16:47 +0100Stephane 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 noteswhere it deviates from the general shoulds and musts of the standard itrefers to and leaves everything else wihout comment. Otherwise, theGemini URI syntax is largely unspecified.
Also because, according o RFC 3986, "The syntax and semantics of URIsvary from scheme to scheme, as described by the defining specificationfor each scheme" with the Gemini spec not noting any variation fromthe general case in 6.2.3.
I've raised this issue at least twice before, because there are some (orone) Gemini server implementations that do not follow this, and willserve a redirect on "gemini://host" to "gemini://host/", and theexpected content only on "gemini://host/". Even ignoring thenormalizations in RFC 3986, I don't know that there are any good reasonsto do this, but last I checked even gemini.circumlunar.space does.
So I think your assumption is fair, but also that the spec should beupdated to be explicit about this case because some server authorsobviously disagreed with us and we have to resort to RFC SherlockHolmes type inference to make a point otherwise.
-- Philip-------------- next part --------------A non-text attachment was scrubbed...Name: not availableType: application/pgp-signatureSize: 488 bytesDesc: not availableURL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210226/a3b316f5/attachment.sig>