On 29/08/2021 15:20, Simon McVittie wrote:
The major difference is fallback behaviour. If a client (web browser or email client or similar) receives a file with a text/* type for which it has no special handler, in the absence of other context it is expected to treat it like text/plain, and show the file to the user as text. If a client receives a file with an unknown application/* type, it is expected to treat it like application/octet-stream, assume that viewing the file as text would be pointless because the user wouldn't necessarily understand it anyway, and offer to save it or open it in an external program instead.
[snip]
For scripting languages like sh and Python, I'm not sure: either way could be appropriate. Which is more common: sharing scripts as source code to read and edit, or sharing scripts as executables to download and run as-is? If the former, text/ makes sense, if the latter, application/.
It is usually easy to save a text file from a web browser, while it is hard (impossible?) to persuade it to display an unknown application/* type. Thus, even if your latter example is more common, it may be preferable use text/.
Roger