[zzo38computer]

I dislike FTP and think that it is not a very good protocol. (There is one advantage of FTP over HTTP, which is that it has directory listings, although you could also do with HTTP possibly by a new file format (e.g. application/httpdirlist) for directory listings.)

You can serve other file formats (including text/gemini) over HTTP. Although I could manage to make the web browser I have to support text/gemini files over HTTP (and local files), this isn't commonly done, and the protocol does not support file format polyfills (although I have a proposal that can make it work).

However, that isn't good enough if you want to serve NNTP or IRC or Telnet or something else like that. If I want to serve discussion forums, I will want NNTP. If I want fast communications, I will want IRC. There may be other possible protocols too. We shouldn't force everything into HTTP(S); it doesn't fit properly. (I do have a NNTP server, as well as HTTP and Gopher.)

[account42]

> the protocol does not support file format polyfills

It does hover support file format negotiation so you can fall back to a different format where it makes sense.

[zzo38computer]

Yes, you can use the Accept header; however, there are some problems with this:

- The default values are often not very useful; they might not list all supported file formats, and may have wildcards for formats that are not supported, too.

- The Accept header (and other headers) are often misused, which also makes it inaccurate. And sometimes if it is a picture, video, etc, the Accept header might make it difficult to load directly.

- The Accept header cannot distinguish if JavaScripts are enabled or disabled.

- If the end user wishes to save to disk (whether using the browser's save function, or using an external program such as curl or wget) or view source of the original file, this will not work. (Of course there is also possibility that you might want to view/download the alternate file instead, so that still will need to be handled, too. But if you want to view the resulting HTML tree then you can use the web developer tools, but that doesn't do all of the things.)

- See https://wiki.whatwg.org/wiki/Why_not_conneg for some more comments. I do not agree with everything mentioned there, but there are many good points too (some of which are similar to the ones that I had mentioned above). (Another note about video codecs: there are differences other than the codec too that a end user may want, such as the picture size.)

My idea is adding a Interpreter header; I wrote a document with my ideas of how I would intend it to work. (This can be used both for server-side and client-side interpretation, and also allows interpreter caching (and possibly also caching the internal representations) if the optional hash has been included in this header value.)

Also note that the HTML <link> command is also available in HTTP, and can be used with a response of any file format. (I have seen it used in one case for applying stylesheets to plain text files; I do not know what other uses work in what web browsers.) (I also have my own ideas about additional links, such as rel="data" to link to underlying data of a web app in case the end user will use their own software (e.g. SQLite) to query it. These can be used even without changing the web browser, but the Interpreter header requires the web browser to support it)