perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Disallow path info
Date Wed, 25 Mar 2015 18:52:43 GMT
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} ^.*(* [NC]
>     RewriteRule ^(.*)$ - [F]

What would you put instead of the ( above ?

> -----Original Message-----
> From: Phillip Hellewell [] 
> 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 <> 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"
> 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
>, 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.
> Phillip

View raw message