[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: TLS in Gopher



> Hi,
>
> On 02/03/18 08:09, Matt Owen (Jaruzel) wrote:
>> Why are we not just following how the introduction of https did it ?
>>
>> 1. TLS enabled gopher links are prefixed by gophers://
>
> This is the mistake that was made with HTTP that we can avoid. This made
> TLS support a special case, meant everyone changing URLs all over the
> place, and a whole load of other problems. It implies that Gopher with
> TLS is a separate protocol. You're still using the Gopher protocol just
> that now it's running over TLS instead of directly over TCP.
>
> HTTP did not repeat this mistake when they started to deploy QUIC+DTLS.
> They didn't decide to have http+quic:// URLs, they reused the https://.
>
>> 2. gophers:// links are used in the gophermap file, and shared elsewhere
>> in the same manner https:// links are. If the connection to that server
>> is already TLS, then it is assumed that all local links in the gophermap
>> file that start with a '/' are also TLS.
>
> gophermap doesn't use URLs, it has a host/port combination and a
> selector. You literally cannot encode gophers:// in a gophermap unless
> you're going to introduce a whole load of new item types, which is not
> what item types are for.
>
>> 3. Gopher clients are updated to understand that gophers:// is TLS and
>> on
>> a default port of 7443 if no discrete port is specified in the link.
>
> Instead, how about gopher clients are updated to assume all servers
> support TLS unless they see evidence to the contrary? I have previously
> described a ridiculously simple method for multiplexing TLS and non-TLS
> on the same port (using MSG_PEEK).
>
>> When https was introduced, there wasn't any fancy way of letting older
>> browsers downgrade the connection - it just wasn't supported. If users
>> wanted to access https, then they had to upgrade their browsers. I don't
>> see why supporting TLS in gopherspace should be any different.
>
> There was. You use http:// instead. It was entirely supported and still
> is to this day. To this day you're still connecting with HTTP first and
> then getting a redirect to HTTPS. You really want to recreate that for
> Gopher?
>
> Thanks,
> Iain.
>
I'm with Iain here. Gopher doesn't need to copy HTTP. That's the beauty of
Gopher: it's not HTTP. It's straightforward and beautifully simple. I
personally don't really care to use TLS with Gopher, but I don't want to
see a bunch of gophers:// or secgoph:// or something.



Reply to: