[
https://issues.apache.org/jira/browse/DIRSERVER-1183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12601854#action_12601854
]
Emmanuel Lecharny commented on DIRSERVER-1183:
----------------------------------------------
Added a test to cover this issue :
/**
* test an RDN with escaped comma
*/
@Test
public void testRdnWithEscapedComa() throws InvalidNameException
{
assertTrue( RdnParser.isValid( "a=b\\,c" ) );
assertEquals( "a=b\\,c", new Rdn( "a=b\\,c" ).toString() );
assertTrue( RdnParser.isValid( "a=\"b,c\"" ) );
assertEquals( "a=b\\,c", new Rdn( "a=\"b,c\"" ).toString() );
assertEquals( "a=\"b,c\"", new Rdn( "a=\"b,c\"" ).getUpName() );
assertTrue( RdnParser.isValid( "a=\"b\\,c\"" ) );
assertEquals( "a=\"b\\,c\"", new Rdn( "a=\"b\\,c\"" ).getUpName() );
assertEquals( "a=\"b,c\"", new Rdn( "a=\"b\\,c\"" ).toString() );
}
The third test is failing.
> searching with quoted attribute values in a DN causes either noSuchObject or
> invalidDNSyntax
> --------------------------------------------------------------------------------------------
>
> Key: DIRSERVER-1183
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1183
> Project: Directory ApacheDS
> Issue Type: Bug
> Components: ldap
> Environment: Windows XP SP2, cygwin, ldapsearch 2.3.39, ADS trunk
> Reporter: Matt Parker
> Assignee: Alex Karasulu
>
> searching with a base DN that has quoted values results in noSuchObject. for
> example:
> ldapsearch -b 'cn=foo' ...
> works, but:
> ldapsearch -b 'cn="foo"' ...
> causes noSuchObject. Further, if there is an escaped value inside the quotes,
> invalidDNSyntax occurs:
> ldapsearch -b 'cn=Parker\, Matt' ...
> works, but:
> ldapsearch -b 'cn="Parker\, Matt"' ...
> causes invalidDNSyntax.
> RFC 2253 section 4 (http://tools.ietf.org/html/rfc2253#section-4) clearly
> states that this is legal, but is obsoleted by 4514, which isn't as clear (at
> least to me). Although since most clients that are in use were probably at
> least written against 2253, it makes sense to continue to support quoted
> values for maximum compatibility, even if it's optional.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
