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)
- 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)