💾 Archived View for rawtext.club › ~sloum › geminilist › 002955.gmi captured on 2020-10-31 at 14:53:30. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Philip Linde linde.philip at gmail.com
Wed Oct 28 16:49:49 GMT 2020
- - - - - - - - - - - - - - - - - - -
On Wed, 28 Oct 2020 12:04:28 -0400"Chris Vittal" <chris at vittal.dev> wrote:
A properly formed gemini request is a fully qualified URL with a scheme
and authority.
Not in this case. In a request, it is only necessary to specify theauthority and optionally a path. From the spec (0.14.2):
If the scheme of the URL is not specified, a scheme of gemini:// is
implied.
So the server really should treat both requests as equivalent.
Furthermore, I think it's wrong of the server not to serve the sameresource for "gemini.circumlunar.space" and "gemini.circumlunar.space/".The spec says that the URI is syntactically compatible with the genericURI syntax except that the userinfo subcomponent of the genericauthority is not allowed. Serving different content for "/" andunspecified path is another difference from the generic URI syntax thatis not specified. RFC 3986:
In general, a URI that uses the generic syntax for authority with an
empty path should be normalized to a path of "/".
This is a should and not a must, but I also think it's bad behaviorpractically to force a client to make another request for somethingthat should really be an implementation detail in the server. I alsodon't see any practical reasons one might want to distinguish the two.
-- 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/20201028/31efaa61/attachment.sig>