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.