💾 Archived View for geminiprotocol.net › history › phlog › redirection.gmi captured on 2023-09-08 at 15:59:21. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
(originally posted in Gopherspace on 2019-06-21)
I'm pretty convinced that, as outlined in earlier posts, I want Gemini to feature some very lightweight equivalent to HTTP's status codes. Compared to in-band "special values" of the kind recently discussed by ratfactor, signalling error conditions unambiguously in a machine-readable fashion allows human niceties like clients which report errors in the user's native language, and also allow robust access by scripts, bots, etc.
Given that status codes are going to be in there, Gemini's philosophy of maximing power to weight ratio means that we should use them for as many cool things as we can, since they're in there anyway. HTTP does a lot of things with status codes. I don't want to copy them all blindly, but rather think about which ones could be useful in scenarios that I imagine could be typical for Gemini, and then implement them if I think they can be done in a way that's sufficiently simple and harmless from a privacy perspective.
One possibility is redirection. Briefly, in HTTP, this is used to let servers respond to a request by saying "Hey, that document you want is actually now at *this* URL". Your browser will then automatically, without telling you, fetch that new URL. One common application of this is to redirect insecure HTTP URLs to secure HTTPS URLs. If you connect to sdf.org on port 80 and request the "/" path, you'll receive this response:
HTTP/1.1 301 Moved Permanently Date: Fri, 21 Jun 2019 18:49:45 GMT Server: Apache/2.2.34 (Unix) mod_ssl/2.2.34 OpenSSL/1.0.2p Location: https://sdf.org/ Content-Length: 325 Connection: close Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>301 Moved Permanently</title> </head><body> <h1>Moved Permanently</h1> <p>The document has moved <a href="https://sdf.org/">here</a>.</p> <hr> <address>Apache/2.2.34 (Unix) mod_ssl/2.2.34 OpenSSL/1.0.2p Server at sdf.org Port 80</address> </body></html>
The 301 status means, like the rest of the first line of the header says, "Moved permanently". The "Location:" header indicates that http://sdf.org has moved to https://sdf.org.
It would be very easy to add this to Gemini. Instead of an "everything okay" response header like this:
2 text/plain
a server could send:
3 <NEW ADDRESS>
Piece of cake, parsed in exactly the same way as the "all okay" header. So, we could have this, the question is do we want it?
Nobody using gopher can deny that this functionality would be handy. logout recently changed the selector for the Bongusta phlog aggregator (or, more accurately, after changing the selector at the start of 2019, this month he finally removed the symlink from the old selector). I am *not* criticising logout here, let me be clear. He did absolutely everything 100% right. He gave advance notice before making the change, and kept the old selector working for 6 months afterwards. In gopher, that's all you can do.
Logout's 2018-12-12 post about breaking Bongusta URLs
But lazy people like me didn't update my bookmarks everywhere (particularly, not on PocketGopher on my phone) and for a few days I was confused by the "Forbidden!" message before I rememebered the change. Scripts like moku-pona also would have been confused, as they can't read the warning which logout put in the menu. And now all old links to Bongusta in people's old phlog posts are broken forever. So, redirects could solve real headaches which actually happen in gopherspace. Why isn't it a slam-dunk that we should want them?
In HTTP, redirects are also the magic behind URL shorteners. I am on record as thinking that URL shorteners are evil, and I stand by that. I am loathe to make the worst evils of the web easily possible in Gemini, and so I am pretty deeply conflicted about redirects, which can be used for good *and* for evil.
My 2017-07-19 post on the evil of URL shorteners
Maybe the worst evil of URL shorteners for the web is their surveillence function. I am pretty convinced that this is actually the main motivation for most of these services being set up. They are a sort of man-in-the-middle attack. Thanks to HTTP's stupid Referer header, they know where you've come to them from. By their very nature, they know where you leave from them to. Thanks to cookies, each time you use one, they know it's you. This lets them build up profiles of the navigation routes that users take through the web. The design of Gemini thus far actually defuses this to quite an extent. There are no Referer headers and no cookies, so even if somebody were to build a Gemini URL shortener, it wouldn't be anywhere near as functional as a surveillance tool as the web equivalent. Maybe this is a reason not to be so afraid of redirects?
They would break other nice properties, though, especially the simple transparency and predictability that gopher offers in that you know in advance *exactly* which one and *only one* server your computer will connect to when you follow a link. This feature maximises a user's autonomy and decision-making ability in their online behaviour, and I value that deeply (as I have written about previously).
My 2018-03-26 post about user autnomy in Gopher
I'm really not sure what I want here. In the face of such uncertainty, I'm inclined to play it safe and leave redirection out. I can always add it later if it proves that leaving it out was a mistake, but it's *much* harder to remove a feature. But I'm really interested in hearing what people think about this. I could use the guidance.
Here are some half-baked ideas on how to possibly implement this: