Phillip Hellewell wrote:
Good news. I got a helpful tip from a Dr James Smith to use a PerlFixupHandler that looks like this:package My::Fixup; use strict; use warnings; use utf8; use Apache2::Const qw(OK NOT_FOUND); sub handler { my $r = shift; return NOT_FOUND if $r->path_info; return OK; } 1; It worked just great! Phillip
You know, I am slowly getting the feeling that by dicing and slicing the URLs and fixing up things afterward, you are setting yourself up for some major headeaches later on, when something changes and/or someone needs to figure out what is going on.
It may be time to reconsider the issue "top-down", and maybe see if there is not a "more standard" way of achieving what you wanted to achieve in the first place (which I honestly have lost track of by now).
I mean, mod_perl is great, in that it allows one to do just that kind of thing, at a relatively deep level within the Apache logic itself. But there lies also the danger of incrementally building up your very own webserver with its very own logic, which at some point does not match anymore what a HTTP-compliant webserver should do in some particular circumstance, and becomes very fragile and difficult to maintain or adapt to some new quirk which would appear on the WWW.
For example, I believe that it is entirely HTTP-compliant for a URL to invoke a script and nevertheless pass it path-info information at the same time, for the script to use in some way. In this particular case, should it not be the script which discards the unwanted path_info if it doesn't want it ? I am not saying that this is the "right" answer, but it is maybe worth pondering, before introducing additional webserver logic which might have unintended side-effects in other cases.
André
