nstalling Drupal

The installation has encountered an error.
Please continue to the error page
An HTTP error 501 occurred. http://locahost/drupal6/install.php?locale=en&profile=default&id=1&op=do

This is what is getting to me after giving database details while installing drupal 6.5

using Fedora Core 8 Apache 2.2, PHP 5.2 MySql 5.1


aaronk’s picture

also having this problem... This problem followed difficulty installing the database. (had to manually fill out settings.php file). also, now anything in install.php just shows a white page.

mysql 5.1, php 5.2, apache, 2.2, red hat

keith.smith’s picture

Title: nstalling DrupalThe installation has encountered an error.Please continue to the error pageAn HTTP error 501 occurred » Installing Drupal: The installation has encountered an error. Please continue to the error page An HTTP error 501 occurred
Category: bug » support
Priority: Critical » Normal
ainigma32’s picture

Status: Active » Postponed (maintainer needs more info)

Are there any errors in Apache's logging?

- Arie

vbrtrmn’s picture

I had the same problem, I disabled mod_security2 for the virtual host and it installed fine.

In the VirtualHost, in httpd.conf or whatever add:

        <ifModule mod_security2.c>
                SecRuleEngine off

Probably won't work in .htaccess, may return a 500 error.

ainigma32’s picture

Status: Postponed (maintainer needs more info) » Fixed

Looks like tomypaul and aaronk won't be posting any feedback so I'm setting this to fixed.

Feel free to reopen if you think that is wrong.

- Arie

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

wmostrey’s picture

Status: Closed (fixed) » Active

I'm really not sure why this issue has been marked "fixed". Not everyone can disable mod_security and I'm not sure if it's advisable to require disabling it in the first place. On my shared hosting provider it's impossible to do so even if I wanted and this leaves me with a Drupal instance on which I can't run update.php.

Stephaan’s picture

I join wmostrey's comment. I also make use of shared hosting. I have the same problem: the database was set up after some issues but now seems ok. Now the installation of the site fails with the error message "An HTTP error 501 occurred. http://www.mysite.eu/install.php?locale=en&profile=default&id=1&op=do".

I don't know how to proceed from here.
I guess I will delete the database, remove Drupal, and retry all over again.
If any better suggestion, most welcome.

Stephaan’s picture

I have now been able to install drupal on the host by first installing it on my local PC using XAMPP. I then moved the site from local to the host according to the description in http://learnbythedrop.com/drop/132

This worked for me.

Paras Kuhad’s picture

I am having the same problem

using fedora 10, apache 2.2 , mysql 5.0, php 5.2

wmostrey’s picture

I would be tempted to mark this as a critical issue since anyone who is not able to edit his httpd.conf or to override this setting in the .htaccess file is stuck with this error and is unable to run update.php, possibly leading to security-related issues.

wmostrey’s picture

Version: 6.5 » 6.9
kmberry’s picture

I would say this definitely is critical since it took me 6 hours to figure it out. I am using rawhide with drupal cvs and I had to comment out the "Include modsecurity.d/modsecurity_crs_30_http_policy.conf" line in my mod_security.conf file. I am using mod_security-2.5.9-1.fc11.i586.

wmostrey’s picture

Version: 6.9 » 6.12
Priority: Normal » Critical

Agreed. And it's even worse for people that simply can not change the mod_security.conf file.

shark’s picture

I have this error as well. I'm on a shared hosting system with no access to apache logs or configuration files.

If it helps, uname -a on the system I'm using gives:

SunOS hostname 5.10 Generic_118833-36 sun4u sparc SUNW,Sun-Fire-V240

Puddlez’s picture

I am having the same issue and posted on it in the forums: http://drupal.org/node/508452#comment-1769966 . I can get as far as starting the "installation" step after the database step completes as expected. This is something my customers have been asking about and it looks like a great tool, if it can be installed. Any updates or info that might help would be greatly appreciated.

Thanks a bunch!

My PC: Windows Vista - Cable Modem
Host: Yahoo
MySQL: Server version: 4.1.14
phpMyAdmin - 2.11.9

Installing Drupal
The installation has encountered an error.
Please continue to the error page

An error occurred. http://juliecarlson.net/drupal-6.13/install.php?locale=en&profile=defaul...

drupalegg’s picture

I ended up putting this in setting.php

$db_url = 'mysql://MyDatabaseUsername:MyDatabasePassword@localhost/MyDatabaseName;

When I go back to Drupal install screen, database started to install and all worked fine.

I hope this helps

mediameriquat’s picture

Version: 6.12 » 6.13

Any update on this issue?

This is VERY frustrating... Sysadmins don't give a damn. Error messages provide no hints whatsoever. Drupal forums give no answers. Clients want a website in good order NOW.

Drupal = Hell

wmostrey’s picture

Version: 6.13 » 7.x-dev
Category: support » bug

I'm moving this to the Drupal 7 queue since this issue still exists, I just tested it. Being unable to run install.php or update.php on a shared hosting provider is really a show stopper.

I understand that this is a solution:

        <ifModule mod_security2.c>
                SecRuleEngine off

But as we all know (and perhaps experienced) not every shared host does or allows custom apache configurations.

alexanderpas’s picture

Title: Installing Drupal: The installation has encountered an error. Please continue to the error page An HTTP error 501 occurred » install.php and update.php not working when http policy of mod_security is enabled.
Heine’s picture

Please find out which rule(s) cause this issue by reviewing the audit logs.

If you run mod_security, don't be surprised stuff breaks.

mediameriquat’s picture

The two main functions affected by this bug are update.php and the automatic import of translations (including the "reimport packages" tool in l10_client)

I confirm that setting Apache as follows solved my problems :

