On Tue, Mar 24, 2015 at 9:29 AM, Szekeres Jr., Edward
wrote:
> I am not sure why something as simple as this would be considered "dicing
> and slicing", simply blocks any requests with "path[any character]info" in
> them
>
> RewriteEngine On
> RewriteCond %{REQUEST_URI} ^.*(path.info).*
On Tue, Mar 24, 2015 at 3:44 AM, André Warnier wrote:
> 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
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 jus
On Mon, Mar 23, 2015 at 8:05 PM, Lathan Bidwell wrote:
> Out of curiosity, Are there links that actually point to
> /myscript.pl/path/info/... ?
Nope, it was just something I accidentally stumbled onto while testing
my site; so there's no concern about breaking any links.
Phillip
On Mon, Mar 23, 2015 at 3:08 PM, Randolf Richardson wrote:
> Can you provide some additional detail about what you're doing?
I'm just trying to secure my website, and one problem right now is if
someone enters http://mysite.example.com/myscript.pl/path/info , not
only does it work (which
Hello,
I would like to disallow path info, i.e., respond with 404 if
PATH_INFO is not empty, i.e., if the URL is something like
http://mysite.example.com/myscript.pl/path/info.
I tried the Apache directive "AcceptPathInfo Off", but sadly this only
works with the normal cgi handler; ModPerl seems
