Batch API not working when http policy of mod_security is enabled.

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

Are there any errors in Apache's logging?

- Arie

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
        </ifModule>

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

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

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.

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.
tx

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.
krgds
s

I am having the same problem

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

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.

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.

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

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

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!
Julie
julie_carlson@comcast.net

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...

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

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

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
        </ifModule>

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

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.

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
</ifModule>

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.

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!

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
</LocationMatch>

Use the id in your mod security rules.

Users of shared hosting may need help from support.

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 2.1.6.1] 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.

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, 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.

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.

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?

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.

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

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

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.

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

Related: #694602: Warn user on install time and in reports about the presence of mod_security..

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."

Thank you for following up.