Background reading: => https://alistapart.com/article/slashforward/ In the above article, Dan Bogan makes a case for adding slashes to the end of all URLs.? I thought it was convincing, so that's how I've been rolling for years. One of my current favorite Gemini clients, by default, alerts the user when following a link and gives the user an option to continue or abort the navigation. One of the capsules I visit from both CAPCOM and Spacewalk has links that are all trailing-slashless. Not only are the links in CAPCOM/Spacewalk slashless, but the intra-capsule links are as well. Should I be sending a polite change request to the author of the capsule, to the maintainer of the Gemini client, to both, or neither? At least with the Gemini client, I could send along a patch to change the default. ---- ? Time and CMS changes have not been good to the article. You'll need to hover over the links in the code snippets and look at your link-preview bar/popup to see what he's talking about.
That might be me. I am already aware of Bogan's case, I read it back in 2002. I find the arguments for slashless more convincing than the arguments against. Please just change that setting in the client. Thank you? mailinglists at ngalt.com writes: > Background reading: > > => https://alistapart.com/article/slashforward/ > > In the above article, Dan Bogan makes a case for adding slashes to the end of all URLs.? I thought it was convincing, so that's how I've been rolling for years. > > One of my current favorite Gemini clients, by default, alerts the user when following a link and gives the user an option to continue or abort the navigation. > > One of the capsules I visit from both CAPCOM and Spacewalk has links that are all trailing-slashless. Not only are the links in CAPCOM/Spacewalk slashless, but the intra-capsule links are as well. > > Should I be sending a polite change request to the author of the capsule, to the maintainer of the Gemini client, to both, or neither? At least with the Gemini client, I could send along a patch to change the default. > > ---- > > ? Time and CMS changes have not been good to the article. You'll need to hover over the links in the code snippets and look at your link-preview bar/popup to see what he's talking about.
It was thus said that the Great Sandra Snan once stated: > That might be me. > > I am already aware of Bogan's case, I read it back in 2002. > I find the arguments for slashless more convincing than the arguments against. I'm curious as to what the argument against is, because the slash is semantically important. => gemini://gemini.conman.org/test/doc1 This is not a directory. => gemini://gemini.conman.org/test/doc1/ And this is not the document you think it is See, this topic came up earlier this year: https://lists.orbitalfox.eu/archives/gemini/2020/001998.html And then there's the reason for the tailing slash that Solderpunk gives: https://lists.orbitalfox.eu/archives/gemini/2020/002000.html The whole thread starts here: https://lists.orbitalfox.eu/archives/gemini/2020/001964.html -spc
mailinglists at ngalt.com writes: > It was. Thank you so much for reading my stuff?? Much apprec? > I'd be _very_ happy to read arguments in favor of slashless. It is a way to write future-proof links that work on both dynamic and static content. This is a site that has survived several CMS changes and has been up with the same look for 11 years. Earlier version of Jekyll allowed slashless without redirecting, not sure how it worked but it stopped working so I've altered my nginx conf to just serve them as directories with index.html files, and Molly of course has index.gmi out of the box. I didn't want to change my linking style from the old site in the hopes that one day I'll have a CMS that once more has slashless URLs. The _counter_ argument to that, then, is that dynamic url routers could be configured to add faux slashes back in to match. And that's a good counter-argument. Anything you can do to make your site consistent is good. And the dynamic portion of my site (the Fedi frontent) currently does allow faux trailing slashes. Bogan's text was written in 2002 and his own site has, as you point out, had some rough times when it comes to consistency: > Time and CMS changes have not been good to the article. You'll need to > hover over the links in the code snippets and look at your > link-preview bar/popup to see what he's talking about. He wrote that before nginx came out, in the Apache era. Nginx just serves the file right up without a bunch of redirects (hopefully?I haven't triple checked that). Now, I do appreciate you alerting me that Molly does do the similar shenanigans that Bogan describes: > Just a minute; first I?ll try to find a file called ?subdirectory.? ? > Wait a second; it?s not there! How about a directory called > ?subdirectory?? ? Ah, here we go. Okay. And next time, please use a > trailing slash. That's something I would hope could change in future versions of Molly. Also, my capsule might not always be on Molly. (Even though it's a fantastic server.?) The bottom line is that the indented external semantics is that requests are asking for content, and those requests should be separated from the specific implementation, such as file system representation.
The client can do whatever it wants, and people can link to you in arbitrary ways. > I could send along a patch to change the default While it might be more ergonomic to only alert the user if the redirect is changing origin, there is nothing inherently wrong with alerting for every redirect. Even if you send a patch to fix (a non-broken) default for that client, there is no guarantee that people don't change the default or simply use different clients. > Should I be sending a polite change request to the author of the capsule You can email the capsule author, but from their perspective, you are making a needless change to a working URL. The correct way to handle this situation is to either keep redirecting and stop caring about how different clients handle it, or to stop redirecting and give a not found error and le people link you correctly.
Hi folks, I am the author of a Gemini server called Space Age. => https://gitlab.com/lambdatronic/space-age/ When I submitted my server for inclusion on the "Gemini software" list (gemini://gemini.circumlunar.space/software/), Solderpunk wrote to me to explicitly verify that my server redirected clients who requested slashless URLs to their slashed equivalents. He pointed out that any relative URLs in the returned Gemtext would not behave as expected in most clients when navigating away from a slashless parent page. Therefore, server redirection of slashless URLs was mandatory for Gemini servers. Given this requirement, I believe the standing recommendation to authors of Gemtext pages is to always include slashes in your links in order to prevent page redirects and speed up loading time for your users. Now you know, and knowing is half the battle! Happy hacking, Gary Sandra Snan <sandra.snan at idiomdrottning.org> writes: > mailinglists at ngalt.com writes: >> It was. > > Thank you so much for reading my stuff?? > Much apprec? > >> I'd be _very_ happy to read arguments in favor of slashless. > > It is a way to write future-proof links that work on both dynamic and > static content. > > This is a site that has survived several CMS changes and has been up > with the same look for 11 years. > > Earlier version of Jekyll allowed slashless without redirecting, not > sure how it worked but it stopped working so I've altered my nginx conf > to just serve them as directories with index.html files, and Molly of > course has index.gmi out of the box. I didn't want to change my linking > style from the old site in the hopes that one day I'll have a CMS that > once more has slashless URLs. > > The _counter_ argument to that, then, is that dynamic url routers could > be configured to add faux slashes back in to match. And that's a good > counter-argument. Anything you can do to make your site consistent is > good. And the dynamic portion of my site (the Fedi frontent) currently > does allow faux trailing slashes. > > Bogan's text was written in 2002 and his own site has, as you point out, > had some rough times when it comes to consistency: >> Time and CMS changes have not been good to the article. You'll need to >> hover over the links in the code snippets and look at your >> link-preview bar/popup to see what he's talking about. > > He wrote that before nginx came out, in the Apache era. Nginx just > serves the file right up without a bunch of redirects (hopefully?I > haven't triple checked that). > > Now, I do appreciate you alerting me that Molly does do the similar > shenanigans that > > Bogan describes: >> Just a minute; first I?ll try to find a file called ?subdirectory.? ? >> Wait a second; it?s not there! How about a directory called >> ?subdirectory?? ? Ah, here we go. Okay. And next time, please use a >> trailing slash. > > That's something I would hope could change in future versions of Molly. > > Also, my capsule might not always be on Molly. (Even though it's a > fantastic server.?) > > The bottom line is that the indented external semantics is that requests > are asking for content, and those requests should be separated from the > specific implementation, such as file system representation. -- GPG Key ID: 7BC158ED Use `gpg --search-keys lambdatronic' to find me Protect yourself from surveillance: https://emailselfdefense.fsf.org ======================================================================= () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Please avoid sending me MS-Office attachments. See http://www.gnu.org/philosophy/no-word-attachments.html
When I was creating my Gemini client for MacOS, I actually had some difficulty with this. The default Swift URL library automatically removes the slash from the end of a path when you?re converting from a string. It took me some effort to get it working properly for Gemini links - I ended up creating my own GeminiURL struct that puts the slashes back at the end of the path. Peter > On Sep 18, 2020, at 5:02 AM, mailinglists at ngalt.com wrote: > > Background reading: > > => https://alistapart.com/article/slashforward/ > > In the above article, Dan Bogan makes a case for adding slashes to the end of all URLs.? I thought it was convincing, so that's how I've been rolling for years. > > One of my current favorite Gemini clients, by default, alerts the user when following a link and gives the user an option to continue or abort the navigation. > > One of the capsules I visit from both CAPCOM and Spacewalk has links that are all trailing-slashless. Not only are the links in CAPCOM/Spacewalk slashless, but the intra-capsule links are as well. > > Should I be sending a polite change request to the author of the capsule, to the maintainer of the Gemini client, to both, or neither? At least with the Gemini client, I could send along a patch to change the default. > > ---- > > ? Time and CMS changes have not been good to the article. You'll need to hover over the links in the code snippets and look at your link-preview bar/popup to see what he's talking about.
On 18-Sep-2020 11:20, Leo wrote: > The client can do whatever it wants, and people can link to you in > arbitrary ways. > >> I could send along a patch to change the default > > While it might be more ergonomic to only alert the user if the > redirect is changing origin, > there is nothing inherently wrong with alerting for every redirect. > Even if you send a patch to > fix (a non-broken) default for that client, there is no guarantee that > people don't change the > default or simply use different clients. > >> Should I be sending a polite change request to the author of the capsule > > You can email the capsule author, but from their perspective, you are > making a needless change to a > working URL. The correct way to handle this situation is to either > keep redirecting and stop caring > about how different clients handle it, or to stop redirecting and give > a not found error and le > people link you correctly. > I largely agree. Whilst Gemini clearly has some differences from the web in this regard, for me this is an area of functionality where we should do by and large the same as the web. Both are path and text based hypertext systems and authors expectations will be already established. Personally I think there is no reason for a client to request permission for a redirect to another page on the same server. If the main concern is a "silent" traversal from a known location to an unknown one, a better fix is for the client to indicate the traversal, but not require an action from the user In my own client GemiNaut it is obvious when you traverse from one domain to another as the theme changes, so there is never a case that the user is silently and unknowably redirected. Other clients without such a clear visual distinction between domains might think a user interaction is sensible. However, bear in mind that from a UI design point of view, interrupting the user to require them to click a button or press "OK" (or equivalent) is generally a sort of last resort to be avoided, because it brings them back into focus of the software tool, rather than focussing on their task at hand or their train of thought. I don't think Gemini clients ought to always interrupt the user upon a server request. As usual with these things, it is finding a balance between visibility of system action, security considerations, usability and personal preference. Best wishes - Luke
Perhaps an obvious typo fix, I meant to type: "I don't think Gemini clients ought to always interrupt the user upon a server [redirect]". On 19-Sep-2020 10:11, Luke Emmet wrote: > I don't think Gemini clients ought to always interrupt the user upon a > server request.
> Whilst Gemini clearly has some differences from the web > in this regard, for me this is an area of functionality where we should > do by and large the same as the web. Using the web does not mean redirections happen seamlessly, or happen at all. Users can have their browsers alert for redirects, or simply not follow redirects. The HTTP spec seems to support this use case as well. > If a Location header field is provided, the user agent MAY > automatically redirect its request to the URI referenced by the > Location field value and also at > The server SHOULD generate a Location header field in the response > containing a URI reference for the different URI. The user agent MAY > use the Location field value for automatic redirection. So common web browsers, like common gemini browsers, might redirect seamlessly, but "User Agents" (instead of popular software that are agents of someone else) still reserve the right to ask the user what to do at any point.
On 19-Sep-2020 11:47, Leo wrote: > > Using the web does not mean redirections happen seamlessly, or happen at > all. Users can have their browsers alert for redirects, or simply not > follow redirects. The HTTP spec seems to support this use case as well. I don't know of any web client that generally implements browser alerts for redirects. Maybe they do exist though, or perhaps you can configure them to do so. > So common web browsers, like common gemini browsers, might redirect > seamlessly, but "User Agents" (instead of popular software that are > agents of someone else) still reserve the right to ask the user > what to do at any point. I get your shift of emphasis here, but a Gemini client is a user agent (as is a web browser) in the protocol sense - it retrieves content on behalf of a user request. The web is so complex that most end users are not in a position to control the fine grained behaviour, beyond a few preferences here and there. Although in Firefox there are more parameters you can configure if you are willing to delve in about:config. Due to its simplicity, one of the nice things about Gemini is the wide choice of clients. And of course the barriers to writing your own client that implements exactly the behaviour you want are much lower. Best Wishes - Luke
I forgot to add that the reason I switched to foo/index.gmi from foo.gmi is because I put .molly files in the foo that sets the lang (iff the lang is not the site default).
Revisiting this issue, I want to clarify what my position was and is. Bogan's case is that you don't want to be doing a bunch of 301s&31s from unslashed to slashed all day every day. I agree with that, and my site was definitely borked (both on HTTPS and Gemini) for being set up to do just that. Bogan's solution is that you add slashes to links. I am not onboard with that solution but have now found another solution. Instead of 301/31, the unslashed versions will now serve the text directly. This is what I intended all along, I just could not figure out how to do it properly because I am secretly really bad at computers^W being motivated to hack on server stuff. In the future I might add 301/31 from slashed to unslashed, since that's the canonical version. That's a project for another day though. Thanks to everyone for their patience with how messed up my capsule has been. Sandra Sandra Snan <sandra.snan at idiomdrottning.org> writes: > That might be me. > > I am already aware of Bogan's case, I read it back in 2002. > I find the arguments for slashless more convincing than the arguments against. > > Please just change that setting in the client. > > Thank you? > > > > mailinglists at ngalt.com writes: > >> Background reading: >> >> => https://alistapart.com/article/slashforward/ >> >> In the above article, Dan Bogan makes a case for adding slashes to the end of all URLs.? I thought it was convincing, so that's how I've been rolling for years. >> >> One of my current favorite Gemini clients, by default, alerts the user when following a link and gives the user an option to continue or abort the navigation. >> >> One of the capsules I visit from both CAPCOM and Spacewalk has links that are all trailing-slashless. Not only are the links in CAPCOM/Spacewalk slashless, but the intra-capsule links are as well. >> >> Should I be sending a polite change request to the author of the capsule, to the maintainer of the Gemini client, to both, or neither? At least with the Gemini client, I could send along a patch to change the default. >> >> ---- >> >> ? Time and CMS changes have not been good to the article. You'll need to hover over the links in the code snippets and look at your link-preview bar/popup to see what he's talking about.
Please correct me if I'm wrong. I believe that the original intent behind discouraging silent redirects was to avoid dark patterns such as tracking re-directs and short URLs made with the intent to hide the target (popular for Rickrolling and shock content). If my above understanding is correct, then adding a trailing slash shouldn't be problematic. This should be clarified in the documentation. -- /Seirdy
That could still be a hidden infinite redirect (from unslashed to slashed to unslashed to slashed to unslashed to slashed to unslashed to slashed to etc). IDK, I feel both bad at having my capsule messed up for so long and also happy that I finally sorted it out. Now unslashed links work as they should i.e. gemini://idiomdrottning.org/texts gives you some texts instead of a 31 response. Rohan Kumar <seirdy at seirdy.one> writes: > Please correct me if I'm wrong. > > I believe that the original intent behind discouraging silent redirects > was to avoid dark patterns such as tracking re-directs and short URLs > made with the intent to hide the target (popular for Rickrolling and > shock content). > > If my above understanding is correct, then adding a trailing slash > shouldn't be problematic. This should be clarified in the documentation. > > -- > /Seirdy
It was thus said that the Great Sandra Snan once stated: > Revisiting this issue, I want to clarify what my position was and is. > > Bogan's case is that you don't want to be doing a bunch of 301s&31s from > unslashed to slashed all day every day. > > I agree with that, and my site was definitely borked (both on HTTPS and > Gemini) for being set up to do just that. > > Bogan's solution is that you add slashes to links. > > I am not onboard with that solution but have now found another solution. > Instead of 301/31, the unslashed versions will now serve the text > directly. > > This is what I intended all along, I just could not figure out how to do > it properly because I am secretly really bad at computers^W being > motivated to hack on server stuff. > > In the future I might add 301/31 from slashed to unslashed, since that's > the canonical version. That's a project for another day though. > > Thanks to everyone for their patience with how messed up my capsule has > been. There's a semantic difference between a URL that ends with a '/' and one that doesn't. The one that ends with a '/' is semantically a directory, and to have to add a file per directory to get all URLs to end with a '/' is, in my opinion, silly. I can see what you are trying to do---skip the silly ".gmi" or ".gemini" extension as being part of the URL, but there should be better ways of doing that that populating a filesystem with a bunch of directories containing a single file (I may do a proof-of-concept with extensionless files---no, wait! I alreay have that---the individual tests under the Gemini Client Torture Test!) Furthermore, if you follow this link, sans a trailing '/': gemini://gemini.conman.org/test/UCSD-Pascal-source.zip you'll get a ZIP file. But, add a trailing '/' to that: gemini://gemini.conman.org/test/UCSD-Pascal-source.zip/ and see what you get (hint: it's not a ZIP file) -spc
Sean wrote: > There's a semantic difference between a URL that ends with a '/' and one > that doesn't. The one that ends with a '/' is semantically a > directory Yes. That's why I removed the slashes and why I all along wanted the slashes gone. Sean wrote: > that doesn't. The one that ends with a '/' is semantically a directory, and > to have to add a file per directory to get all URLs to end with a '/' is, in > my opinion, silly. I can see what you are trying to do---skip the silly > ".gmi" or ".gemini" extension as being part of the URL, but there should be > better ways of doing that that populating a filesystem with a bunch of > directories containing a single file It seems like you've got what I want to do somewhat backwards. You seem to think that I want URLs that end with slashes, i.e. has directory semantics. That's what I don't want. That's why my internal links all along have been without slashes. That's why I finally fixed the long-standing 31 issue. And I needed to do programming to do so which is what I didn't wanna do in the first place. Ugh. You guys roped me in to doing actual work. The server-side technical implementation behind serving up, for example, "The Dumbphone Experience" text at gemini://idiomdrottning.org/dumbphone-experience should not matter for users. As far as they're concerned, that's a leaf node named dumbphone-experience placed in the capsule root. That's the semantics I want and that's the semantics I've got now. Jolly good. (On the server side, I could implement that in a couple of ways; I need the server to be able to distinguish the page from other files (for example I also host images, and plain text files) so on the server side, I need to set up a naming scheme like dumbphone-experience.gmi, dumbphone-experience.gemini, or dumbphone-experience/index.gmi and then use server rewriting to serve up the correct node. It's wholly irrelevant on the client side which of those three is in use (I'm not mixing the three models, I use one of them). They get a file named dumbphone-experience with the text/gemini MIME type which is what they wanted. Turns out that in order to get different languages for different pages?which was the first thing I wanted to do on this list back in August 2020?and this particular server, it's easier to use dumbphone-experience/index.gmi because then I can also put metadata in the same directory. Since I needed to reprogram the server anyway, I could've come up with some cockamamie convention to get per-file metadata, like dumbphone-experience.gemini and dumbphone-experience.metadata both in the same folder and then serve that as dumbphone-experience. Or have preambles that the server strips. I coulda done it in all tons of ways. Does not matter to clientside which way I did it.) Sean wrote: > Furthermore, if you follow this link, sans a trailing '/': > > gemini://gemini.conman.org/test/UCSD-Pascal-source.zip > > you'll get a ZIP file. But, add a trailing '/' to that: > > gemini://gemini.conman.org/test/UCSD-Pascal-source.zip/ > > and see what you get (hint: it's not a ZIP file) > > -spc You posted the same argument in the same kinda patronizing way last September: Sean wrote, but way earlier: > I'm curious as to what the argument against is, because the slash is > semantically important. > > => gemini://gemini.conman.org/test/doc1 This is not a directory. > => gemini://gemini.conman.org/test/doc1/ And this is not the document you think it is Semantics is my jam. Do not try to bring the ruckus vs Idiomdrottning on this. Sean wrote: > And then there's the reason for the tailing slash that Solderpunk gives: > > https://lists.orbitalfox.eu/archives/gemini/2020/002000.html Solderpunk is awesome.?? But he is wrong about this. Solderpunk writes: > It might *seem* dumb, but it's essential for relative URLs to work > correctly. They work correctly when there is a consistent view which tree nodes are leaf nodes. Solderpunk writes: > Links in text/gemini may be relative URLs, e.g. just > "other_page.gmi". It's the client's job to turn that into an absolute > URL, in accordance with the RFC rules for doing so. If you are at > "gemini://example.com/foo", then that relative link turns into > "gemini://example.com/other_page.gmi" Which is fine. It's just that foo is a leaf node. That's what I want. The semantics work, it's just one level up. True, relative links don't work when you have slashed and unslashed both working. Because they'll be at different "levels" in the tree. So before I add any relative links to my pages, I'll need to put in the 31s from slashed to unslashed (which is the direction they should've been going all along) so there's only one canonical URL for each page. Sandra
Sandra Snan <sandra.snan at idiomdrottning.org> writes: > Sean wrote: >> that doesn't. The one that ends with a '/' is semantically a directory, and >> to have to add a file per directory to get all URLs to end with a '/' is, in >> my opinion, silly. I can see what you are trying to do---skip the silly >> ".gmi" or ".gemini" extension as being part of the URL, but there should be >> better ways of doing that that populating a filesystem with a bunch of >> directories containing a single file This is what I wrote back then: Sandra Snan <sandra.snan at idiomdrottning.org> writes: > This is what I just implemented using Molly. > I had to put every gmi file in its own directory :( > Not really what I wanted but at least now files have the right lang. > That's important to people using screen readers. Your own suggestion in that same thread had been that I should add a custom Lua program. I replied: > I don't mind writing some Lua, Go, CL or any other language but that > kinda fiddling will have to go on the back burner for now. Every suggestion to "How do I set different langs for different gmi files" was that I had to do programming. And that's what I ended up having to do now. Even with Molly I ended up having to program, eventually, because of this 31 slash issue. I originally had URLs like gemini://idiomdrottning.org/texts.gmi and gemini://idiomdrottning.org/images.gmi (those URLs will continue to get updates for ever, don't worry Spacewalk fans). Sure, extensionless would've looked nicer, but I don't wanna jump through hoops just to get rid of four characters for vanity. I had to put them in separate directories because of the languages. (Or I would've? had to use GLV-1.12556 ?.) And the semantics of slashed URLs is that people are requesting a file named "" and that's dorky enough that I'll walk through the fire and the flames to fix. Can't have that. Sandra
On 13-Feb-2021 00:09, Sean Conner wrote: > >> There's a semantic difference between a URL that ends with a '/' and one >> that doesn't. The one that ends with a '/' is semantically a directory, and >> to have to add a file per directory to get all URLs to end with a '/' is, in >> my opinion, silly. I can see what you are trying to do---skip the silly >> ".gmi" or ".gemini" extension as being part of the URL, but there should be >> better ways of doing that that populating a filesystem with a bunch of >> directories containing a single file (I may do a proof-of-concept with >> extensionless files---no, wait! I alreay have that---the individual tests >> under the Gemini Client Torture Test!) It may seem like there is a "natural" difference between these two URL forms, but as far as I understand it the semantics of any URL path segment is opaque and determined by the server. The path is an opaque string whose semantics is not intrinsically discernable. There may be no files or directories involved whatsoever. It happens that there is a simple sort of implementation to serve a folder of files in this way, but that is by no means a universal URL path semantics that we can make inferences about. gemini://server/foo may or may not serve the same content as gemini://server/foo/ or it can redirect there. Either way it is up to the server to determine the semantics of the resource. Clean and simple URLs are nice for end users, and maybe authors too. But that's the main reason we all strive for a simple URL structure. Regards - Luke
Luke wrote: > It may seem like there is a "natural" difference between these two URL > forms, but as far as I understand it the semantics of any URL path > segment is opaque and determined by the server. The path is an opaque > string whose semantics is not intrinsically discernable. > > There may be no files or directories involved whatsoever. It happens > that there is a simple sort of implementation to serve a folder of files > in this way, but that is by no means a universal URL path semantics that > we can make inferences about. > > gemini://server/foo may or may not serve the same content as > gemini://server/foo/ or it can redirect there. Either way it is up to > the server to determine the semantics of the resource. I don't wanna disagree with someone who is in my own corner on this?, but? It's tree semantics, which is evidenced in practice by the way relative links work. (Especially since .. and co exist). A link to bar/baz from gemini://server/foo leads to gemini://server/bar/baz while a link to bar/baz from gemini://server/foo/ leads to gemini://server/foo/bar/baz. I've now implemented 31s and 301s from the slashed to unslashed so now I can start using relative links again. Except they'll have to be written to reflect the reality that /foo is a leaf node and not a directory node, i.e. the leaf node is no longer a file named "" (the empty string). It's also something that might be good to reflect in culture and convention. I could see if, for example "gemini://medusae.space/index.gmi?20", instead had the url been gemini://medusae.space/home/cooking/index.gmi, how that would make sense in some way. I've kept my own web page & capsule having all flat URLs in one huge name space for a while. It's a tradeoff? Sandra
On 16-Feb-2021 20:58, Sandra Snan wrote: > I don't wanna disagree with someone who is in my own corner on this?, > but? Its an interesting topic - and I'm sure there is a lot of prior thought on this we get to rehash for fun here. > It's tree semantics, which is evidenced in practice by the way relative > links work. (Especially since .. and co exist). Yes I do agree the relative link resolving semantics are tree-like, but that's all, and its not much. Relative path creation is a server side act so the URL semantics is still determined by the server/content author. I was thinking more in terms of the content or URL semantics as in what is the expected meaning of the "parent" fragment in respect of the "child" The content semantics may not be tree like in the pleasant way we see when serving a file system file and folder structure. /foo/ may not be any kind of meaningful container of /foo/bar and foo/baz - we can't assume it is the more generic location. We may imagine a perfectly valid URL /westminster/london/uk - that might make sense for a certain type of application. It is sort of upside down from a classical geographic point of view, so the domain semantics may not map onto the url fragmentation. That is sort of what I had in mind, that we cannot infer much about the domain semantics from the url structure. Similarly an opaque URL /dhjksfl/sueyug/sodfye - its only tree like in respect of relative path resolution. The domain semantics of the path fragments in this case are almost completely opaque. /foo/bar/baz may seem to have more semantics, but it has the same behaviour. Hence I do think this is in the realm of pragmatics of use and conventions. We like to look at a URL and hope it is more sensible - and some clients implement an "up" feature to go up the path. But what you get in general as you do so is anyone's guess. But day to day conventions and pragmatics usually are strong enough that this sort of thing usually works. Regards ?- Luke
Luke Emmet <luke at marmaladefoo.com> writes: > We may imagine a perfectly valid URL /westminster/london/uk - that > might make sense for a certain type of application. Right. And going to ../ontario or ../france or ../belgrade might be legit links from the UK London to other Londons because it's a tree. And ../../memphis/tennessee for another Westminster. Because it's a tree. But I still feel you're in my corner when it comes to making my capsule structure flat. I ended up not sending more than half of my last email because it strayed off topic a bit (and this lists gets enough rants as it is) but gemini://idiomdrottning.org/page-vs-capsule
I never saw this reply (from last September!) Gary Johnson <lambdatronic at disroot.org> writes: > When I submitted my server for inclusion on the "Gemini software" list > (gemini://gemini.circumlunar.space/software/), Solderpunk wrote to me to > explicitly verify that my server redirected clients who requested > slashless URLs to their slashed equivalents. He pointed out that any > relative URLs in the returned Gemtext would not behave as expected in > most clients when navigating away from a slashless parent page. > Therefore, server redirection of slashless URLs was mandatory for Gemini > servers. > > Given this requirement, I believe the standing recommendation to authors > of Gemtext pages is to always include slashes in your links in order to > prevent page redirects and speed up loading time for your users. Maybe it's wrong to call it slashless and more correct to call it dotless. Links on gemini://some.url/foo/bar/baz will act as if the page was gemini://some.url/foo/bar/baz.gmi rather than as if the page was gemini://some.url/foo/bar/baz/_.gmi I've now updated mdna to 31 slashed to slashless. Having both resolve to the same page is what creates the ambiguity. => mdna gemini://idiomdrottning.org/molly-brown > Now you know, and knowing is half the battle! > > Happy hacking, > Gary I love this signoff?
It was thus said that the Great Sandra Snan once stated: > Luke Emmet <luke at marmaladefoo.com> writes: > > We may imagine a perfectly valid URL /westminster/london/uk - that > > might make sense for a certain type of application. > > Right. And going to ../ontario or ../france or ../belgrade might be > legit links from the UK London to other Londons because it's a tree. > And ../../memphis/tennessee for another Westminster. Because it's a tree. > > But I still feel you're in my corner when it comes to making my capsule > structure flat. I ended up not sending more than half of my last email > because it strayed off topic a bit (and this lists gets enough rants as > it is) but gemini://idiomdrottning.org/page-vs-capsule Of the two clients I use (generally portal.mozz.us but sometimes the simple one I wrote), this link causes them to fail: gemini://idiomdrottning.org/ Namely because both these clients get a redirection to: gemini://idiomdrottning.org but both clients will always send: gmeini://idiomdrottning.org/ (well, I can speak for my own client which does that, I suspect that's what's happening for portal.mozz.us). There's language in RFC-3986 about this particular case (section 6.2.3). -spc
On Tue, Feb 16, 2021 at 8:53 PM Sean Conner <sean at conman.org> wrote: > Of the two clients I use (generally portal.mozz.us but sometimes the > simple one I wrote), this link causes them to fail: > > gemini://idiomdrottning.org/ > > Namely because both these clients get a redirection to: > > gemini://idiomdrottning.org > > but both clients will always send: > > gmeini://idiomdrottning.org/ > > (well, I can speak for my own client which does that, I suspect that's > what's happening for portal.mozz.us). There's language in RFC-3986 about > this particular case (section 6.2.3). > > -spc I just pushed an update to the portal.mozz.us proxy to fix this. Actually the code was already in place, but my web framework was doing an automatic redirect on the missing slash to try to be helpful :/ The following URL should now work without re-adding a trailing slash. https://portal.mozz.us/gemini/idiomdrottning.org Your point is well taken though. gemini://example.com and gemini://example.com/ are canonically the same resource and should always return the same response. It took me a while to understand this but I now see the light. - Michael
Thank you for pointing out the root node special case. Hopefully fixed now. I had missed 6.2.3. Thank you for pointing that to me; that saved me some headaches on my HTTPS homepage as well.
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.)
On 17-Feb-2021 01:27, Sandra Snan wrote: > Luke Emmet <luke at marmaladefoo.com> writes: >> We may imagine a perfectly valid URL /westminster/london/uk - that >> might make sense for a certain type of application. > But I still feel you're in my corner when it comes to making my capsule > structure flat. I ended up not sending more than half of my last email > because it strayed off topic a bit (and this lists gets enough rants as > it is) but gemini://idiomdrottning.org/page-vs-capsule I'm in the camp that you should have whatever structure you like :) On the web I prefer simple flat-ish URL structures, probably without even any file extension. A lot of URLs expose the innards of the site (cgi-bin, *.php) implementation that is orthogonal to the URL and content naming, and I put file extensions in that bracket. How many of our visitors need to know what some site is implemented in, or it it is a database, or built from a static site generator? That is what Apache mod_rewite was made for. Personally I'm a bit more torn about this in Gemini, as the landscape is much more spartan. Having a link end *.pdf gives readers a very good hint as to the content at the end of the URL and it helps me make a choice - do I want to click that thing or not? Also clients can provide certain UI hints or decorations to suggest the likely content of the link with some basic URL heuristics. So in Gemini, I prefer to see a file extension in the URL. Similarly clients can implement a simple "Up" feature which means any page does not need this intrinsic navigation. All assuming the author maps their content onto the URL structure in a sensible way. As a visitor, we cannot expect URLs to implement any sort of tree structure, but in practice they usually do and we can traverse up and down the URL architecture as well as by following the authored links. For me this is the pragmatics of URLs. ?- Luke
On Wed, Feb 17, 2021 at 11:37:52AM +0000, Luke Emmet <luke at marmaladefoo.com> wrote a message of 40 lines which said: > A lot of URLs expose the innards of the site (cgi-bin, *.php) > implementation This is widely recognized as a very bad practice since, should you change implementation (moving from PHP to Node?), the URL would change, which is bad <https://www.w3.org/Provider/Style/URI> > Having a link end *.pdf gives readers a very good hint as to the > content at the end of the URL and it helps me make a choice Sure, but this is a very different case. The extension is about the content, not about how it was generated/served. > As a visitor, we cannot expect URLs to implement any sort of tree > structure, but in practice they usually do and we can traverse up > and down the URL architecture as well as by following the authored > links. For me this is the pragmatics of URLs. I agree that, for the visitor, it is better. I certainly prefer sites where you visit <gemini://guide.example/france/paris> and can edit the URL in the address bar to go to <gemini://guide.example/france/>, expecting something more general about France. As you know (but it may be worth repeating), RFC 3986 does not mandate that this works. Paths are mostly opaque. You cannot rely on it, but I find it cool, and a Good Practice.
On 17-Feb-2021 11:37, Luke Emmet wrote: > So in Gemini, I prefer to see a file extension in the URL. To clarify - for linked resources in gemini (png/jpg/pdf/mp3 etc) - just show me the extension of every other type that is linked to. I can make a calculation whether to activate the target or not. Might it be large or slow, will it launch some other application etc. For the primary nodes and default content type of the gemini hypertext (text/gemini) I just need the name of the thing, and I don't need to know how it was generated. ?- Luke
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2/12/2021 4:09 PM, Sean Conner wrote: > It was thus said that the Great Sandra Snan once stated: >> Revisiting this issue, I want to clarify what my position was and >> is. >> >> Bogan's case is that you don't want to be doing a bunch of >> 301s&31s from unslashed to slashed all day every day. >> >> I agree with that, and my site was definitely borked (both on >> HTTPS and Gemini) for being set up to do just that. >> >> Bogan's solution is that you add slashes to links. >> >> I am not onboard with that solution but have now found another >> solution. Instead of 301/31, the unslashed versions will now >> serve the text directly. >> >> This is what I intended all along, I just could not figure out >> how to do it properly because I am secretly really bad at >> computers^W being motivated to hack on server stuff. >> >> In the future I might add 301/31 from slashed to unslashed, since >> that's the canonical version. That's a project for another day >> though. >> >> Thanks to everyone for their patience with how messed up my >> capsule has been. > > There's a semantic difference between a URL that ends with a '/' > and one that doesn't. The one that ends with a '/' is semantically > a directory, and to have to add a file per directory to get all > URLs to end with a '/' is, in my opinion, silly. I can see what > you are trying to do---skip the silly ".gmi" or ".gemini" extension > as being part of the URL, but there should be better ways of doing > that that populating a filesystem with a bunch of directories > containing a single file (I may do a proof-of-concept with > extensionless files---no, wait! I alreay have that---the > individual tests under the Gemini Client Torture Test!) > > Furthermore, if you follow this link, sans a trailing '/': > > gemini://gemini.conman.org/test/UCSD-Pascal-source.zip > > you'll get a ZIP file. But, add a trailing '/' to that: > > gemini://gemini.conman.org/test/UCSD-Pascal-source.zip/ > > and see what you get (hint: it's not a ZIP file) > Apologies for not trimming, I just left all of that intact above. Hey Sean, we've been down this road well over a year ago, 14 September 2019 here on the list. Very early on in Gemini development. You are correct, by why are we revisiting this again? Perhaps just a link to the Subject thread: *URLs in request lines*, would suffice? I'll make it simple ;) Here it is, from a post of mine, citing you, in the middle of the thread back when we had less than a dozen servers in Gemini space :) https://lists.orbitalfox.eu/archives/gemini/2019/000160.html I hope that helps! Kindest regards, - -- Bradley D. Thornton Manager Network Services http://NorthTech.US gemini://Vger.Cloud TEL: +1.310.421.8268 -----BEGIN PGP SIGNATURE----- Comment: Find this cert at hkps://keys.openpgp.org Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQEzBAEBCAAdFiEENWT7St9Eg6sLyiLAuIw5wQytyEkFAmAvywkACgkQuIw5wQyt yElh7gf/YFN114gnrZXY16fGZ35gZBnYeSdAOWf9vYlo2FKTYvdVORRx2I/4Tyhh KbP6uaFTZ5lJMJ40HLtNDX0+UqKwFqm+d2i2/sRl6mRJWOmDDDDgccM4VPMaqGD/ n5BxhTnuKev8MJTNioT1GA/JclWMszTj12TufvHN7OJNDUQqjZDekJgjXccrlbaN c+2ZGg1EgPKLPBX2TIgSOGlJkh7scNyXPehX+g2Tg7mXOZEgJ3a4D03enYWqj4vD uAlAu3CPlSsgxKK+tSBH83anuOvk/IVEhu4DHj9ZLvlH7awdE2EpJ++64YKCSqDT UMyoz9IXBlWFkjOy6dTGpAQyzJ3Ncw== =pbG/ -----END PGP SIGNATURE-----
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. -- Philip
On Fri, 12 Feb 2021 19:09:30 -0500 Sean Conner <sean at conman.org> wrote: > There's a semantic difference between a URL that ends with a '/' and one > that doesn't. The one that ends with a '/' is semantically a directory, According to what spec? "The path component contains data, usually organized in hierarchical form" (RFC 3986). A URI with a trailing slash may or may not represent a directory. It may or may not refer to the same resource as the URI wihout the trailing slash. None of it is specified. The idea of an URI path as analogous to a filesystem path can be useful (RFC 3986 uses the file system analogy to describe dot-segments), but is ultimately just an analogy. In this case I think it's important to note the difference between a personal opinion (yours being that there is a semantic difference between URIs with and without trailing slashes) and specification (RFC 3986's being that there's a syntactic difference but no specified semantic difference, and only a short note about the semantic meaning of a path as containing "data, usually organized in hierarchical form"). > and > to have to add a file per directory to get all URLs to end with a '/' is, in > my opinion, silly. Agreed. I've suggested pattern-based path rewrites and rules before, like Apache or Nginx do. That time I think the question was about how to best serve multilingual content. -- Philip
On Fri, Feb 26, 2021 at 11:16:10AM +0100, Philip Linde <linde.philip at gmail.com> wrote a message of 63 lines which said: > 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. And these implementations are right, since the point is currently not specified (one of the holes in the specification). A possible way to address a lot of such holes (though not all of them) would be to just state in the specification: "For path, query and fragments semantics, just do like the http scheme." This would solve this problem and would be reasonable since many people assume that all schemes behave like http.
---
Previous Thread: Automatic hyphenation and the lang parameter to text/gemini
Next Thread: Announcing gmni, a line-mode gemini browser and curl-esque utility program