Re: Disallow path info

On Tue, Mar 24, 2015 at 3:44 AM, André Warnier <[email protected]> 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