[horde] Too Many Apache Internal Redirects for /nag/task.php?actionID=add_task&tasklist_id=XGcpFDPh0hWdHpJR6F4Opw2

Steffen skhorde at smail.inf.fh-bonn-rhein-sieg.de
Tue Nov 12 20:28:29 UTC 2013


Andy Dorman wrote:
> On 11/06/2013 06:36 AM, Arjen de Korte wrote:
>> Citeren Andy Dorman <adorman at ironicdesign.com>:
>>
>>> On 11/05/2013 01:51 AM, Arjen de Korte wrote:
>>>> Citeren Andy Dorman <adorman at ironicdesign.com>:
>>>>
>>>>> I apologize in advance if this is not the proper mailing list to post
>>>>> this on...not sure if this is a Horde apache config, nag .htaccess or
>>>>> debian packaging problem....
>>>>>
>>>>> My environment is the latest Debian apt install (thanks to Mathieu
>>>>> Parent's hard work), Horde 5.1.4, Tasks (nag) 4.1.2, PHP 5.5, and
>>>>> Apache 2.4.6.
>>>>>
>>>>> Everything has been working fine, but it sometime in the past two
>>>>> months (I do not use nag as often as I should ;-), something caused
>>>>> nag's add_task action to trigger this apache error:
>>>>>
>>>>> 2013-11-04T16:02:09.283781-06:00 yorick apache2[633]: [core:error]
>>>>> [pid 633:tid 140599831254784] [client 71.207.183.174:47426] AH00124:
>>>>> Request exceeded the limit of 10 internal redirects due to probable
>>>>> configuration error. Use 'LimitInternalRecursion' to increase the
>>>>> limit if necessary. Use 'LogLevel debug' to get a backtrace.
>>>>>
>>>>> My related Apache configs are:
>>>>>
>>>>> /etc/apache/confs-available/php-horde.conf is
>>>>> ----------------------------------
>>>>>> <Directory /usr/share/horde>
>>>>>>   AllowOverride Limit FileInfo
>>>>>> </Directory>
>>>>>
>>>>> Apache site config looks like this
>>>>> ----------------------------------
>>>>> <VirtualHost *:80>
>>>>>  ServerAlias beta.mail.army.com
>>>>>  DirectoryIndex index.php
>>>>>  DocumentRoot /usr/share/horde/
>>>>>  SuexecUserGroup www-data www-data
>>>>>  IPCCommTimeout 120
>>>>>  <Files "*.php">
>>>>>    SetHandler fcgid-script
>>>>>    FcgidWrapper /var/www/mail.army.com/php5-cgi .php
>>>>>  </Files>
>>>>>  FcgidMaxRequestLen 10496000
>>>>> </VirtualHost>
>>>>>
>>>>> I did some research and as a test, I changed the /nag/.htaccess file
>>>>> to use "RewriteBase /" instead of "RewriteBase /horde" as shown below.
>>>>> ----------------------------------
>>>>> # IMPORTANT: DO NOT EDIT THIS FILE!
>>>>> # It will be overwritten with any future upgrade.
>>>>>
>>>>> allow from all
>>>>>
>>>>> <IfModule mod_rewrite.c>
>>>>>    RewriteEngine On
>>>>> #    RewriteBase /horde
>>>>>    RewriteBase /
>>>>>    RewriteRule .* - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
>>>>>    RewriteCond   %{REQUEST_FILENAME}  !-d
>>>>>    RewriteCond   %{REQUEST_FILENAME}  !-f
>>>>>    RewriteRule ^(.*)$ rampage.php [QSA,L]
>>>>> </IfModule>
>>>>>
>>>>>
>>>>> The problem goes away with the /nag/.htaccess above.
>>>>>
>>>>> So does anyone have a suggestion for anything I could change in my
>>>>> Apache config to fix this instead of mucking around nag's .htaccess
>>>>> file?
>>>>>
>>>>> Thanks for any thoughts.
>>>>
>>>> Could this /nag/.htaccess file be left over from an earlier
>>>> installation? The .htaccess files for nag in my installation live in
>>>>
>>>>     /nag/config/.htaccess
>>>>     /nag/lib/.htaccess
>>>>     /nag/locale/.htaccess
>>>>
>>>> I don't have one in /nag/.htaccess. Since your DocumentRoot is set to
>>>> /usr/share/horde/ and I don't suspect you have installed Horde in
>>>> /usr/share/horde/horde, it might be something from an older
>>>> installation
>>>> where DocumentRoot was set to /usr/share.
>>>>
>>>
>>> I do not believe the nag/.htaccess is from an earlier install.  It
>>> depends on how the Debian package is set up of course, but normally if
>>> a file is no longer used, it is removed on the next update.
>>>
>>> I really think this may have been caused by an Apache update from 2.2
>>> to 2.4.6 which took place between the last successful add_task action
>>> and the start of this problem with Internal Redirects.
>>>
>>> I am now thinking that what I am going to have to do is tell Apache to
>>> ignore nag's .htaccess files and add my own directives for nag in my
>>> /etc/apache/confs-available/php-horde.conf Either that or switch to
>>> Nginx.  ;-)  I have tested successfully with Nginx, but the servers
>>> that are going to be running this in production are already using
>>> Apache for our spam/virus filtering UI and I can't run two http
>>> servers on port 80.
>>
>> In that case I doubt that the line
>>
>>     DocumentRoot /usr/share/horde/
>>
>> in your Apache site configuration is correct. That really only makes
>> sense if Horde is the only thing on the webserver. If you also have a
>> spam//virus UI on that box, this unlikely will live under the /horde
>> directory.
>>
> 
> I apologize and to clarify.  I made a mistake in copying the Apache site
> config.  As you can see below, these settings (including the
> DocumentRoot) apply ONLY to the horde web site at
> http://beta.mail.army.com.
> 
> <VirtualHost *:80>
>  ServerName beta.mail.army.com
>  DirectoryIndex index.php
>  DocumentRoot /usr/share/horde/
>  SuexecUserGroup www-data www-data
>  IPCCommTimeout 120
>  <Files "*.php">
>    SetHandler fcgid-script
>    FcgidWrapper /var/www/mail.army.com/php5-cgi .php
>  </Files>
>  FcgidMaxRequestLen 10496000
> </VirtualHost>
> 
> The above settings work fine for a Debian install as long as I set
> "RewriteBase /" in the nag/.htaccess file.
> 
> The Spam/virus filtering UI is on a completely different server URL with
> a different document root.
> 
> Also, if the horde document root was incorrect, the entire site would
> not work, no?
> 

The only htaccess with rampage is located in my Horde root, I have a
PEAR install, though:

# IMPORTANT: DO NOT EDIT THIS FILE!
# It will be overwritten with any future upgrade.

allow from all

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteRule .* - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
    RewriteCond   %{REQUEST_FILENAME}  !-d
    RewriteCond   %{REQUEST_FILENAME}  !-f
    RewriteRule ^(.*)$ rampage.php [QSA,L]
</IfModule>

Do you have simimliar htaccess files in other app's root directory? What
happens, if you disable [rename] the file?

-- 

Steffen



More information about the horde mailing list