Lighttpd

Thanks! I will try to review this in the next week or so, after the Thanksgiving holiday in the U.S.

The tiny extras all seem like good ideas.

I have some questions about the rest of the patch:

Currently mod_dirlisting pretends to create XHTML, but output is served as "text/html" => dir-listing.external-js becomes useless, as it's inserted as self-closing element, which is interpreted as "tag-soup".

So, would it be better if mod_dirlisting set HTTP response header Content-Type: text/xml; charset=... instead of text/html?

Any deleterious affects from the following behavior changes?

dir-listing.auto-layout is enabled by default. With your patch (and dir-listing.auto-layout enabled), the specification that the generated page is xml:lang="en" has been removed. Also removed is the specification that the generated page has charset=iso-8859-1 if dir-listing.encoding has not been set. That last one is easy to add back.

With your patch, note that if dir-listing.auto-layout is disabled but dir-listing.encoding is set, then the encoding is no longer part of the body output after your patch is applied. (The encoding is still part of the HTTP response header.)

Would sending Content-Type: text/xml be a better choice?

gstrauss wrote:

would it be better if mod_dirlisting set HTTP response header Content-Type: text/xml; charset=... instead of text/html?

I guess you mean application/xhtml+xml (with text/xml you will need to explain browsers how you want the output to be rendered – e.g. XSL): you would be complicating things by enforcing publishers to develop "XML apps".
Going the HTML way is far easier for (virtually) everyone.

dir-listing.auto-layout is enabled by default. With your patch (and dir-listing.auto-layout enabled), the specification that the generated page is xml:lang="en" has been removed.

This is not relevant when talking about HTML (i.e. not XHTML).

Also removed is the specification that the generated page has charset=iso-8859-1 if dir-listing.encoding has not been set.

That already is the creepy default, you don't have to add anything. ;-)

if dir-listing.auto-layout is disabled but dir-listing.encoding is set, then the encoding is no longer part of the body output after your patch is applied. (The encoding is still part of the HTTP response header.)

Nowadays publishers are able to override HTTP Content-Type (i.e. through BOM or META in the first 1KB), so, as long as they do properly use it to markup their "non-auto-layout" heading, everything should work as expected, both "online" (when served through HTTP) and "offline" (when rendering saved docs locally).

Also removed is the specification that the generated page has charset=iso-8859-1 if dir-listing.encoding has not been set.

That already is the creepy default, you don't have to add anything. ;-)

FYI: This is no longer the default behavior.
https://tools.ietf.org/html/rfc7231

Appendix B.  Changes from RFC 2616
[...]
   The default charset of ISO-8859-1 for text media types has been
   removed; the default is now whatever the media type definition says.
   Likewise, special treatment of ISO-8859-1 has been removed from the
   Accept-Charset header field.  (Section 3.1.1.3 and Section 5.3.3)