You are viewing a plain text version of this content. The canonical link for it is here.
Posted to wiki-changes@httpd.apache.org by Apache Wiki <wi...@apache.org> on 2007/07/01 15:39:22 UTC

[Httpd Wiki] Update of "ScratchPad/PHPDownload" by noodl

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Httpd Wiki" for change notification.

The following page has been changed by noodl:
http://wiki.apache.org/httpd/ScratchPad/PHPDownload

The comment on the change is:
First draft

New page:
Probably the second most frequently posed problem on #apache (after broken vhosts) is that of PHP scripts being offered for download in the browser.  

The following steps should help to diagnose and fix the problem.

== Flush the browser's cache ==
Delete the cache via the menus, restart the browser and try again.  Even if this doesn't help immediately, remember to perform this step after each of the following.

== Check if the proffered download contains untouched PHP code ==
Accept the download in your browser, open the saved file and see if it contains unparsed PHP code.  If it does then your server isn't corrrectly configured for PHP.

To enable PHP, add the following to your apache config.

FIXME: Replace this with a dedicated page.

{{{
# (other modules)
# Replace the following with the correct path and version of your php module
LoadModule php5_module modules/libphp5.so
# (other modules)

AddHandler application/x-httpd-php php
}}}

If the downloaded file has been parsed by the PHP engine, then go back to step one and flush your browser's cache. If that still doesn't work..

== Check the Content-Type header ==
Using any of the methods documented in [:Recipes/WatchingHttpHeaders], check the value of the Content-Type: http header.

If it's application/x-httpd-php, you'll need to remove all erroneous references to that value as a mime type in your config.  To do this, search your config file(s) for {{{AddType application/x-httpd-php}}} and also remove all references to this 'type' from the mime.types file.  This is especially problematic for Debian/Ubuntu users who's configs contain multiple instances of this error.

If it's text/plain, go back to step one.  If it's anything else, it could be that your script is setting its own type header, or else no type is being set and httpd's {{{DefaultType}}} value is being used.