Description
These two options hold request controls. set_option on the LDAPObject encodes them, but get_option runs what libldap stored back through DecodeControlTuples, i.e. the response control classes. That only works when request and response values happen to share a schema, like paged results. A value-less request like SearchNoOpControl blows up with a pyasn1 error when critical and is silently dropped when not, see #102 and #639. Same thing was reported on the list back in 2011 with PasswordPolicyControl: https://mail.python.org/pipermail/python-ldap/2011q4/003037.html
libldap itself just hands back a copy of the request controls you set, nothing decodes anything, and the module-level ldap.get_option already returns the raw (oid, criticality, value) tuples. So for 4.0 I'd drop the DecodeControlTuples call in LDAPObject.get_option and return the tuples there too. Then nothing ever tries to decode a request control.
Blast radius looks close to zero. I couldn't find anything in tree or downstream that reads these options back, lib389 and FreeIPA only set them, and the docs promise nothing about the return value. TestLDAPObjectOptions._test_controls pins the current behaviour and needs updating along with the change. Discussed with @mistotebe in #639.
Description
These two options hold request controls. set_option on the LDAPObject encodes them, but get_option runs what libldap stored back through DecodeControlTuples, i.e. the response control classes. That only works when request and response values happen to share a schema, like paged results. A value-less request like SearchNoOpControl blows up with a pyasn1 error when critical and is silently dropped when not, see #102 and #639. Same thing was reported on the list back in 2011 with PasswordPolicyControl: https://mail.python.org/pipermail/python-ldap/2011q4/003037.html
libldap itself just hands back a copy of the request controls you set, nothing decodes anything, and the module-level ldap.get_option already returns the raw (oid, criticality, value) tuples. So for 4.0 I'd drop the DecodeControlTuples call in LDAPObject.get_option and return the tuples there too. Then nothing ever tries to decode a request control.
Blast radius looks close to zero. I couldn't find anything in tree or downstream that reads these options back, lib389 and FreeIPA only set them, and the docs promise nothing about the return value. TestLDAPObjectOptions._test_controls pins the current behaviour and needs updating along with the change. Discussed with @mistotebe in #639.