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

[Arjen de Korte]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 308 bytes
Desc: PGP digitale ondertekening
URL: <http://lists.horde.org/archives/horde/attachments/20131106/d88dc909/attachment.bin>