Re: Gopher over TLS

I agree with the stream hack, it isn't really beautiful.
To the point of Gopher+. It isn't an official RFC standard therefore we 
shouldn't really care about it IMO.

It was thus said that the Great Sean Conner once stated:
> 
>   One way to extend is to include an extra field at the end:
> 
> 0About	/about.txt	example.org	70	s


I like the solution. The server and clients need modification to support 
Gopher over TLS. Therefore it is ok to modify the syntax.

Cheers,
Emil

Am 15.03.20 um 22:59 schrieb Sean Conner:
> 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
>