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).* [NC]
RewriteRule ^(.*)$ - [F]
-----Original Message-----
From: Phillip Hellewell [mailto:ssh...@gmail.com]
Sent: Tuesday, March 24, 2015 11:12 AM
To: mod_perl list
Subject: Re: Disallow path info
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
