[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apache-modperl
Subject:    Re: Disallow path info
From:       André Warnier <aw () ice-sa ! com>
Date:       2015-03-25 18:52:43
Message-ID: 551303FB.9000800 () ice-sa ! com
[Download RAW message or body]

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:sshock@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 <aw@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


[prev in list] [next in list] [prev in thread] [next in thread]