You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@httpd.apache.org by Jeff Trawick <tr...@attglobal.net> on 2003/02/21 14:18:33 UTC

provide AddDescriptionMatch for mod_autoindex?

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)

Re: provide AddDescriptionMatch for mod_autoindex?

Posted by Jeff Trawick <tr...@attglobal.net>.

William A. Rowe, Jr. wrote:

> 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.

Overhead sucks, of course.

I just fear breaking config files all over creation if the semantics 
change with 2.1 (maybe that wouldn't happen).

I need to think about this more, and convince myself that fnmatch is the 
way to solve most all desires.

Re: provide AddDescriptionMatch for mod_autoindex?

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.

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)