On Wed, Feb 17, 2021 at 4:18 AM 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. > > <gemini://gemini.circumlunar.space/docs/specification.gmi> seems > silent about "gemini:" rules. 1.2 says "The path, query and fragment > components are allowed and have no special meanings beyond those > defined by the generic syntax." > > (The Lupa crawler currently normalizes <gemini://example.com> to > <gemini://example.com/> but I wonder if I'm right.) That's an interesting point. Assuming the gemini spec is undefined simply because this edge case was not considered at the time (that I am 99.9% sure of). Can you make an argument for why this normalization *should not* be adopted by gemini://? The biggest advantage that I see is that we can use existing URL normalization tools and libraries which, like it or not, are heavily biased towards working with the http:// URL scheme. Also, those URLs being the same means that I can always depend on using "/" as the relative link for my root URL. If I had to worry about them being semantically different, I would also want to be able to use an empty string "" as a relative URL (which is valid as far as I can tell, see path-empty in section 4.2 the RFC). But looking at the text/gemini specification for link lines: =>[<whitespace>]<URL>[<whitespace><USER-FRIENDLY LINK NAME>] A blank, relative <URL> will collapse into =>[<whitespace><USER-FRIENDLY LINK NAME>] which collides with the alternate form of =>[<whitespace>]<URL> - Michael
---
Previous in thread (30 of 35): 🗣️ Luke Emmet (luke (a) marmaladefoo.com)
Next in thread (32 of 35): 🗣️ Bradley D. Thornton (Bradley (a) NorthTech.US)