It was thus said that the Great Emil Engler once stated:
Hi, I read your blog.
Let's say we register the URI scheme gophers: with port 7000 and all the
other stuff you mentioned.
What if the request contains something like an additional character
(maybe an ASCII control sequence?) like other suggesetd on the ML. If
the gopher client provides this the server uses TLS, if not it'll use
plain gopher.
There are two issues here---one is with the gophermap file, and the other
with the actual request the client makes. Let's start with the gophermap.
Normally, a line will look like:
0About /about.txt exammple.com 70
One way to extend is to include an extra field at the end:
0About /about.txt example.org 70 s
One open question about this method is the interaction with Gopher+. I'm
not aware of many Gopher+ servers *or* clients, but until it's determined
that Gopher+ is *not* used (or so little used as to be moot) then a way to
integrate this method with Gopher+ is required.
Another approach, much like with non-gopher links, is to just do:
0About /about.txt URL:gophers://example.com/0/about.txt example.com 70
This has the benefit of using an existing mechanism. The downside is that
every link on a secure gopher server would need to have such links. This
means either a map of absolute URLs like the above, or the gopher clients
would need to now understand URLs to support links like:
0About /about.txt URL:/about.txt example.com 70
which means suporting section 5 of RFC-3986 (the URL RFC) to resolve
relative URLs. Or not, but then a gopher server that supports URL:
selectors [1] would have to handle relative links as well.
An alternative method, much like URL:, is to use TLS:
0About /about.txt TLS:/about.txt example.com 70
or maybe:
0About /about.txt /about.txt TLS:example.com 70
Again, a gophermap would have to annotate every TLS link. Adding TLS: to
the selector means the server might have to support such a selector (per
URL:). Adding it to the host, which (in my opinion is where it should go)
would break existing clients.
I don't like the "stream sniffing" hack---checking the initial bytes of
the request to see if it's a TLS handshake or not. Besides being a hack, it
also complicates the server implementation, especially if one is using a
pre-existing TLS library (which may make such a hack difficult to downright
impossible depending upon the library).
As I stated in my blog post, adding TLS is the easy part. The hard part
is integrating it without breaking existing clients.
-spc
[1] I can't locate the document right now, but the URL: proposal also
mentioned gopher servers to also handle URL: prefixed selectors for
those gopher clients that can't handle it. I added such support to
my own gopher server [2].
[2] https://github.com/spc476/port70
Specifically:
https://github.com/spc476/port70/blob/master/port70/handlers/url.lua