directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny (JIRA)" <>
Subject [jira] Commented: (DIRSERVER-638) Searches with escaped characters in the base DN fail.
Date Sun, 06 Aug 2006 05:57:15 GMT
    [ ] 
Emmanuel Lecharny commented on DIRSERVER-638:

Yes, I think I introduced a regression in the current parser. Octothrops Strings and PairChar
or escaped characters are currently parsed, but not transformed to their counterparts.

However, this is a complicated one (with DIRSERVER-631) in that the current LdapDN structure
will not be able to store those values correctly - except for escaped chars- AFAIR.

We have three cases :
- <oid>=#<hexPairs>* : the value is binary and should be stored in a byte[]
- <attrType> = <String with escaped chars like \+ : those escaped chars should be
transformed to their real values in the attributeValue
- <attrType> = <String with PairChars like \4A> : the problem here is that this
is supposed to be a String, so those HexPair are supposed to represent valid UTF-8 sequences,
which could perfectly be wrong. The parser then have to check that those values are correct,
and transform them to their chars counterpart. Remember that DN are transfered as bytes representingan
UTF-8 encoded value.

Alex, if it can wait, I can handle this JIRA and DIRSERVER-631 when I'll be back. Not that
I don't think that you won't be able to fix the code, or that I don't want you to touch *my*
code (you know, the *it's my code* syndrom), but much more because it's because the regression
is my fault.  This piece of code is a little bloated, because I'm working with the initial
UP String, and a Position Objet, and many methods in StringTools return a number of bytes
read instead of the resultant char (was thinking of isHexPair), so you may need to re-read
and parse those hexPair a second time to store the result. The result is generally a subString
of the original DN, because I don't create a subString to store the attributeValue. 

Also keep in mind that we have no clue during the parsing phase about the attribute type :
is it binary or not? This is a not resolved question : binary are allowed as a part of a DN,
but should they be coded in the first form (oid=#<hex>*) or may they be encoded this
way : <attr>=<escaped hexPairs>*. May be the best place to do the ransformation
is in the Normalization service, thus the AttributeValue should be kept as byte[] until then.

I have started to think about DN parsing on confluence :
with a better structure to hold all the needed information (it will be very helpfull for ModifyRDN

Let's start a little discussion about those ponts before coding, it can save us some time.

> Searches with escaped characters in the base DN fail.
> -----------------------------------------------------
>                 Key: DIRSERVER-638
>                 URL:
>             Project: Directory ApacheDS
>          Issue Type: Bug
>    Affects Versions: 1.0-RC3
>         Environment: ApacheDS 1.0 RC 3
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
> Microsoft Windows XP version 5.1 Service Pack 1
>            Reporter: Stefan Zoerner
>         Assigned To: Alex Karasulu
>         Attachments:
> Searches with escaped characters in the base DN fail. I have created a test entry like
> dn: sn=Ferry,dc=example,dc=com
> objectclass: top
> objectclass: person
> sn: Ferry
> cn: Bryan Ferry
> and perform searches with the following parameters
> 1)
> BASE DN: sn=\46\65\72\72\79,dc=example,dc=com
> Filter: (cn=Bryan Ferry)
> Scope: BASE
> 2)
> BASE DN: sn=#4665727279,dc=example,dc=com
> Filter: (cn=Bryan Ferry)
> Scope: BASE
> In both cases the entry is not found, although it should (see examples in Chapter 5 of
RFC 2253). In example 1 the search base is the DN of the example with "Ferry" escaped with
backslashes. The second example is the same search base, but with the value BER encoded (octet
> An attached JUnit test creates the entry and performs both search ops. It passes with
Sun Java System Directory Server 5.2 but fails with ApacheDS.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


View raw message