AddDescriptionMatch would be fine, but keep in mind the overhead of invoking the pcre engine. Better opportunity for 2.1-dev is to ask all of these functions to use the fnmatch() API for consistency.
Bill At 07:18 AM 2/21/2003, Jeff Trawick wrote: >AddDescription has some unfortunate behavior in matching file names: > >"File is a file extension, partial filename, wild-card expression or full filename >for files to describe." > >Which is it? In fact there is no way to tell mod_autoindex what the user intends, >and some obvious desires cannot be satisfied. It would seem useful to specify a >regular expression for the file name to eliminate any such questions. > >AddDescriptionMatch "some text" '/somefilebybasename$' >AddDescriptionMatch "some text" '^/some/file/by/full/path$' >AddDescriptionMatch "some text" 'somefilebysubstring' >AddDescriptionMatch "some text" '\.somefilebyfullextension$' >AddDescriptionMatch "some text" '\.somefilebyleadingextension' > >Here's the PR I was looking at: > >http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17210 >(the reporter didn't realize the substring issue, but unfortunately I can't figure >out how to solve his problem with current AddDescription) > >But there are also the following: > >http://bugs.apache.org/index.cgi/full/8570 >(the reporter suggests changing the semantics of AddDescription to achieve certain >functions that AddDescriptionMatch would provide) > >http://bugs.apache.org/index.cgi/full/8248 >(reporter wants to match .h files but has no way to match .h without also matching >.html) > >http://bugs.apache.org/index.cgi/full/6995 >(another substring problem like the new PR 17210... unclear how to solve) > >http://bugs.apache.org/index.cgi/full/5814 >(.h vs .html problem again) > >(I didn't look back any further)
