
|
If you were logged in you would be able to see more operations.
|
|
|
| Resolution Date: |
24/Sep/05 11:14 AM
|
|
If a client calls an arbitrary extended operation, the server (namely the ExtendedHandler) throws a NotImplementedException. After this, the call of the client blocks, and the client hangs.
I suggest to change the handler to simply send an error code 2 (LDAP_PROTOCOL_ERROR) with message "Unrecognized extended operation" back to the client. This is the expected behavior if an extended operation is not supported by the server.
Attached you find a test case, which demands an always unknown extended operation (OID=1.1) and checks the result. Error code 2 leads to a CommunicationException in JNDI. I have tested this with several LDAP server implementations, behavior was always as expected.
I have also attached a patch, which changes the ExtendedHandler to behave like described above. Not a big thing, but it leads to compliant behavior for extended ops, even if we do not have any in place yet.
|
|
Description
|
If a client calls an arbitrary extended operation, the server (namely the ExtendedHandler) throws a NotImplementedException. After this, the call of the client blocks, and the client hangs.
I suggest to change the handler to simply send an error code 2 (LDAP_PROTOCOL_ERROR) with message "Unrecognized extended operation" back to the client. This is the expected behavior if an extended operation is not supported by the server.
Attached you find a test case, which demands an always unknown extended operation (OID=1.1) and checks the result. Error code 2 leads to a CommunicationException in JNDI. I have tested this with several LDAP server implementations, behavior was always as expected.
I have also attached a patch, which changes the ExtendedHandler to behave like described above. Not a big thing, but it leads to compliant behavior for extended ops, even if we do not have any in place yet. |
Show » |
|