Bug #34374 for perl-ldap:

Sun Mar 23 16:35:02 2008 MFULLER [...] cpan.org - Ticket created

I have noticed odd (and incorrect) behavior when updating an attribute which is not defined as multi-value. The following example works, but it sets the attribute to the second value. This is arbitrary. Worse, it shouldn't work because the attribute is not defined as multi-value. $ldap_mesg = $ldap_conn->modify($dn, changes => [ replace => [ 'attr_name' => ['val_1', 'val2'] ] ]); However, if you add a third value it will error with code 65. This is the expected behavior. But, it should do that with two values. This is using Sun Directory Server v5. I'm running Net::LDAP .34 on Win XP Pro.

Sun Mar 23 18:07:27 2008 gbarr [...] pobox.com - Correspondence added

CC:	Perl-LDAP Mailing List <perl-ldap [...] perl.org>
Subject:	Re: [rt.cpan.org #34374] incorrect behavior when updating an attribute
Date:	Sun, 23 Mar 2008 17:07:05 -0500
To:	bug-perl-ldap [...] rt.cpan.org
From:	Graham Barr <gbarr [...] pobox.com>

On Mar 23, 2008, at 3:35 PM, Mark Fuller via RT wrote: Show quoted text

> I have noticed odd (and incorrect) behavior when updating an attribute > which is not defined as multi-value. > > The following example works, but it sets the attribute to the second > value. This is arbitrary. Worse, it shouldn't work because the > attribute > is not defined as multi-value. > > $ldap_mesg = $ldap_conn->modify($dn, > changes => [ > replace => [ 'attr_name' => ['val_1', > 'val2'] ] > ]); > > However, if you add a third value it will error with code 65. This is > the expected behavior. But, it should do that with two values. > > This is using Sun Directory Server v5. I'm running Net::LDAP .34 on > Win > XP Pro.

what do you see, in both cases, if you turn on debugging with $ldap_conn->debug(15); just before you call to modify ? Graham.

Sun Mar 23 18:07:28 2008 The RT System itself - Status changed from 'new' to 'open'

Sun Mar 23 22:37:19 2008 MFULLER [...] cpan.org - Correspondence added

On Sun Mar 23 18:07:27 2008, gbarr@pobox.com wrote: Show quoted text

> what do you see, in both cases, if you turn on debugging with > $ldap_conn->debug(15); just before you call to modify ?

Below is the debug output. One is with two attributes (which updates the single-value attribute with the second value). One is with three attributes (which generates the expected error 65). With two values: ================================================================ Net::LDAP=HASH(0x1b9f678) sending: 30 6A 02 01 02 66 65 04 37 78 78 78 67 75 69 64 0j...fe.7xxxguid 3D 78 78 78 78 78 78 2C 6F 75 3D 70 65 6F 70 6C =xxxxxx,ou=peopl 65 2C 6F 75 3D 69 6E 74 72 61 6E 65 74 2C 64 63 e,ou=intranet,dc 3D 78 78 78 78 78 78 78 78 2C 64 63 3D 63 6F 6D =xxxxxxxx,dc=com 30 2A 30 28 0A 01 02 30 23 04 17 78 78 78 57 6F 0*0(...0#..xxxWo 72 6B 50 72 6F 66 69 6C 65 57 6F 72 6B 50 6C 61 rkProfileWorkPla 63 65 31 08 04 01 78 04 03 79 79 79 __ __ __ __ ce1...x..yyy 0000 106: SEQUENCE { 0002 1: INTEGER = 2 0005 101: [APPLICATION 6] { 0007 55: STRING = 'xxxguid=xxxxxx,ou=people,ou=intranet,dc=xxxxxxxx,dc=com' 0040 42: SEQUENCE { 0042 40: SEQUENCE { 0044 1: ENUM = 2 0047 35: SEQUENCE { 0049 23: STRING = 'xxxWorkProfileWorkPlace' 0062 8: SET { 0064 1: STRING = 'x' 0067 3: STRING = 'yyy' 006C : } 006C : } 006C : } 006C : } 006C : } 006C : } Net::LDAP=HASH(0x1b9f678) received: 30 0C 02 01 02 67 07 0A 01 00 04 00 04 00 __ __ 0....g........ 0000 12: SEQUENCE { 0002 1: INTEGER = 2 0005 7: [APPLICATION 7] { 0007 1: ENUM = 0 000A 0: STRING = '' 000C 0: STRING = '' 000E : } 000E : } With three values: ================================================================ Net::LDAP=HASH(0x1b9f678) sending: 30 6F 02 01 02 66 6A 04 37 78 78 78 67 75 69 64 0o...fj.7xxxguid 3D 78 78 78 78 78 70 2C 6F 75 3D 70 65 6F 70 6C =xxxxxx,ou=peopl 65 2C 6F 75 3D 69 6E 74 72 61 6E 65 74 2C 64 63 e,ou=intranet,dc 3D 78 78 78 78 78 78 78 78 2C 64 63 3D 63 6F 6D =xxxxxxxx,dc=com 30 2F 30 2D 0A 01 02 30 28 04 17 78 78 78 57 6F 0/0-...0(..xxxWo 72 6B 50 72 6F 66 69 6C 65 57 6F 72 6B 50 6C 61 rkProfileWorkPla 63 65 31 0D 04 01 78 04 03 79 79 79 04 03 78 78 ce1...x..yyy..xx 78 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ x 0000 111: SEQUENCE { 0002 1: INTEGER = 2 0005 106: [APPLICATION 6] { 0007 55: STRING = 'xxxguid=xxxxxx,ou=people,ou=intranet,dc=xxxxxxxx,dc=com ' 0040 47: SEQUENCE { 0042 45: SEQUENCE { 0044 1: ENUM = 2 0047 40: SEQUENCE { 0049 23: STRING = 'xxxWorkProfileWorkPlace' 0062 13: SET { 0064 1: STRING = 'x' 0067 3: STRING = 'yyy' 006C 3: STRING = 'xxx' 0071 : } 0071 : } 0071 : } 0071 : } 0071 : } 0071 : } Net::LDAP=HASH(0x1b9f678) received: 30 0C 02 01 02 67 07 0A 01 41 04 00 04 00 __ __ 0....g...A.... 0000 12: SEQUENCE { 0002 1: INTEGER = 2 0005 7: [APPLICATION 7] { 0007 1: ENUM = 65 000A 0: STRING = '' 000C 0: STRING = '' 000E : } 000E : }

Mon Mar 24 05:55:10 2008 gbarr [...] pobox.com - Correspondence added

Subject:	Re: [rt.cpan.org #34374]
Date:	Mon, 24 Mar 2008 04:54:36 -0500
To:	bug-perl-ldap [...] rt.cpan.org
From:	Graham Barr <gbarr [...] pobox.com>

On Mar 23, 2008, at 9:37 PM, Mark Fuller via RT wrote: Show quoted text

> > Queue: perl-ldap > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=34374 > > > On Sun Mar 23 18:07:27 2008, gbarr@pobox.com wrote:

>> what do you see, in both cases, if you turn on debugging with >> $ldap_conn->debug(15); just before you call to modify ?

> > Below is the debug output. One is with two attributes (which > updates the > single-value attribute with the second value). One is with three > attributes (which generates the expected error 65).

Which tells me that Net::LDAP is doing the right thing. The packets it is sending look formed ok and the result you get is what the server is returning. So the issue must be on the server side. Graham.

Mon Mar 24 13:35:03 2008 MFULLER [...] cpan.org - Correspondence added

Thanks Graham. Sorry for taking your time. I am able to recreate the behavior using ldapmodify. I'm changing the status to resolved. Mark

Mon Mar 24 13:35:04 2008 MFULLER [...] cpan.org - Status changed from 'open' to 'resolved'