Rici Lake wrote:
<snip>
Obviously, this requires some careful thought to get right, but a good rule of thumb is: put your Location sections in order in the file, from least-specific to most-specific. Then things will probably work out the way you would expect them too.
I gave it some careful thought, and then moved the <Location / > container to the top of the list, and /server-status worked as you predicted. The javascript that putInJava puts in was not there (how could it be?), but it wouldn't apply to users going after /server-status anyway. /server-info didn't, but I found out that the module implementing that is not activated by default. Problem solved. Good work.
PS: I don't know what putInJava does, but I suppose it modifies the web page in some way. This strikes me as more of an output filter than a handler; I am led to believe that mod_perl implemented that even in mod_perl 1. With Apache 2.0, anyone can write output filters, thankfully. Implementing it as a filter rather than a handler would side-step the "only one handler" rule, which might help, particularly if you want it to apply to proxied content as well. (Probably everyone on this list is more qualified than I am to help you put together an output filter in mod_perl.)
The Eagle book doesn't mention filters (except in another context). The Moose book (Apache Cookbook, which, when my wife saw on the credit card bill, made her think I was into Native American ethnic cooking) (recipe 10.7) talks about a SetOutputFilter directive. "[T]he SetOutputFilter directive . . . [is] only available in Apache 2.0".
-- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
