On 26/10/2022 18:26, Sean Conner wrote:
> The one thing I do miss from HTTP is the ability to redirect a request.
> So, as an experiment, I added the ability to mark a selector as having been
> moved, using the standard gopher error mechanism. So, if you attempt to
> retreive the selector '/Phlog:' on my server [1], you'll get:
>
> 3Permanent redirect Phlog: gopher.conman.org 70
Looks nice. Now, having such behavior standardized over gopher clients
and servers is probably a dream.
Since we are in wonderland territory, let me list a couple of things
that I find missing in Gopher:
- virtual host support
- advertising of the type and charset of the resource being returned
- a method of unambiguously saying "this selector does not exist"
- support for some kind of forms
- standardized color sequences (like ANSI ESC codes)
- ...
and I probably forgot some.
The point being - Gopher comes with none of these things and... it's
fine. These limitations are part of what Gopher is, and one must learn
to live within these limits. It would be easy to address most of these
shortcomings very easily, but what for? It would no longer be Gopher.
> A benefit of TLS is that it prevents an ISP from modifying the document as
> it's being delivered. There are ISPs out there that will modify HTML pages,
> usually to insert their own advertising, on pages served over http:.
I find it hard to believe that such thing actually happen on any
significant scale. Aren't you rather thinking of hosters in lieu of
ISPs? Hosters (esp. the free ones) do have the tendency to include ads
in user content, but TLS is irrelevant here since they simply modify the
files that are stored on their own disks. No need for any protocol-level
interaction.
But even assuming that what you say is true: TLS would be of no big
help, because it would be fairly easy for such ISP to set up a TLS proxy
to perform any kind of MITM business (yes, with a different CA having
signed the x509 cert being presented - but who looks at that?).
Mateusz