LocationMatch wildcard on 404

------=_Part_15545_14960482.1206492992528
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I have an application that handles virtual directory requests:

e.g. http://www.example.com/part

where 'part' does not really exist.

It does it like this:


SetHandler perl-script
PerlOptions +GlobalRequest
PerlResponseHandler myPartHandler::myPartHandler


But other real directories exist under the DocumentRoot and other virtual
directories (in addition to "part") are being added all the time.

I cannot continue to add LocationMatch handlers for all of these future
wildcard directories.

Can a LocationMatch "wildcard" trigger on a normal 404 or is there a better
way to do this?

In psudo-code:

unless (Real Directory) {myPartHandler}


Once again, thank you for sharing your wisdom.

-W

------=_Part_15545_14960482.1206492992528
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I have an application that handles virtual directory requests:

e.g.    

     where 'part' does not really exist.

It does it like this:


    <LocationMatch "/part">
            SetHandler perl-script
        PerlOptions +GlobalRequest
        PerlResponseHandler myPartHandler::myPartHandler
    </LocationMatch>


But other real directories exist under the DocumentRoot and other virtual directories (in addition to "part") are being added all the time.

I cannot continue to add LocationMatch handlers for all of these future wildcard directories.


Can a LocationMatch "wildcard" trigger on a normal 404 or is there a better way to do this?

In psudo-code:

      unless (Real Directory) {myPartHandler}


Once again, thank you for sharing your wisdom.


-W




------=_Part_15545_14960482.1206492992528--

Re: LocationMatch wildcard on 404

On Tue, Mar 25, 2008 at 8:56 PM, Will Fould wrote:
> Can a LocationMatch "wildcard" trigger on a normal 404 or is there a better
> way to do this?

There are many ways. Here are a few:
- A custom ErrorDocument pointing to a URL that your perl code
handles. (The 404 approach you had in mind.)
- A PerlTransHandler that checks for the existence of the directory
and sets the handler as needed. (The built-in handler for static
files is called default-handler.)
- mod_rewrite can check for the existence of a file path and do an
internal redirect if it isn't found.

If you have a separate front-end proxy, mod_rewrite on the front-end
is probably the best way to go. If you don't, a TransHandler is a
good approach. The 404 is fine, but gets sticky because you have to
handle real 404s too.

- Perrin

Re: LocationMatch wildcard on 404

------=_Part_15600_25966955.1206496710314
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Wow - actually, I'm glad you asked - thanks a lot perrin:

Ultimately I think we're going this way with our new hardware, separating
all static items from the application servers:

- have modperl app server send redirect for all static content to the load
balancer.
- Nothing static exists on the modperl servers.
- The static content is sitting on machines running apache.

I'm assuming the handler on the modperl machines will use the wildcard for
everything (except the application) and do the business of redirecting.

If this sounds reasonable (and assuming the static machines do not take
direct requests from the outside world), the modperl handler can auth and
create any request URI's for the static items.

Does this sound right?

If so, might something simple like on the modperl servers
work/scale efficiently for this purpose?


-W

On Tue, Mar 25, 2008 at 6:29 PM, Perrin Harkins wrote:

> On Tue, Mar 25, 2008 at 8:56 PM, Will Fould wrote:
> > Can a LocationMatch "wildcard" trigger on a normal 404 or is there a
> better
> > way to do this?
>
> There are many ways. Here are a few:
> - A custom ErrorDocument pointing to a URL that your perl code
> handles. (The 404 approach you had in mind.)
> - A PerlTransHandler that checks for the existence of the directory
> and sets the handler as needed. (The built-in handler for static
> files is called default-handler.)
> - mod_rewrite can check for the existence of a file path and do an
> internal redirect if it isn't found.
>
> If you have a separate front-end proxy, mod_rewrite on the front-end
> is probably the best way to go. If you don't, a TransHandler is a
> good approach. The 404 is fine, but gets sticky because you have to
> handle real 404s too.
>
> - Perrin
>

------=_Part_15600_25966955.1206496710314
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Wow - actually, I'm glad you asked - thanks a lot perrin:

Ultimately I think we're going this way with our new hardware, separating all static items from the application servers:

 - have modperl app server send redirect for all static content to the load balancer.

 - Nothing static exists on the modperl servers.
 - The static content is sitting on machines running apache.

I'm assuming the handler on the modperl machines will use the wildcard for everything (except the application) and do the business of redirecting.


If this sounds reasonable (and assuming the static machines do not take direct requests from the outside world), the modperl handler can auth and create any request URI's for the static items.

Does this sound right?


If so, might something simple like <Location "/*"> on the modperl servers work/scale efficiently for this purpose?


-W