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
