Fwd: Re: PATH_INFO in A2?

[William A. Rowe, Jr.]

Still too much backlogged mail... should have gone here instead;

Date: Mon, 08 Jul 2002 12:12:50 -0500
To: Aaron Bannert <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
From: "William A. Rowe, Jr." <[EMAIL PROTECTED]>
Subject: Re: PATH_INFO in A2?

At 11:41 AM 7/8/2002, Aaron Bannert wrote:

On Mon, Jul 08, 2002 at 11:03:48AM -0500, William A. Rowe, Jr. wrote:
> At 12:02 PM 7/6/2002, Rasmus Lerdorf wrote:
> >> > What is a dynamic page if not a PHP page?
> >>
> >> Like I said, Apache doesn't know if a file on disk is meant for PHP or
> >> not.  The best way to fix this would be for mod_php to set the value if
> >> the filter is added for the request.
> >>
> >> I agree, it would be cool if Apache could set this correctly based on
> >> the filters that have been added for the request.
> >
> >Seems like there should be an API call where a filter can specify whether
> >it is a dynamic one or not as opposed to specifically flipping the
> >acceptpathinfo bit.
>
> There is, and they shouldn't.  See core.c:3145
>
>     /* Deal with the poor soul who is trying to force path_info to be
>      * accepted within the core_handler, where they will let the subreq
>      * address its contents.  This is toggled by the user in the very
>      * beginning of the fixup phase, so modules should override the user's
>      * discretion in their own module fixup phase.  It is tristate, if
>      * the user doesn't specify, the result is 2 (which the module may
>      * interpret to its own customary behavior.)  It won't be touched
>      * if the value is no longer undefined (2), so any module changing
>      * the value prior to the fixup phase OVERRIDES the user's choice.
>      */
>     if ((r->used_path_info == AP_REQ_DEFAULT_PATH_INFO)
>         && (conf->accept_path_info != 3)) {
>         r->used_path_info = conf->accept_path_info;
>     }

Cool, I was meaning to ask you what the magic numbers meant here, so I
could document it in the header and then implement this properly for
PHP. Unfortunately I got sidetracked... :) Glad it came up again so
we can get it fixed.

from httpd.h:627;

/**
 * @defgroup values_request_rec_used_path_info Possible values for request_rec.used_path_info
 * @{
 * Possible values for request_rec.used_path_info:
 */

/** Accept the path_info from the request */
#define AP_REQ_ACCEPT_PATH_INFO    0
/** Return a 404 error if path_info was given */
#define AP_REQ_REJECT_PATH_INFO    1
/** Module may chose to use the given path_info */
#define AP_REQ_DEFAULT_PATH_INFO   2
/** @} */

> Effectively, we allow any module to set r->used_path_info to flag that
> the request is valid with path_info.
>
> The reason to your question in another post, 'Why not always default
> to on???' was pretty simple.  Most filters don't process path info.
> php, perl and includes sometimes use the path info, sometimes won't.
> That's why it can be turned off anywhere, even if your preference is to
> allow it.  Modules can override the -default- preference, but never an
> explicit preference in the config.
>
> So why not leave it on everywhere?  That's been discussed many times,
> the IBM WebSphere product did so by default (even static content.)  The
> problem is recursion, you have no way of telling a robot or other scanner
> that there are no more -new- pages here to read, so they can just pound
> the heck out of duplicated URI space.
>
> We used to have this on www.apache.org/httpd.html. Folks started using
> www.apache.org/httpd [multiviewed].  Then folks started referring to
> www.apache.org/httpd/index.html, as if this were a directory.  It never was.
>
> It's only productive to allow PATH_INFO if the application (PHP, Perl, etc)
> can provide a 404 itself if the PATH_INFO isn't interesting.  Includes can't
> do that, which is why I provided the r->used_path_info flag to advise that
> some filter might be consuming that bit.

So what does PHP need to do?

before fixup's...

if (r->used_path_info == AP_REQ_DEFAULT_PATH_INFO) {
    r->used_path_info = AP_REQ_ACCEPT_PATH_INFO;
}

after the map to storage phase... such as in the filter_init.