<ifModule mod_security2.c>
     SecRuleEngine off
Heine’s picture

Status: Active » Closed (won't fix)

Won't fix for now as a server configuration issue.

If you can show us a rule that enables us to work around this issue, please reopen.

Note, the point of the mod_security rule may well be to DENY access to install.php or update.php, in which case a workaround is not possible.

Mavro’s picture

Hi Everyone,

I had this exact problem tonight while installing Open Atrium on my Mac running MAMP. I checked MAMP's PHP error log and found this:

PHP Fatal error: Allowed memory size of 16777216 bytes exhausted (tried to allocate 40 bytes)

Even though I had my memory limit in MAMP's php.ini set to the Drupal recommended 16M, the installer needed more. I increased the memory limit to 160 and the installer finished successfully after I refreshed the install page with the 501 error. I'm not sure what the minimum memory limit is for the install to work. The memory issue might have been all of the included modules with the Open Atrium install profile. The memory limit also might be able to be decreased after install.

I hope this helps!

inforeto’s picture

Please do some troubleshooting to find out the exact rules that block the install.

A fix to avoid disabling the security is to add exceptions.
Code usually goes in modsec2.conf

For example

<LocationMatch "/update.php">
        SecRuleRemoveById 990011

Use the id in your mod security rules.

Users of shared hosting may need help from support.

flickerfly’s picture

Status: Closed (won't fix) » Active

Good news, I'm pretty sure it isn't just blocking install.php and update.php out of hand.

This is spit into the logs. It would appear to be a problem with Request headers not having a Content-Type? My provide is pretty flexible with me and has opened up some other areas where such problems have cropped up when uploading files.

[Wed Jan 20 11:43:01 2010] [error] [client] ModSecurity: Access denied with code 501 (phase 2). Match of "rx (?:^(?:application\\\\/x-www-form-urlencoded(?:;(?:\\\\s?charset\\\\s?=\\\\s?[\\\\w\\\\d\\\\-]{1,18})?)??$|multipart/form-data;)|text/xml)" against "REQUEST_HEADERS:Content-Type" required. [file "/etc/apache2/modsecurity_crs/modsecurity_crs_30_http_policy.conf"] [line "69"] [id "960010"] [msg "Request content type is not allowed by policy"] [severity "WARNING"] [tag "POLICY/ENCODING_NOT_ALLOWED"] [hostname "d6test.domain.com"] [uri "/install.php"] [unique_id "R5esoc-ASakAAHGeOqAAAAAI"]

Anyway, hope that can be fixed pretty easily and get back-ported to D6.

flickerfly’s picture

This rule appears to also be a problem for devel_generate module where I can't generate more than 51 nodes, but can generate 50 nodes.

Devel Issue: #691672: ModSecurity complains when generating more than 50 nodes

Heine’s picture

Title: install.php and update.php not working when http policy of mod_security is enabled. » Batch API not working when http policy of mod_security is enabled.
Priority: Critical » Normal
flickerfly’s picture

Heine, I'd like to argue that this is critical because it blocks install of drupal in environments where the configuration can't be changed and it blocks updates in environments where ModSecurity has been upgraded/installed after initial install causing potentially insecure drupal installs that can not be resolved since you can't operate the newest version of a module because you can't update the db to be compatible with it.

Heine’s picture

Batch API, or rather, jquery.ajax uses application/xml as content type for the POSTS. BTW application/xml is the default content type for XMLHttpRequests, so I dont' understand why the author of mod_security wants to block it.

We could explicitly set application/x-www-form-urlencoded in the ajax options (progress.js), but I wonder how long it would take for mod_security to block that as well.

flickerfly’s picture

This article disagrees about the content type having a default on POSTs: http://java.sun.com/developer/technicalArticles/J2EE/AJAX/

"An HTTP POST requires a Content-Type header to be set on the XMLHttpRequest object by using the following statement:

req.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
req.send("id=" + encodeURIComponent(idTextField.value));"

That article is from 2005. Has something changed or is the author just plain wrong?

Heine’s picture

Maybe they need this type for use with the server backend they are using.

W3C specifically states in XMLHttpRequest Working Draft section 4.6.3 The send() method step 3:

If the request method is GET or HEAD act as if data is null.

If the data argument has been omitted or is null, do not include a request entity body and go to the next step.

Otherwise [eg for POST requests], let encoding be UTF-8, mime be text/plain, and then follow these rules:

data is a Document
Let encoding be the preferred MIME name of the character encoding of data. If encoding is UTF-16 change it to UTF-8.
Let mime be application/xml.
If no Content-Type header has been set using setRequestHeader() set a Content-Type request header with a value of mime;charset=encoding.

flickerfly’s picture

I opened up an issue in ModSecurity's tracker. I believe this is the link, but I'm not sure (their tracker is confusing at points): https://www.modsecurity.org/tracker/browse/CORERULES-30

Damien Tournoud’s picture

Category: bug » support

This is still a support request. There is no bug in Drupal here, as far as I can tell.

wmostrey’s picture

Category: support » bug

This really is a bug for the reasons stated in comment #7. We want people to be able to at least install Drupal on shared hosts (for example), right? So if there's anything we can do to make this work, we should.

Damien Tournoud’s picture

Category: bug » support

I absolutely don't doubt that this is a bug... in mod_security. Drupal has nothing to do with that.

Heine’s picture

flickerfly’s picture

Status: Active » Closed (fixed)

Good news, ModSecurity agreed that this was their problem and have fixed it. Here's the exact statement...

"Added the "application/xml" Content-Type to allowed list. Wil be fixed in next CRS rev."

Heine’s picture

Status: Closed (fixed) » Closed (won't fix)

Thank you for following up.