Make the filename-to-MIME-type lookup public

[vdhamer]

Make the filename-to-MIME-type lookup public

Version: FlyingFox 0.27.1
Type: feature request (API visibility)

Summary

FileHTTPHandler.makeContentType(for:) is static func with no access modifier, so it is internal
to FlyingFox:

// FlyingFox/Sources/Handlers/FileHTTPHandler.swift:61
static func makeContentType(for filename: String) -> String

Any custom HTTPHandler that serves files therefore has to reimplement the same lookup, even when it
delegates the actual response to FileHTTPHandler.

Why it matters

The moment a handler does its own path resolution — a directory index, an authorisation check, a URL
rewrite, serving from a database or an archive — it needs a Content-Type for the file it resolved.
The library already has a good answer, tested and maintained, including the legacy fallback in
legacyMakeContentType(for:) for platforms where UTType is unavailable. Keeping it internal means
every such handler grows a private copy that will drift from FlyingFox's over time.

It is a small surface: one pure, static, side-effect-free function from a filename to a string. There
is no state to expose and nothing to keep in sync, which makes it pretty trivial to provide.

The contentType: parameter on FileHTTPHandler.init is already public and already accepts an
override, so the library invites callers to supply a content type — it just does not let them ask for
the sensible default while doing so. That asymmetry is the whole of this request.

Suggested change

Make it public, on whichever type reads best:

public extension FileHTTPHandler {
    static func contentType(forFilename filename: String) -> String
}

Either exposing the existing makeContentType(for:) directly, or adding a thin public wrapper if the
current name should stay internal. HTTPHeader/HTTPResponse would be an equally reasonable home if
the lookup is felt to be more general than FileHTTPHandler.

Also worth considering whether it is useful and not too broad: should charset=utf-8 should be appended
for text types. A browser needs it for HTML served in anything but ASCII, and a caller that has to
add it is back is obliged to extending the FlyingFox response.

Context

From vdhamer/Photo-Club-Hub-HTML#249. The app's handler resolves a request path inside a generated
static site and then hands the file to FileHTTPHandler, which is exactly the delegation FlyingFox
supports — except that determining the content type to pass along means a private UTType lookup of
about ten lines, duplicating logic that sits a few files away.

Related: the directory-index request (filed separately), which is the reason this handler exists at
all in that app. If that one lands, this one matters less for us — but it would still apply to anyone
writing a custom file-serving handler for any other reason.

---

Note: this suggestion came out of adopting FlyingFox in
vdhamer/Photo-Club-Hub-HTML. I explicitly asked
Claude Code (Opus 5) for changes that would reduce the glue code on our side and would plausibly
benefit other FlyingFox users as well — the analysis above is its work against the 0.27.1
sources (yes, I did review it before filing). Offered as one user's suggestion; feel free to reject it if it does
not fit where you want the library to go.