Am 11.09.26 um 11:05 schrieb Joe Orton:
On Thu, Sep 10, 2026 at 01:46:59PM +0200, Ruediger Pluem wrote:
On 9/10/26 12:15 PM, Joe Orton wrote:
The magic file parsing code in mod_mime_magic is 30 years old and hasn't
been maintained much in that time. The code has the same heritage as the
"file" package widely available on Linux and BSD systems [1], which is
actively maintained and exposes it via a "libmagic" API. It is quite
simple to rebuild mod_mime_magic around that API - proof of concept
here: https://github.com/apache/httpd/pull/752
Thanks for taking the initiative.
I had the impression, "file" was a dying project, because there were no
releases last year. When I cleaned up the list of software I regularly
build, I removed it. It is nice to see, that it had two releases this
year and sporadic commit activity in addition so it seems to be active
again.
There is a performance trade-off: the old code parses the text-format
magic file at startup, the new code will mmap() the pre-compiled binary
magic file per request. I don't see this as a big deal, if you are
dependent on mod_mime_magic that's a fallback option anyway.
In that PR I've added a mod_mime_libmagic based on the library - 335
lines vs the 2.5K lines of mod_mime_magic. An alternative would be to
make most of mod_mime_magic #ifdef'ed out and embed the API use there
directly? Kind of prefer starting fresh, any other opinions or
objections to doing this?
Your code looks nice from visual inspection. I wonder, whether we should
really force "mod_mime_magic.c" to run before the new module via aszPre.
If we think it is the better module (in term of correctness) to decide
on the magic result, it should run before. But of course if we focus on
compatibility the new one should run after. Maybe we could drop
"mod_mime_magic.c" from aszPre. If only one of the two is loaded it
doesn't make a difference, if both are loaded it should be possible to
define the order by the LoadModule order.
I would be in favor of a fresh start. At least in the beginning this
should ease choosing between the two.
Makes sense... also helpful to distinguish any bug reports.
+1
How do we deal with OSes (e.g. probably Solaris and AIX) where it is not part of
the standard setup?
Just another external dependency?
Or do we want to keep offering the current mod_mime_magic there longterm?
We can keep mod_mime_magic to support platforms without the library
available. I guess Windows is also on that list too?
At least for Solaris Sparc (even 10) I know, that current "file" builds
fine (using a self-compiled latest gcc supporting that platform) and
provides pkgconfig info.
Thanks and best regards,
Rainer
