Out of curiosity, Are there links that actually point to / myscript.pl/path/info/... ?
Because if you are trying to block them, then it sounds like you don't want to link to them either. Would it be possible to find how they are reaching that page and change the links? Another perspective: If you change the links, then if they somehow get there...then they get a broken page.... On Mon, Mar 23, 2015 at 6:16 PM, Phillip Hellewell <ssh...@gmail.com> wrote: > On Mon, Mar 23, 2015 at 3:08 PM, Randolf Richardson <rand...@modperl.pl> > 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 I don't want), but the page is formatted all > wrong because it can't find the css, because my HTML uses a relative > path, like this: > > <link rel="stylesheet" type="text/css" href="css/default.css"> > > and because of the path of the URL, the web browser looks here for it: > http://mysite.example.com/myscript.pl/path/info/css/default.css > instead of here where it's actually at: > http://mysite.example.com/css/default.css > > And worst of all, that really long crazy path also works, and returns > HTML from my script, and it is not CSS. > > This affects some js files that I include from my HTML too. What's > scary is the fact that this means the browser tries to interpret the > HTML that gets returned as both css and javascript. > > And yes, I already know I can make this work probably by using > absolute paths for (but actually I can't, because in my real use case > there is a parent folder in the path that comes before the script, on > some servers but not others). > > But I don't want to do a bunch of workarounds to "make it work". I > want the user to get a 404. > > > As far as I understand it, with "AcceptPathInfo Off" in efffect, > the > > "/path/info" portion should cause a 404 error. Of course, if this > > doesn't work on your system, one possible work-around would be to > > Yes, and it does work on my system when using the default cgi handler. > It only does not work when I am using ModPerl handler. > > > check that $r->path_info is empty and do the following if it isn't: > > > > $r->status(Apache2::Const::HTTP_NOT_FOUND); > > return Apache2::Const::HTTP_NOT_FOUND; > > What is $r and where does it come from? I know I can check the > PATH_INFO env var from my perl script, but my goal is to *not* have to > modify all my .pl scripts to do extra checking. > > Thanks, > Phillip >
