ID: 18648 Comment by: jesse at skybuilders dot com Reported By: ms at ecs dot soton dot ac dot uk Status: Bogus Bug Type: Apache2 related Operating System: All PHP Version: 5CVS-2003-01-29 (dev) / 4CVS-20020121 (stable) New Comment:
>From Jesse Burkhardt, 2003/12/17 Use the following link to reproduce this is Apache2/php4 bug: http://drupal.skybuilders.com/phpBugTest.php Also cut and paste this text to enter into the form's textarea, observing how the paragraph ordering becomes disturbed: <BEGIN SNIP> <br /><br /> A. <br /><br /> Apache responds "406 Not Acceptable" and lists xxx.php as a possible alternative of MIME type application/x-httpd-php. If the "Options MultiViews" is in effect, Apache serves xxx.php when that is the shortest (or only) choice. <br /><br /> Adding a "MultiViewsMatch Handlers Filter" or renaming to xxx.html.php don't help. I think we need to use PHP as a filter; 4.3.2 mentions having set a new handler but doesn't say this bug is closed. <br /><br /> BTW, what's the reason why we "Do not use Apache 2.0 and PHP in a production environment neither on Unix nor on Windows."? (That warning comes from http://www.php.net/manual/en/install.apache2.php) <br /><br /> B. <br /><br /> Apache responds "406 Not Acceptable" and lists xxx.php as a possible alternative of MIME type application/x-httpd-php. If the "Options MultiViews" is in effect, Apache serves xxx.php when that is the shortest (or only) choice. <br /><br /> Adding a "MultiViewsMatch Handlers Filter" or renaming to xxx.html.php don't help. I think we need to use PHP as a filter; 4.3.2 mentions having set a new handler but doesn't say this bug is closed. <br /><br /> BTW, what's the reason why we "Do not use Apache 2.0 and PHP in a production environment neither on Unix nor on Windows."? (That warning comes from http://www.php.net/manual/en/install.apache2.php) <br /><br /> C. <br /><br /> Apache responds "406 Not Acceptable" and lists xxx.php as a possible alternative of MIME type application/x-httpd-php. If the "Options MultiViews" is in effect, Apache serves xxx.php when that is the shortest (or only) choice. <br /><br /> Adding a "MultiViewsMatch Handlers Filter" or renaming to xxx.html.php don't help. I think we need to use PHP as a filter; 4.3.2 mentions having set a new handler but doesn't say this bug is closed. <br /><br /> BTW, what's the reason why we "Do not use Apache 2.0 and PHP in a production environment neither on Unix nor on Windows."? (That warning comes from http://www.php.net/manual/en/install.apache2.php) <br /><br /> D. <br /><br /> Apache responds "406 Not Acceptable" and lists xxx.php as a possible alternative of MIME type application/x-httpd-php. If the "Options MultiViews" is in effect, Apache serves xxx.php when that is the shortest (or only) choice. <br /><br /> Adding a "MultiViewsMatch Handlers Filter" or renaming to xxx.html.php don't help. I think we need to use PHP as a filter; 4.3.2 mentions having set a new handler but doesn't say this bug is closed. <br /><br /> BTW, what's the reason why we "Do not use Apache 2.0 and PHP in a production environment neither on Unix nor on Windows."? (That warning comes from http://www.php.net/manual/en/install.apache2.php) <br /><br /> E. <br /><br /> Apache responds "406 Not Acceptable" and lists xxx.php as a possible alternative of MIME type application/x-httpd-php. If the "Options MultiViews" is in effect, Apache serves xxx.php when that is the shortest (or only) choice. <br /><br /> Adding a "MultiViewsMatch Handlers Filter" or renaming to xxx.html.php don't help. I think we need to use PHP as a filter; 4.3.2 mentions having set a new handler but doesn't say this bug is closed. <br /><br /> BTW, what's the reason why we "Do not use Apache 2.0 and PHP in a production environment neither on Unix nor on Windows."? (That warning comes from http://www.php.net/manual/en/install.apache2.php) <br /><br /> <END SNIP> Previous Comments: ------------------------------------------------------------------------ [2003-07-20 12:57:07] vesely at tana dot it For completeness, I'd like to mention that the setting suggested > [4 Feb 3:05pm CST] [EMAIL PROTECTED] wrote > > # good (d) > AddType application/x-httpd-php .php works owlright except that if a request for xxx.php arrives w/o extension like GET /xxx HTTP/1.1 Accept: text/* Apache responds "406 Not Acceptable" and lists xxx.php as a possible alternative of MIME type application/x-httpd-php. If the "Options MultiViews" is in effect, Apache serves xxx.php when that is the shortest (or only) choice. Adding a "MultiViewsMatch Handlers Filter" or renaming to xxx.html.php don't help. I think we need to use PHP as a filter; 4.3.2 mentions having set a new handler but doesn't say this bug is closed. BTW, what's the reason why we "Do not use Apache 2.0 and PHP in a production environment neither on Unix nor on Windows."? (That warning comes from http://www.php.net/manual/en/install.apache2.php) ------------------------------------------------------------------------ [2003-05-04 08:36:37] anrdaemon at mtu-net dot ru Thanx to [EMAIL PROTECTED] /me stupid... AddInputFilter PHP .php solves all problems. ------------------------------------------------------------------------ [2003-03-05 07:32:56] jorton at redhat dot com The default configuration in Red Hat Linux has only the <Files *.php*> section. This bug appears to occur if the "AddType x-httpd-php .php" is added *as well* as the <files *.php> section. http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=76559 ------------------------------------------------------------------------ [2003-02-20 09:43:34] apiset at hotmail dot com The default httpd configuration on RH8.0 use <Files *.php> SetOutputFilter PHP SetInputFilter PHP LimitRequestBody 524288 </Files> so is this RedHat fault? I replace above lines with AddType application/x-httpd-php .php and it works!!! should tell redhat about this ------------------------------------------------------------------------ [2003-02-07 21:50:42] [EMAIL PROTECTED] First I made a typo in my previous comment. I mean "application/x-httpd-php" everywhere I wrote "x-http-php". Anyway let me mark this as bogus... (The problem turned out to be a user fault.) ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/18648 -- Edit this bug report at http://bugs.php.net/?id=18648&edit=1
