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

On Tue, Mar 25, 2008 at 6:29 PM, Perrin Harkins <[EMAIL PROTECTED]> wrote:

> On Tue, Mar 25, 2008 at 8:56 PM, Will Fould <[EMAIL PROTECTED]> 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
>

Reply via email to