>
>First, mod_mime understands filename extensions (and mapping files).
>
>mod_mime_magic understands file contents.
>
>mod_mime_hfs could grok the additional indentification streams on the file :)
The problem there is how do I change which module takes precedence per directory.
>
>I think mixing apples and oranges will cause headaches. Have the user follow
>mod_mime_hfs,
>then mod_mime (for extensions or file maps), then mod_mime_magic (the last resort.)
If only apples were labeled apples and oranges were labeled oranges. AddType doesn't
imply anything about filename extensions, neither does mod_mime.
>
> > One possible problem is a file type isn't limited to 7bit ascii. If this is
>important (please tell me) I can change the syntax to
>'0xFFFFFFFF" or "'0xFFFFFFFF". I don't anticipate a problem with upper ascii
>characters since they will be platform specific anyway
>(and will have it's own separate config file).
>
>On WinNT all configs are considered utf-8. On Unix/Win9x the conf file is essentially
>treated as the locally defined code page.
I fail to see what WinNT has to do with anything.
>
> > Implementation in source code:
>> There is no cost in fetching the file type so long you do it while fetching the
>filename (where is this done?). If you try to
>fetch a file type when it isn't set, or from a filesystem which doesn't support them
>it returns null.
>
>Please see apr_dir_read and apr_stat/lstat/getfileinfo. The concept is this:
>
> . if the user asks for something, research it (no matter how painful, such as
> the file ownership or permissions on Win32.)
>
> . if an apr_finfo_t field comes for free, fill it in anyways :)
>
> . so on Unix, group/user ids are filled in, even if the user stats for
>APR_FINFO_MIN.
> Not for Win32, which will quintupple the time required for the stat :(
>
> . on Win32, nearly the entire apr_finfo_t is filled out for apr_dir_read, even when
> asked for APR_FINFO_DIR.
Would anybody complain if I add fields from attr.h?
> > Thus there is no reason not to always have this option on when running on Darwin.
>The primary difference between filename
>extensions and file types is Apache matches filename extensions in a case insensitive
>manner while file types are any 32bit value
>(or four char code).
>
>This doesn't map terribly cleanly :( Dunno what we aught to do about it. AS400 and
>Win32
>also have alternate streams (so do some Mac filesystems, no?) that may encode things
>like
>the language or charset. It would be nice to find some apr_ methods to extract this
>useful
>data for Apache.
It would be possible to map ttxt to the mac roman charset but I don't see much demand
for it. Everything is unicode these days anyway.
>
>
>> It does this by converting filename extensions to lower case before entering them
>in the runtime database, then converting the
>filename extension in question to lower case, then strcmp(). Personally I don't
>understand why strcasecmp() wasn't used instead,
>perhaps because it was slightly faster.
>
>Not if it's tested multiple times :( Once, yes, but when you are comparing against a
>very
>large table, and indexing via a hash, it's pointless.
I found out that it uses strcasecmp() anyway, but in the table lookup, so I can't use
tables. Makes me wonder why everything is tolowered in the first place.
Anyway it's irrelevant now.
> > If this modification to mod_mime.c were done, I would also want to add a directive
>to change which mapping had priority. Thus one
>Darwin user may prefer filename extension mapping, another may prefer file type
>mapping, and another may want filename extension
>mapping in one directory only.
>
>Understood, but this can't happen in mod_mime.
Where then?
>
>> If you want me to develop a separate module the priority issue will have to be
>addressed because load order doesn't allow the user
>to change the priority on a directory-specific basis.
>
>So on a Darwin config, set mod_mime_hfs as the highest priority module. It can have
>a fast
>escape based on the <Directory > config (even dynamically detected) which drops the
>file on
>to mod_mime. It can partially fill in the info, and leave other issues (language?)
>for
>mod_mime or mod_mime magic.
>
>The one problem I'd like to see addressed that mod_mime_* mechanisms respect the
>decisions
>that are made before, and this becomes a run-all instead of a run-until-success.
>With now
>five different aspect to detect (we've got language, content-type, forced handlers,
>charset
>and one I'm forgetting), we have to get off the idea that one mod_mime_any module
>will ever
>answer all the questions :)
But how does one set module priority per directory?
