Re: PATH_INFO in A2?
Justin Erenkrantz wrote: I don't believe that mod_include would want AcceptPathInfo on. Um, why not? I know of SSIs that use the path-info.. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp!
Re: PATH_INFO in A2?
At 11:49 AM 7/11/2002, you wrote: Justin Erenkrantz wrote: I don't believe that mod_include would want AcceptPathInfo on. Um, why not? I know of SSIs that use the path-info.. But not by default. That would be the exception, not the rule. The idea is to avoid namespace recursion, and unlike CGIs, most folks don't look at PATH_INFO in their SSIs. If your CGI doesn't look at it either, that's the CGI's problem. Bill
Re: PATH_INFO in A2?
William A. Rowe, Jr. wrote: But not by default. That would be the exception, not the rule. The idea is to avoid namespace recursion, and unlike CGIs, most folks don't look at PATH_INFO in their SSIs. This smacks of a 'father knows best' attitude -- which historically infuriates me. If it's dynamic, it's dynamic, so give it access to all its data. *DON'T* force users (and people they ask for help) into a guessing game about when to turn the option on. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp!
Re: PATH_INFO in A2?
On Thu, 11 Jul 2002, Rodent of Unusual Size wrote: William A. Rowe, Jr. wrote: But not by default. That would be the exception, not the rule. The idea is to avoid namespace recursion, and unlike CGIs, most folks don't look at PATH_INFO in their SSIs. This smacks of a 'father knows best' attitude -- which historically infuriates me. If it's dynamic, it's dynamic, so give it access to all its data. *DON'T* force users (and people they ask for help) into a guessing game about when to turn the option on. Aye - and people who love fooling netapps/squid/caches who think they should do stupid things when they see a '?' in the URL love using it for constructing dynamic content whith a URL which looks like it is static (and then use PATH_INFO). Dw -- http://www.foo.com/legal/italy/disclaimer.html
Re: PATH_INFO in A2?
At 03:56 PM 7/11/2002, Rodent of Unusual Size wrote: William A. Rowe, Jr. wrote: But not by default. That would be the exception, not the rule. The idea is to avoid namespace recursion, and unlike CGIs, most folks don't look at PATH_INFO in their SSIs. This smacks of a 'father knows best' attitude -- which historically infuriates me. If it's dynamic, it's dynamic, so give it access to all its data. *DON'T* force users (and people they ask for help) into a guessing game about when to turn the option on. And don't go spilling entire web trees from every static file resource, resulting in infinite recursion of a resource identifier ;-) This was a compromise. Short of pre-parsing the SSI for included CGI files or PATH_INFO references, we can't predict. Better docs about this? YES! I would agree 100% this isn't intuitive enough. Sorry if I feel somewhat strongly here. Just got blasted with a dozen hits last night for robots.txt by a.v., and I have only one dns entry registered to that box. Sure, you -can- include anything in an SSI, but should the majority default to recursion or no recursion? To default in favor of a non-infinitely-recursing resource is a good thing, IMHO. Do others care to shed new light in this year old debate? Bill
Re: PATH_INFO in A2?
Rasmus Lerdorf wrote: With this config: LoadModule php4_modulemodules/libphp4.so AddType application/x-httpd-php .php http://localhost/index.php works fine and parser PHP pages without problems. (using prefork - but it shouldn't matter) However: http://localhost/index.php/foo Gives a 404 and says: The requested URL /index.php/foo was not found on this server. In Apache1 /index.php would still get passed to PHP and /foo would end up in the PATH_INFO server var. -Rasmus does it work with the normal CGI or mod_include ??? !--#echo var='PATH_INFO' -- is a SSI file should tell you
RE: PATH_INFO in A2?
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; } 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. Bill
Fwd: Re: PATH_INFO in A2?
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.
PATH_INFO in A2?
With this config: LoadModule php4_modulemodules/libphp4.so AddType application/x-httpd-php .php http://localhost/index.php works fine and parser PHP pages without problems. (using prefork - but it shouldn't matter) However: http://localhost/index.php/foo Gives a 404 and says: The requested URL /index.php/foo was not found on this server. In Apache1 /index.php would still get passed to PHP and /foo would end up in the PATH_INFO server var. -Rasmus
Re: PATH_INFO in A2?
On Sat, 6 Jul 2002, Rasmus Lerdorf wrote: | The requested URL /index.php/foo was not found on this server. | | In Apache1 /index.php would still get passed to PHP and /foo would end up | in the PATH_INFO server var. What AP2 code are you using? I'm running .40-dev with a CVS update as of last afternoon (right after Bpane's apr_table mods) and PHP 4.2.1 (with the set-cookie fix)... everything is fine for me on a site that reqires PATH_INFO ( http://playadelfuego.org/ ) /dale
Re: PATH_INFO in A2?
On Sat, 6 Jul 2002, Rasmus Lerdorf wrote: | 2.0.40-dev built on June 23rd Make sure you have AcceptPathInfo On /dale
Re: PATH_INFO in A2?
On Sat, 6 Jul 2002, Dale Ghent wrote: On Sat, 6 Jul 2002, Rasmus Lerdorf wrote: | 2.0.40-dev built on June 23rd Make sure you have AcceptPathInfo On Argh! Why the heck is that off by default? -Rasmus
Re: PATH_INFO in A2?
On Sat, 6 Jul 2002, Rasmus Lerdorf wrote: | On Sat, 6 Jul 2002, Dale Ghent wrote: | | On Sat, 6 Jul 2002, Rasmus Lerdorf wrote: | | | 2.0.40-dev built on June 23rd | | Make sure you have AcceptPathInfo On | | Argh! Why the heck is that off by default? Dunno. I ran into this same problem a while back when I made the switch from AP1.3 to AP2. It has always seemed like a regression to me (especially when there's no mention on the change in any of the AP2 upgrade docs. There was no AcceptPathInfo directive in 1.3. It got added in AP2 with a default of Off (obviously). I don't know the original meaning of this. I guess having a switch for this is cool... but it's default shouldnt stray from what has been expected all the long. /dale
RE: PATH_INFO in A2?
From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]] On Sat, 6 Jul 2002, Dale Ghent wrote: On Sat, 6 Jul 2002, Rasmus Lerdorf wrote: | 2.0.40-dev built on June 23rd Make sure you have AcceptPathInfo On Argh! Why the heck is that off by default? It's on by default for dynamic pages, but there is no way that Apache can tell that a page is going to be served by PHP, so it is off for what Apache thinks are static pages. Ryan
RE: PATH_INFO in A2?
Make sure you have AcceptPathInfo On Argh! Why the heck is that off by default? It's on by default for dynamic pages, but there is no way that Apache can tell that a page is going to be served by PHP, so it is off for what Apache thinks are static pages. What is a dynamic page if not a PHP page? -Rasmus
Re: PATH_INFO in A2?
Dale Ghent wrote: Make sure you have AcceptPathInfo On Now it works, thanks. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
RE: PATH_INFO in A2?
From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]] Make sure you have AcceptPathInfo On Argh! Why the heck is that off by default? It's on by default for dynamic pages, but there is no way that Apache can tell that a page is going to be served by PHP, so it is off for what Apache thinks are static pages. 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. Ryan
RE: PATH_INFO in A2?
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. -Rasmus
Re: PATH_INFO in A2?
On Sat, Jul 06, 2002 at 10:02:24AM -0700, 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. Sounds like PHP needs to implement the filter_init function. It is exactly for this situation. -- justin
RE: PATH_INFO in A2?
On Sat, 6 Jul 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. We just added a new function for all input filters to allow this to be done (Justin referenced it in his reply). However, that function doesn't solve the problem, because there should be an ap_filter_is_dynamic(r) that hides the implementation details for all filters. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 ---
Re: PATH_INFO in A2?
On Sat, Jul 06, 2002 at 03:11:20PM -0400, [EMAIL PROTECTED] wrote: We just added a new function for all input filters to allow this to be done (Justin referenced it in his reply). However, that function doesn't solve the problem, because there should be an ap_filter_is_dynamic(r) that hides the implementation details for all filters. I don't believe that mod_include would want AcceptPathInfo on. Only PHP would. So, I don't know what ap_filter_is_dynamic() would buy here (other than setting r-no_local_copy to 1). -- justin
Re: PATH_INFO in A2?
On Sat, Jul 06, 2002 at 03:11:20PM -0400, [EMAIL PROTECTED] wrote: We just added a new function for all input filters to allow this to be done (Justin referenced it in his reply). However, that function doesn't solve the problem, because there should be an ap_filter_is_dynamic(r) that hides the implementation details for all filters. I don't believe that mod_include would want AcceptPathInfo on. Only PHP would. So, I don't know what ap_filter_is_dynamic() would buy here (other than setting r-no_local_copy to 1). -- justin Why wouldn't mod_include want AcceptPathInfo to be on? I am sure there are .shtml files out there that are written with the assumption that PATH_INFO is set correctly. -Rasmus
RE: PATH_INFO in A2?
From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]] On Sat, Jul 06, 2002 at 03:11:20PM -0400, [EMAIL PROTECTED] wrote: We just added a new function for all input filters to allow this to be done (Justin referenced it in his reply). However, that function doesn't solve the problem, because there should be an ap_filter_is_dynamic(r) that hides the implementation details for all filters. I don't believe that mod_include would want AcceptPathInfo on. Only PHP would. So, I don't know what ap_filter_is_dynamic() would buy here (other than setting r-no_local_copy to 1). -- Justin ap_filter_is_dynamic wouldn't replace the init function, it would be a simple function that the init functions could call to easily setup the filters. Ryan