Consequences of wrap-file's :index-files? default on wrap-content-type

Consider this simple static file delivery, but observe carefully its delivered Content-Type header:

(-> handler
    (wrap-file "public") ; :index-files? defaults to true, serving index.* files in directories
    (wrap-content-type)) ; set Content-Type based on the file extension in the URI

While this will always serve up index.html if it exists, how it gets delivered changes.

http://localhost/index.html — correctly serves with a mime type of text/html, due to the specified file extension in the URI. Good.

http://localhost/ — causes wrap-file to deliver index.html by default, but as the URI has no file extension wrap-content-type, unaware that wrap-file automatically selected this resource, delivers a response with a mime type of application/octet-stream. This is a problem, as it causes browsers, like Firefox, to download the content rather than display it. Bad.

Unfortunately, I'm too new to Ring to know if I'm doing this wrong, so apologies in advance should this turn into user education issue, but I didn't see in the documentation how to address it.

It seems that wrap-content-type should either be aware of the "effective URI" at best or allow its content-type-response to accept an override – though doing so isn't always reliable, as it may not always be an html index file delivered.

The behavior of wrap-file (or even wrap-resource) seems to be breaking a strong assumption made downstream by the loosely coupled wrap-content-type about the URI.

An aside: workarounds suggesting making a special route for that one off case don't take into consideration that other subdirectories suffer from the same problem; hacking routes to correct a middleware issue is obviously the wrong way to go.

Start by reading the wrap-file and wrap-content-type middleware entry points, focusing on how an index file selected for a URI without an extension reaches content-type detection. Check existing tests around these middleware functions, if present. Done means directory requests serving index files receive an appropriate Content-Type without breaking direct file requests or other index-file types.