Re: Disallow path info
André Warnier <[email protected]>
| Newsgroups | gmane.comp.apache.mod-perl |
|---|---|
| Message-ID | <[email protected]> |
Phillip Hellewell wrote: > On Tue, Mar 24, 2015 at 3:44 AM, André Warnier <[email protected]> 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 is going on. > > Umm, no I am not dicing and slicing URLs and fixing up things afterwards. > > If I tried to solve this problem using rewrite module, that would be > dicing and slicing and I'm not confident I would get the regex right. > > If I tried to modify all my scripts to handle path_info and alter the > URLs inside the returned HTML by, e.g., prepend ../ for however many > parts are in the path info *that* would really be dicing and slicing > and I would probably mess up somewhere. > > No, I'm not doing either of those. I'm doing a 3-line > PerlFixupHandler to return 404 if path_info is set, which is the > perfect fix for the fact that ModPerl ignores "Accept PathInfo off" > apache directive for some reason. > >> 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 already made the issue very clear. Just go read my first email. > > The only "more standard" way of achieving what I want would be for > ModPerl to stop ignoring the "AcceptPathInfo off" apache directive. > >> 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. > > Umm, no. I'm not using modperl to accomplish some non-standard thing. > An HTTP-compliant webserver is free to allow or disallow paths like > http://mysite.example.com/myscript.pl/path/info, and Apache already > supports either allowing or disallowing that, and I can achieve > exactly what I want without ModPerl using the "AcceptPathInfo off" > directive. > > It is when I add ModPerl to the mix that the problem comes back > because ModPerl ignores "AcceptPathInfo off" and that is a problem > with ModPerl not a problem with what I am trying to achieve, so fixing > a problem caused by ModPerl with a ModPerl fixup handler makes perfect > sense. > >> 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. > > I believe you are right, it is entirely HTTP-compliant to support > path-info. But I believe it is also entirely HTTP-compliant to not > support it. > > My scripts already discard path_info, but that doesn't solve the > problem I explained, which is that if you enter > http://mysite.example.com/myscript.pl/path/info, then if my script > returns HTML that includes <link rel="stylesheet" type="text/css" > href="css/default.css"> then your web browser will try to download the > css at http://mysite.example.com/myscript.pl/path/info/css/default.css, > which is wrong and will return HTML from my script again instead of > the actual css which is at http://mysite.example.com/css/default.css. > > path-info may work for you, but it doesn't work for me, and I don't > need it and I don't use it and I don't want it and it is entirely > legitimate for me to not support it. > Sorry, I did not mean to offend you or attack your strategy here. I was just trying to alert you to possible pitfalls, for having been there myself before : you start with a tweak to achieve one particular goal, and then you find that in one case it doesn't work as expected, so you add another tweak, and before you know it, you find yourself in a hopeless spiral of tweak over tweak.. I believe that I also got a bit confused, and mixed up memories of a previous post to the list (entitled "How Do I change the Document Root Per Request"), and thought that your post was a follow-up on that one (which would have made it a lot of tweaks). Sorry again.