Aaron Dalton wrote:
I'm using mod_perl and CGI::Application::Dispatch to create a RESTful web application. In the one resource, GETs should be sent to the default handler, and all other requests to the dispatcher. I have tried using <Limit> and <LimitExcept>, but they do not appear to be working. The handlers get processed regardless. Here is the current config:<Location /fs> <LimitExcept GET> Allow from All SetHandler perl-script PerlHandler BackCAD::Dispatch </LimitExcept> </Location>Is there some way to make this work? Do I need to write some sort of pre-dispatcher that checks the request method and returns DECLINED if it's GET? But if it's *not* GET, how do I then pass control on to the other dispatcher?
Interesting issue. Several things come to mind, roughly :1) you may want to (also) post this question on the mod_perl list (modperl@xxxxxxxxxxxxxxx)
2) what happens if you just remove the section > <Limit GET> > Allow from All > SetHandler default-handler > </Limit> ? 3) If nothing else works, you should be able to do this using mod_rewrite : a) define a new <Location /fs-dispatch> with your perl module in itb) use RewriteCond and RewriteRule to check for a "non-GET" call, and if so, re-direct (internally) to the /fsdispatch location 4) for your last question : I think that if your first handler returns DECLINED, Apache will automatically pass the request to the next defined handler in the chain. The first handler returning "not-DECLINED" wins. You could also create your "pre-dispatcher" as a PerlAccessHandler, which will always be executed in a previous phase (before content handlers). That pre-dispatcher could just "push" the BackCAD::Dispatch handler as a content-handler only if needed, leaving the default Apache handler if it is a GET.
TIMTOWTDI, I think the saying goes. --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx