Answer: Because it makes conversations flow in a nonsensical order.
Question: Why is top-posting wrong?
>> firstname.lastname@example.org wrote:
>>> I have been using apache, PHP and mysql for years with no problems.
>>> I just suffered a computer crash and my backup failed, so I had to
>>> reinstall. However, now I have a problem. I tried "pkg_add -r php5"
>>> and the latest PHP5 from www.php.net(www.php.net used to work, but
>>> that was before php5 existed).
> Kevin Kinsey wrote:
>> The first thing to note is that PHP can install three different
>> a CLI (command line interface) executable at /usr/local/bin/php, a CGI
>> (common gateway interface) at /usr/local/bin/php-cgi, and an Apache SO
>> (shared object) at /usr/local/libexec/apache/libphp5.so.
>> So, first question, which of the above files exist? When you run
>> `php -i` in a shell, you are accessing the CLI, most likely (running
>> `which php` should tell you), and IIRC the package doesn't build
>> the Apache SO, so the problem may be in your Apache configuration
>> (is it configured to properly use the CGI executable?), or the
>> complete lack of a CGI in the location shown above.
>>> If I access phpinfo() with my browser, it fails. When I try to
>>> run a PHP script, I get the error:
>>> >cgi error:
>>> > The following CGI application misbehaved by not
>>> > returning a complete set of HTTP headers.
>>> > The headers it did not return are:
>>> > This error message means PHP failed to output anything at all. To
>>> > get to a sensible error message, change to the PHP executable >
>>> directory and run PHP -i. If php has any problems running, then a
>>> suitable error message will be displayed which will give a clue
>>> as to what needs to be done next. If you get a screen full of HTML codes,
>>> then PHP is working.
>>> > Once PHP is working on the command line, try accessing the script
>>> once again. If it still fails then it could be one of the following:
>>> > *The file permissions on your script, php.ini, or any extensions
>>> > you are trying to load are such that the anonymous internet user
>>> > ISUR_<machinename> cannot access them.
Kevin Kinsey wrote:
>> This might indicate that you have the CGI *only*.
>> Verify that the Apache daemon user (www? nobody?) has access to the files
>> as mentioned above. And, likely, the same user should be able to run the
>>> > *The script file does not exit (or possible isn't where you think
>>> > it is relative to your web root directory). If the script does
>>> > exit then the server will return a 404 error instead.
>>> > I didn't get the 404 error, so I think my script exits. When I >
>>> typed PHP -i, I received 4 pages of HTML code. This means PHP
>>> works. I tried > phpinfo() from my browser and still nothing. I
>>> have been fighting this for 3 weeks and
>>> > reinstalled many times. I tried this on FreeBSD-5.4, 6.1 and
>>> 6.2. All > three operating systems produce the same result. > I
>>> found out that apache runs in a jail and uses chroot. I added the >
>>> directory it says and still nothing.
>>> This is where I get stuck. Thanks in advance for any help.
Kevin Kinsey wrote:
>> The apache log (maybe /var/log/httpd.error.log?) should have some
>> information, perhaps in addition to what you have seen. I don't know
>> much about running Apache in a jail; you'll need to keep in contact
>> with the list and hope that someone with a clue notices your problem.
>> Since the question is really about PHP instead of FreeBSD, you might
>> try some PHP forums/mail lists as well.
> I am using PHP/Mysql to manage my business database. I have a database
> that contains my orders. I use my browser to print these orders. I
> think it's the Apache SO version. /usr/local/bin/php and
> /usr/local/libexec/apache/libphp5.so are there. I just reinstalled it
> twice today with the exact same result. I reinstalled according to the
> tip another guy sent me. I can use the php CLI, thats how I get 4
> pages of HTML code. But 'phpinfo()' still doesn't display in my
> browser. Which files should i check permissions on to see if the groups
> 'www' and 'nobody'?
> I did check the '/var/log/httpd.error.log'. It says:
> > Wed Sep 19 10:42:56 2007] [notice] Apache/1.3.37 (Unix) PHP/5.1.6
> with Suhosin-patch configured -- resuming normal operations
> > [Wed Sep 19 10:42:56 2007] [notice] Accept mutex: flock (Default: flock)
> > [Wed Sep 19 10:43:56 2007] [error] [client 127.0.0.1] File does not
> exist: /usr/
> > local/www/data/favicon.ico
> I did install the file 'favicon.ico' and that solved the problem, the
> '/var/log/httpd.error.log' is now OK.
> I already tried sending this problem to the PHP forms without any luck.
Please carbon-copy the freebsd-questions list to make sure your
mail isn't lost here.
If Apache is running PHP as an SO, they you should have something like
the following in /usr/local/etc/apache/httpd.conf:
LoadModule php5_module libexec/apache/libphp5.so
AddType application/x-httpd-php .php
If these aren't present, then Apache doesn't serve PHP documents
Being ugly isn't illegal. Yet.