Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Errors-To: <wrowe@rowe-clan.net>
Message-Id: <5.1.0.14.2.20020517184241.01ff65c8@pop3.rowe-clan.net>
Date: Fri, 17 May 2002 18:48:58 -0500
To: dev@httpd.apache.org
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Subject: Re: Odd URL (mis)behavior in 2.0
Cc: Aaron Bannert <aaron@clove.org>, dev@httpd.apache.org
In-Reply-To: <Pine.LNX.4.44.0205171549270.16768-100000@christine.ca>
References: <20020517131109.C14245@clove.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 05:50 PM 5/17/2002, Rasmus Lerdorf wrote:
> > Right now PATH_INFO is not automatically passed to PHP scripts in the
> > Apache 2.0 module for PHP. I have a patch on my plate that enables it
> > by default, but for now you can add "AcceptPathInfo On" to the directory
> > or location sections where you want it to work.
>
>That should go in.  Why would you not want $PATH_INFO?  I don't think it
>should be configurable at all.  It should always be there.

For PHP by default?  Yes, only if you are using a handler.

If you are filtering the output of another handler [which you can't do right
now, php2filter is really a handler in filter's clothing] you should have no
say about the handler's choices.

So Aaron's patch aught to provide the default -> on mapping of AcceptPathInfo
for x-httpd-php content.

The point to AcceptPathInfo is that you don't want infinite recursion on 
handlers
such as the default handler for static content.  In fact, it's probably a 
good idea
to set AcceptPathInfo Off for all but the specific cgi/php/jk content that 
actually
uses a PATH_INFO namespace.

But that 'right solution' would have broken too many old applications, so the
default AcceptPathInfo behavior depends on the handler serving the content.
E.g. the default handler will defaults to off, while dynamic handlers such as
cgi/ssi default to on, as should PHP.

Bill