On Tue, Mar 24, 2015 at 3:44 AM, André Warnier <a...@ice-sa.com> 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. Phillip