When a custom error page has been defined for 404 and/or 403 errors, but the page does not exist in the site, drupal_not_found and drupal_access_denied will be re-called over and over, inserting rows to the watchdog each time, until PHP segfaults.
This applies to both DRUPAL-4-6 and HEAD branches.
The patches I'm attaching add a check for the value of the 404/403 path setting not being the same as the url that triggered the 404/403 request in the first place.
if ($path && $path != $_GET['q]) ...
We have just implemented this patch in production on all SRI websites (e.g. www.cfrb.com) and it's fixed the behaviour as intended.
Comment | File | Size | Author |
---|---|---|---|
#2 | common_inc_4-7HEAD.patch | 819 bytes | rkerr |
#1 | common_inc_4-6.patch | 835 bytes | rkerr |
Comments
Comment #1
rkerr CreditAttribution: rkerr commentedAttatching patch for DRUPAL-4-6 CVS branch.
Comment #2
rkerr CreditAttribution: rkerr commentedAttaching patch for HEAD CVS branch (4.7).
Comment #3
moshe weitzman CreditAttribution: moshe weitzman commentedi can't reproduce this infinite loop in HEAD. anyone else?
Comment #4
dopry CreditAttribution: dopry commentedI can reproduce against 4.7-beta3.
the patch fixes the issue.
normal 404 and 403 pages work if they exist after patch.
I cannot reproduce against 4.6.5.
Comment #5
Dries CreditAttribution: Dries commentedCommitted the patch against HEAD. Will commit against the DRUPAL-4-6 branch later today. Not marking 'fixed' yet.
Comment #6
rkerr CreditAttribution: rkerr commentedThanks, Dries.
To reproduce... set 403 and/or 404 to "node/{some number that does not exist as nid in node table}"
then try to addess a restricted page, or a path that will generate a 404.
At least, that is what will create the problem for me.
Comment #7
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedchanging version and priority.
Comment #8
Dries CreditAttribution: Dries commentedCommitted to DRUPAL-4-6. Thanks.
Comment #9
(not verified) CreditAttribution: commented