Re: Gopher over TLS

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