[ http://issues.apache.org/jira/browse/DIRSERVER-638?page=comments#action_12426029 ] 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 : http://docs.safehaus.org/display/APACHEDS/DN+Parsing with a better structure to hold all the needed information (it will be very helpfull for ModifyRDN operation) 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: http://issues.apache.org/jira/browse/DIRSERVER-638 > 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: SearchWithEscapedCharacters.java > > > Searches with escaped characters in the base DN fail. I have created a test > entry like this: > 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 String). > 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: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
