Szekeres Jr., Edward wrote:
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
I already apologised for that comment.
RewriteEngine On
RewriteCond %{REQUEST_URI} ^.*(path.info).* [NC]
RewriteRule ^(.*)$ - [F]
What would you put instead of the (path.info) above ?
-----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
