Fixed in Horde 3.1.4.

I use horde and imp on Cyrus 2.2 IMAP server. I get the following 
warning forwarded to the web browser, when I try to change ACL 
settings in IMP.



Warning: Cannot use a scalar value as an array in 
/opt/horde-webmail-1.0-rc2/lib/Horde/IMAP/ACL/rfc2086.php on line 216



Even this is only a warning (that doensn't look nice on the horde 
interface) it causes in an incomplete or inconsitent response of the 
$capapilities array. I checked the code of rfc2086.php and found the 
following:



        $response_array = explode(' ', $response);

         foreach ($response_array as $var) {

             if (strpos($var, '=') !== false) {

                 $var2 = explode('=', $var, 2);

                 
$capabilities[String::lower($var2[0])][String::lower($var2[1])] = 1;

             } else {

                 $capabilities[String::lower($var)] = 1;

             }

         }

         fclose ($imap);



         return $capabilities;



When I check the response to IMAP command CAPABILITIES to our IMAP 
server I get



2 CAPABILITY

* CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID LOGINDISABLED ACL RIGHTS=kxte 
QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT 
CHILDREN MULTIAPPEND BINARY SORT SORT=MODSEQ THREAD=ORDEREDSUBJECT 
THREAD=REFERENCES ANNOTATEMORE CATENATE CONDSTORE IDLE LISTEXT 
LIST-SUBSCRIBED X-NETSCAPE URLAUTH



So, the following will happen:



The foreach goes well until it comes to



$var="SORT";



and $capabilities[sort]=1 will be set via the "else" part.



Next time of "foreach" the if part will be triggered with



$var="SORT=MODSEQ";

$var2= array(

        'sort'=>'modseq'

        );



and that results in



$capabilities[sort][modseq]



can't be set, 'cause $capabilities[sort] is already set to scalar value 1.

This means, the name of the capabilities aren't unique key values.



I hacked using a simple ellimination of the SORT=MODEQ capability but 
- of course - the $capabilities array is incomplete now.