perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phillip Hellewell <>
Subject Re: Disallow path info
Date Tue, 24 Mar 2015 15:12:15 GMT
On Tue, Mar 24, 2015 at 3:44 AM, André Warnier <> 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, and Apache already
supports either allowing or disallowing that, and I can achieve
exactly what I want without ModPerl using the "AcceptPathInfo off"

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

> 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, 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,
which is wrong and will return HTML from my script again instead of
the actual css which is at

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.


View raw message