I've never seen this before:

An unrecoverable error has occured. You can find the error message below. It is advised to copy it to the clipboard for reference. Please continue to the update summary

An HTTP error 406 occured. update.php?op=do_update

While trying to run system update #1015, while logged in as user #1. The system is running under Apache via suexec, PHP version 4.4.4. Setting $access_check = FALSE; has no effect.

On the same host I can create a clean Drupal 4.6.10 install and update to 4.7.4 with no errors, but then I get the same error as above trying to update to HEAD so it seems specific to Drupal 5.x.

Comments

ChrisKennedy’s picture

ChrisKennedy commented
Status: Active » Closed (duplicate)

Duplicate of http://drupal.org/node/82690

Feel free to set that one as critical though - I would have if more people had reported it.

ChrisKennedy’s picture

ChrisKennedy commented
Status: Closed (duplicate) » Active

Sorry - it's a different error code. But does the patch in that issue fix the problem?

pwolanin’s picture

pwolanin commented

No, just tried the patch at http://drupal.org/node/82690#comment-145954, and unfortunately it does not fix it.

However, it does seem like it might be similar, since it's again at the /update.php?op=selection and gives an HTTP error.

pwolanin’s picture

pwolanin commented

Also, FWIW the site is using Apache 1.3.37.

ChrisKennedy’s picture

ChrisKennedy commented

Does the discussion at http://drupal.org/node/80299 help?

pwolanin’s picture

pwolanin commented

hmmm, does sound similar, but this host seems not to be running mod_security, and the 4.6 -> 4.7 update runs fine.

pwolanin’s picture

pwolanin commented

Ok, it's confirmed, as with http://drupal.org/node/82690, to be a JS issue of some sort. If I disable JS in the browser (FF 2.0), the update runs with no error.

pwolanin’s picture

pwolanin commented

maybe a broader problem with JS- with the same hosting company, but different server, NONE of the collapsible fieldsets work (and I can't see the content of them), but update.php runs ok.

pwolanin’s picture

pwolanin commented

Further minor point- on server #1 (update.php fails, fieldsets work) the resize grippie at the bottom of text areas appears as a set of horizontal lines. On server #2 (fieldsets fail) the resize grippie is at the bottom center of the textarea, but appears as a set of diagonal lines (like Drupal 4.7)!?

ChrisKennedy’s picture

ChrisKennedy commented

Is it possibly a proxy/caching problem?

pwolanin’s picture

pwolanin commented

no, I don't think so- Drupal 4.7 on the same servers works perfectly (fieldsets collapse, updates run, etc).

pwolanin’s picture

pwolanin commented

Tech support at the hosting company says

406 errors denote a block by mod_security.

Also, there was apparently a minor mis-configuration in server #2's mod_security, so now that's changed and both behave like server #1 (fieldsets work, but 406 error running update.php with JS enabled).

pwolanin’s picture

pwolanin commented

tech support's suggested way of temporarily disabling mod security:

Temporarily you can add the following line to your .htaccess file:

SecFilterEngine Off

This will essentially disable mod_security for the domain. However, that line should be removed once you have completed what was needed. mod_security provides a great deal of protection against wide spread script exploits.

However, since the JS is doing nothing useful except making hte page prettier, it seems to me the issue should be addressed there.

ChrisKennedy’s picture

ChrisKennedy commented

Does disabling mod security fix the problem? If so this issue shouldn't be critical.

It would also be helpful to see the request logs surround this functionality in order to see what's triggering mod_security.

heine’s picture

heine commented
Priority: Critical » Normal

I just looked back in my posting history to give you a taste for "what can trigger" it.

curl, Lynx, exec, To: user@example.com, rpm, txt, mother (!), and in #drupal-support I've encountered perl, python, ssh, [a-z]ssh, echo, bash, depending on the host's rule set.

I'm for "won't fixing" this.

pwolanin’s picture

pwolanin commented

Temporarily disabling JS in the browser, or disabling mod_security in .htaccess as described above are both work-arounds that succeed for me on this host. If this is a "won't fix" it needs to be documented in UPGRADE.txt, and/or on the troubleshooting FAQ page.

pwolanin’s picture

pwolanin commented

My host has very helpfully looked at the error logs to find the trigger- here's what they say:

[11/Dec/2006:06:52:15 -0600] [example.net/sid#a86e874][rid#a24d934][/update.php][1] Access denied with code 406. Pattern match "^$" at HEADER("Content-Length")

The error essentially means that the POST content-length is not being specified, therefore it is being blocked.

So this sounds very closely related to the problem at http://drupal.org/node/82690, rather than triggering off something in the text.

heine’s picture

heine commented
Status: Active » Closed (duplicate)

Thank you! Marking as duplicate of http://drupal.org/node/82690.