You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Dale Ghent <da...@elemental.org> on 2002/05/17 22:06:54 UTC

Odd URL (mis)behavior in 2.0

I think what I'm about to describe counts as a regression in 2.0 from
1.3.x.

I have a user who uses and odd URL scheme on his website. He has a PHP
script, "/d.php" that is referenced in following manner: "/d.php/foo.html"
where the "/foo.html" bit is passwd tothe d.v php script and the PHP
script generates dynamic content based on that argument.

On 1.3.x, this works fine. All the propper headers and content are
returned by the server to the client.

But in Apache 2.0 (running the same versoin of PHP - 4.2.1) a 404 status
is returned and the Content-Type header has "application/x-httpd-php"
rather than "text/html." Of course, the browser then asks whether you'd
like to download the output or not because of the mime type.

ISTR that there was some fix put into the tree a long time ago for CGI
scripts that are called in this same manner, but for the life of me, I
can't figure out why this is failing on 2.0 with a PHP script called this
way.

Any thoughts?

/dale


Re: Odd URL (mis)behavior in 2.0

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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



Re: Odd URL (mis)behavior in 2.0

Posted by Rasmus Lerdorf <ra...@apache.org>.
> 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.

-Rasmus


Re: Odd URL (mis)behavior in 2.0

Posted by Aaron Bannert <aa...@clove.org>.
On Fri, May 17, 2002 at 04:06:54PM -0400, Dale Ghent wrote:
> 
> I think what I'm about to describe counts as a regression in 2.0 from
> 1.3.x.
> 
> I have a user who uses and odd URL scheme on his website. He has a PHP
> script, "/d.php" that is referenced in following manner: "/d.php/foo.html"
> where the "/foo.html" bit is passwd tothe d.v php script and the PHP
> script generates dynamic content based on that argument.
> 
> On 1.3.x, this works fine. All the propper headers and content are
> returned by the server to the client.
> 
> But in Apache 2.0 (running the same versoin of PHP - 4.2.1) a 404 status
> is returned and the Content-Type header has "application/x-httpd-php"
> rather than "text/html." Of course, the browser then asks whether you'd
> like to download the output or not because of the mime type.
> 
> ISTR that there was some fix put into the tree a long time ago for CGI
> scripts that are called in this same manner, but for the life of me, I
> can't figure out why this is failing on 2.0 with a PHP script called this
> way.

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.

-aaron

Re: Odd URL (mis)behavior in 2.0

Posted by Cliff Woolley <jw...@virginia.edu>.
On Fri, 17 May 2002, Dale Ghent wrote:

> regarding #2, the README in the apache2filter directory of the PHP source
> tree used to say (in pre-4.2.0 revs) to use Add*Filter PHP directives. But
> now, since 4.2.0 was released, it commands to use the "traditional"
> AddType method to activate PHP scripts.

Oh, I forgot we did that.  Sorry.  Yeah, x-httpd-php should be okay.
Presumably if you get the PATH_INFO thing set right, the rest will work.
The AddType thing is just shorthand for the two Add*Filter directives, by
the way:

static void php_insert_filter(request_rec *r)
{
	if (r->content_type &&
	    strcmp(r->content_type, "application/x-httpd-php") == 0) {
		php_add_filter(r, r->output_filters);
		php_add_filter(r, r->input_filters);
	}
}




--------------------------------------------------------------
   Cliff Woolley
   cliffwoolley@yahoo.com
   Charlottesville, VA



Re: Odd URL (mis)behavior in 2.0

Posted by Dale Ghent <da...@elemental.org>.
On Fri, 17 May 2002, Cliff Woolley wrote:

| 1) You need to set AcceptPathInfo On if you want to allow this behavior
| 2) Don't set the magic mime type application/x-httpd-php anymore, just
|    do the AddOutputFilter PHP and AddInputFilter PHP directives.

mmmkay!

regarding #2, the README in the apache2filter directory of the PHP source
tree used to say (in pre-4.2.0 revs) to use Add*Filter PHP directives. But
now, since 4.2.0 was released, it commands to use the "traditional"
AddType method to activate PHP scripts.

Thanks!
/dale


Re: Odd URL (mis)behavior in 2.0

Posted by Cliff Woolley <jw...@virginia.edu>.
On Fri, 17 May 2002, Dale Ghent wrote:

> I have a user who uses and odd URL scheme on his website. He has a PHP
> script, "/d.php" that is referenced in following manner: "/d.php/foo.html"
> where the "/foo.html" bit is passwd tothe d.v php script and the PHP
> script generates dynamic content based on that argument.
> On 1.3.x, this works fine. All the propper headers and content are
> returned by the server to the client.
> But in Apache 2.0 (running the same versoin of PHP - 4.2.1) a 404 status
> is returned and the Content-Type header has "application/x-httpd-php"
> rather than "text/html."

Two things with Apache 2.0:

1) You need to set AcceptPathInfo On if you want to allow this behavior
2) Don't set the magic mime type application/x-httpd-php anymore, just
   do the AddOutputFilter PHP and AddInputFilter PHP directives.

--Cliff

--------------------------------------------------------------
   Cliff Woolley
   cliffwoolley@yahoo.com
   Charlottesville, VA