You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modproxy-dev@apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2001/09/06 23:55:51 UTC

Re: the filesmatch directive / map_to_storage

From: "Ian Holsman" <ia...@cnet.com>
Sent: Thursday, September 06, 2001 1:36 PM    


> I've found a small problem  (probably more a documentation problem)
> 
> <FilesMatch> only works for 'file-based' storage.
> 
> so, using it to set the INCLUDES filter on a page delivered by mod-proxy
> doesn't work.

Please consider this...

<FilesMatch index\..*>
     something
</FilesMatch>

Request http://someserver/somepath/index.shtml/foo/bar/more

The FilesMatch tests 'more'.  That is not the 'file' served (index.shtml)
but we can't determine that it happens to be query_info because the file
is _not_ in our file system.

Agreed this needs to be documented, unless we decide to attempt this behavior
in spite of it's problems.  Options?


> Also .. on another documentation point.
> it is possible for mod-include to NOT check for 'options' include,
> and remove the keyword altogether. seeing how you have to set the
> outputfilter anyway it's doubling up, and also a source for
> configuration errors.

I'm thinking we 'generally' should drop duplicates, but that's a pretty deep
question where we might have more than one transformation by the same filter.
Opinions?