Hi Sean, Sean Conner writes: > The TL;DR of this would be: the following two URLs SHOULD be the same and > serve up the same page: > > gemini://example.com > gemini://example.com/ Great, so I will continue to do what I have been doing: automatically replacing empty filenames with "/". >> Completely agree that gopher is special here, but my reading of RFC-3986 >> section 6.2.3 was that itactually allows for some scheme-dependent >> behaviour anyway. > > You are right (now that I'm rereading that section). Great to know that I'm not going completely mad! >> You almost certainly have answered my question, but I'm being really >> daft and still not getting it. (Feel free to give up!) > > Give up? Never give up! Never surrender! By Grabthar's hammer, by the > suns Worvan, you shall be avenged! holy moly > Oh, sorry. Got carried away there. :-) > No, this is good. I'm having to clarify my own thoughts on this. You > have no idea how much I've written and deleted in writing this reply. Thanks for your persistence! > Technically speaking, these two URLs are NOT the same: > > http://example.com/foo > http://example.com/foo/ > > and a webserver could technically serve up different content for the two > requests. But RFC-3986, section 6.2.3 states that the following are the > same for http: > > http://example.com > http://example.com/ > > The question you are asking is---are the these two examples the same for > Gemini? > > gemini://example.com > gemini://example.com/ Exactly. > Again, per RFC-3986, they are (unless some document describing Gemini URLs > states otherwise). I naturally assumed they would be as they are for HTTP. > That's perhaps an unwarrented assumption, but I would have to think the two > *are* the same, because of the nature of URLs. > > The *only* character that can follow the authority section (hostname, > port, etc) of a URL is the slash. There is no other valid character that > can go there. So while it is possible for a Gemini server to serve up two > different resources for the example above, that would, in my opinion, > violate the rule of least surprise. Even with gopher URLs, RFC-4266, > section 2.1 says the following are the same: > > gopher://example.com > gopher://example.com/ > gopher://example.com/1 > > The slash between the authority section and the selector is required not > only by URL parsing rules, but because there are alphaebtic gopher types. > Also, RFC-1436 (Introduction) states that gopher selectors are opaque and > have no meaning, so the following two are distinct resources: > > gopher://example.com/1 > gopher://example.com/1/ > > Addtionally, these *are* already covered by RFC-3986 (first example > above), but I digress. So while technically what you say is true (two > different resources) I would recommend against it (rule of least surprise). This is all tremendously helpful and clear. I agree with semantic equivalence of "" and "/" filenames or filenames being the optimal behaviour for servers. Servers are always free to be relaxed about what they accept, but clients need to take care that they don't make assumptions that may not always be true. In elpher I'm very picky about the gopher selector portion of the URL. I map both gopher://example.com and gopher://example.com/ to gopher://example.com/1, but *never* presume to alter anything after the selector type character. So gopher://example.com/1 is *never* converted to gopher://example.com/1/ or vice versa. For gemini I currently map gemini://example.com to gemini://example.com/ on parsing, but (besides dot segment conversions) never alter anything else. (Whether servers treat gemini://example.com/file and gemini://example.com/file/ as equivalent is none of the client's business.) > With that out of the way, I do handle the lack of a trailing slash with > the request <gemini://gemini.conman.org> in GLV-1.12556 by sending out a > redirect. I think mine is the only server that actually does something > different than serve up the top level page [1]. I also do that for any > requests that map to a directory that don't end in a slash [2]. Yes, I noticed this when implementing redirects on the client side. Elpher shouldn't be asking for "" anymore though. > -spc (Did this answer your question?) Very clearly. Thank you for your patience! plugd
---
Previous in thread (13 of 15): 🗣️ Sean Conner (sean (a) conman.org)
Next in thread (15 of 15): 🗣️ plugd (plugd (a) thelambdalab.xyz)