The man page says:
-M suffix type encoding encoding11
Adds a new entry to the table that converts file suffixes to content type and encoding. This option takes four additional arguments containing the file prefix, its ``Content-Type’’, ``Content-Encoding’’, and ``Content-Encoding’’ for HTTP/1.1 connections, respectively. If any of these are a single dash (``-‘’), the empty string is used instead. Multiple -M options may be passed.
Which wasn’t much help. The only thing I could find searching was someone else wondering how it works, because they’d tried this:
-M'.html text/html UTF-8 UTF-8'
But that doesn’t work. Neither does the variation of -M .html text/html UTF-8 UTF-8 which results in strange error messages from tools such as the W3C validator like:
Either we do not support the content encoding specified (“UTF-8”), or an error occurred while decoding it.
The error was: Don’t know how to decode Content-Encoding ‘utf-8’
Turns out it’s actually all a bit misleading. To specify content encoding you don’t specify the content encoding (!) you specify the content type:
httpd_flags="-M .html 'text/html; charset=utf-8' '' '' -M .xml 'text/xml; charset=utf-8' '' ''"
(And note how unlike how the man page says I couldn’t use a single dash, but had to explicity enter an empty string for each Content-Encoding).
Computers: Entirely logical.