Re: Questions about URLs for Gopher search items
On Sun, Oct 27, 2019 at 03:47:49PM +0100, Christoph Lohmann wrote:
> Greetings comrade.
Greetings, thanks for your answer.
> > The first is: to what extent is RFC 4266 ("The gopher URI Scheme") being
> > adhered to by the modern Gopher community? Are we trying to follow it,
> > or is it being actively ignored in the same way that Gopher+ is being
> > actively ignored?
>
> No.
I assume you mean "No, it is not being ignored".
> > Note the use of ? instead of %09 to separate the search term from the
> > selector.
>
> This is incorrect. Lynx does many things wrong. Lynx should be fixed.
I thought this might be the case.
> For example geomyidae does implement ?key=value for its dcgi and cgi
> scripts. But all of this is up to the server. The client only sends
> what is in the URI to the server and does not decode it.
I think Gophernicus does likewise.
> > I tried to see what other clients do here to see if there was a rough
> > consensus, but was surprised to find that very few clients actually
> > provide a way to get the URL of the current Gopher item! VF-1 does, but
> > it doesn't include search terms at all, which is something I'd like to
> > fix.
>
> Sacc knows it.
Could you explain how? Sacc was one of the clients I tried. I read the
man page. It is clear that I can press `u` to see the URL of the menu
item my cursor is currently pointing at. This is not the same thing as
seeing the URL of the item I am currently *at*. After I have done a
Veronica search with sacc and I am staring at the results, how do I ask
sacc "Which URL am I at, right now?".
After reading their built-in documentation, I was unable to figure out
how to ask that very simple question of most clients. It does not
appear to be possible, or to be undocumented, in cgo, click, gopher,
sacc and stubb. Bombadillo displays the current URL at the top of the
page, similar to most web browsers - it appears to display search terms
after an *unencoded* tab, so that copying and pasting the URL would not
quite work. But points to Bombadillo for at least showing the current
URL. Clients where this is easy and obvious are rare. I use the `url`
command in VF-1 very regularly to share links and I am confused as to
how people are happily surviving without this ability.
> As said: A gopher server could interpret ?something to a separate
> parameter for some script. But this is not part of the client, to
> interpret this. If the client sends some user interaction, use the
> encoded tab. This is the only thing the client knows: If you send
> something behind a tab in the selector, it is a query. If something is
> behind a second tab, it could be some gopher+ stuff.
I understand this now. But my point stands that the majority of clients
do not seem to understand the %09 syntax. Most clients support
launching from a shell prompt with a URL as an argument. If I try to
start clients by running:
$ client gopher://gopher.floodgap.com/7/v2/vs%09cheese
then:
* Lynx works as expected and I see search results
* Cgo and stubb throw an error or do nothing, respectively
* Bombadillo, gopher, sacc and VF-1 ask me to input a search string,
having obviously failed to notice the one in the URL.
* The Floodgap Gopher-HTTP proxy also asks me to enter parameters.
I'll admit I didn't bother to update all of my clients before testing
this, so apologies if anybody fixed this in a recentish release, but I
think it unlikely that *everyone* did, so my point that this typically
fails still stands.
> Seven is used everywhere.
Where is "everywhere"? The majority of clients will not even provide an
answer to the question. Direct links to search results appear to be
rare in the wild.
> Normally the client has internally only the menu item of item type,
> selector, server and port. If there is a tab in the selector, with item
> type ?7?, it does not need to ask for a user prompt.
The above experiment shows that almost no clients check for a tab in the
selector. Most of them are interpeting an item type of 7 as literally
meaning "I need to ask the user for input".
In fact, while:
$ gopher gopher://gopher.floodgap.com/7/v2/vs%09cheese
causes gopher to ask me for input,
$ gopher gopher://gopher.floodgap.com/1/v2/vs%09cheese
works as expected. Which was kind of my point. If a client "implements
correct en- and decoding of gopher URIs" as you advise, and an RFC 4266
style URL is used, then accessing a page of search results looks exactly
the same as accessing a regular index. What purpose is served by using
a different item type? If we insist that 7 is the correct type here,
then client complexity increases (slightly) because accessing a type 7
URL means the client has to inspect the selector to know what to do. If
we use 1 here, clients which correctly decode URLs (which appears to be
the minority, but that is an obvious and hard to deny fault of those
clients, which is not specific to search at all) will just work without
the need to inspect the selector. Client authors then do not need to
ever think about URLs with search terms in them as a special case at
all. Surely this is the cleaner solution?
> It is good explored. You used bad examples (lynx) for reasoning.
I used just about the only example I could get. I think it's very clear
this is poorly explored. The majority of clients will not tell their
user what the URL is for the search results they are currently viewing.
The majority of clients cannot correctly navigate to RFC 4266 style URLs
with search terms in them. The best known and most widely used Gopher
search engine, if you submit a query to it using a tab in the selector,
will feed you a result directory where the "Back to the beginning" etc.
links have item type 1 and use the alternative CGI syntax - perhaps
precisely because doing it the other way confuses many clients?
Cheers,
Solderpunk
Reply to: