Redirection
-----------
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[1], 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
301 Moved Permanently
Moved Permanently
The document has moved here.
Apache/2.2.34 (Unix) mod_ssl/2.2.34 OpenSSL/1.0.2p Server at
sdf.org Port 80
----------
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
----------
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[2]
before making the change, and kept the old selector working for 6
months afterwards. In gopher, that's all you can do.
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[3], 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.
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[4]).
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:
* The could be interpreted strictly as a new path to be
sent to the same host on the same port as the original request.
This would be enough to solve logout's Bongusta move and similar
problems, but you couldn't possibly build a useful URL-shortener
around it. It also retains perfect predictability of which
host you'll be connecting to. I acknowledge that redirects to new
hosts can be perfectly legitimate, so this is a bit of a compromise
solution.
* could be a full URL, allowing redirection to new
hosts, but the spec could explicitly specify that clients for
interactive use by humans MUST ask for confirmation before following
redirects to new hosts.
[1] gopher://sdf.org:70/0/users/ratfactor/phlog/2019-06-18-protocol-pondering-x-solderpunk
[2] gopher://i-logout.cz:70/0/phlog/posts/2018-12-12_im_gonna_break_things.txt
[3] gopher://zaibatsu.circumlunar.space:70/0/~solderpunk/phlog/url-shorteners-are-evil.txt
[4] gopher://zaibatsu.circumlunar.space:70/0/~solderpunk/phlog/on-gopher-conservatism.txt