Update: If you’re having other trouble with your 1&1 Drupal setup, such as the “500 Server Error” or problems with clean URLs, try this post on Drupal.org:
Thank you, thank you, thank you! This was bugging the hell out of me, and the link from the Drupal installer is less than helpful for sorting the register_globals issue out:
I run a couple of Drupal sites on 1and1 for historical reasons (3 years free). A while ago, I dutifully upgraded them to Drupal 5.7. And was surprised to find that PHP’s register_globals was enabled.
All this time, I’ve been running with a .htaccess file which explicitly disabled that setting — if 1and1’s Apache was running mod_php only, it turns out. Apparently, such PHP settings in .htaccess files don’t do anything if running PHP in CGI mode.
Since Drupal 5.7 warns you if register_globals is enabled, it became glaringly obvious that they were. Not a happy situation at all. Drupal is coded intelligently and securely in general, but register_globals is inherently a security risk. It should never be enabled. But worse, in many versions of PHP, there is a bug which allows even more exploits to be used when register_globals is enabled. This bug has been fixed in recent versions of PHP, but hosting companies like 1and1 are notorious for not upgrading their PHP, MySQL, etc. versions.
For reference, the site above suggests to create a .htaccess file at the root of your hosting directory (~/) and add the following line to it:
AddType x-mapp-php5 .php
This helps with MediaWiki as well, but MediaWiki does have a workaround that auto-forwards the .php file to it’s corresponding .php5 file if it detects that it is running under php4.