Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.0.0-M11
    • Fix Version/s: 1.0.0-M21
    • Labels:
      None

      Description

      A simple LDIF file containing 3 entries is rejected by LDIFParser:

      dn: uid=uniqueId, dc=domain

      dn: uid=uniqueId2, dc=domain

      dn: uid=uniqueId3, dc=domain

      I don't see any issue in this LDIF. Parser should return 3 entries with no attribute.
      With M11, the error is the following:
      ERROR - ERR_12058_UNKNOWN_ENTRY_TYPE Unknown entry type
      ERROR - ERR_12058_UNKNOWN_ENTRY_TYPE Unknown entry type
      ERROR - ERR_12069 Cannot parse the ldif buffer : ERR_12059_UNKNOWN_ENTRY Unknown entry
      ERROR - ERR_12069 Cannot parse the ldif buffer : ERR_12059_UNKNOWN_ENTRY Unknown entry

      If I add an attribute to each entry, I get no more error.

        Activity

        Hide
        elecharny Emmanuel Lecharny added a comment -

        Closing the resolved issues.

        Show
        elecharny Emmanuel Lecharny added a comment - Closing the resolved issues.
        Hide
        elecharny Emmanuel Lecharny added a comment -

        Both "dn:" and "dn: " are accepted with the current trunk.

        Show
        elecharny Emmanuel Lecharny added a comment - Both "dn:" and "dn: " are accepted with the current trunk.
        Hide
        rouazana Raphaël Ouazana added a comment -

        Thank you for the fix.
        About "empty DN", I misread the code. The DN line "dn:" is forbidden, but "dn: " is correctly handled. So it seems ok.

        Show
        rouazana Raphaël Ouazana added a comment - Thank you for the fix. About "empty DN", I misread the code. The DN line "dn:" is forbidden, but "dn: " is correctly handled. So it seems ok.
        Hide
        elecharny Emmanuel Lecharny added a comment -

        Fixed with http://svn.apache.org/r1570807

        We now accept entries like :

        version: 1
        dn: cn=test1

        dn: cn=test2

        dn: cn=test3

        Show
        elecharny Emmanuel Lecharny added a comment - Fixed with http://svn.apache.org/r1570807 We now accept entries like : version: 1 dn: cn=test1 dn: cn=test2 dn: cn=test3
        Hide
        elecharny Emmanuel Lecharny added a comment -

        Any patch welcomed ! And as we are going to release something next week, that would be a good timing.

        Not sure I grok "disallow empty DN". Do you mean that a LDIF containing :
        DN:
        is not valid ?

        if so, that would be a clear bug, and it requires a new JIRA, yes.

        Thanks !

        Show
        elecharny Emmanuel Lecharny added a comment - Any patch welcomed ! And as we are going to release something next week, that would be a good timing. Not sure I grok "disallow empty DN". Do you mean that a LDIF containing : DN: is not valid ? if so, that would be a clear bug, and it requires a new JIRA, yes. Thanks !
        Hide
        rouazana Raphaël Ouazana added a comment -

        Thank you Emmanuel. Do you need a patch?
        Furthermore reading the code it seems you disallow empty DN (I should open an other ticket, but we are always speaking about emptiness ^^). I don't see why empty DN should be disallowed.

        Show
        rouazana Raphaël Ouazana added a comment - Thank you Emmanuel. Do you need a patch? Furthermore reading the code it seems you disallow empty DN (I should open an other ticket, but we are always speaking about emptiness ^^). I don't see why empty DN should be disallowed.
        Hide
        elecharny Emmanuel Lecharny added a comment -

        Raphaël,

        first, I see your point. I was thinking that you wanted to generate LDIF files that are going to be processed by a server.

        Yes, you can get a list of DN with nothing else, and yes, we should accept such LDIFs. This is easy to fix.

        FTR, thee are very few LDAP servers that accept a LDIF file with a version, this is the reason we relaxed the parser to accept it.

        I changed the type of this JIRA from bug to improvement (also note I didn't close the issue yesturday, which means I thought it required more discussion, somtehing that happened !)

        Thanks !

        Show
        elecharny Emmanuel Lecharny added a comment - Raphaël, first, I see your point. I was thinking that you wanted to generate LDIF files that are going to be processed by a server. Yes, you can get a list of DN with nothing else, and yes, we should accept such LDIFs. This is easy to fix. FTR, thee are very few LDAP servers that accept a LDIF file with a version, this is the reason we relaxed the parser to accept it. I changed the type of this JIRA from bug to improvement (also note I didn't close the issue yesturday, which means I thought it required more discussion, somtehing that happened !) Thanks !
        Hide
        rouazana Raphaël Ouazana added a comment -

        Hi,

        I understand your point, put these LDIF with only DN are often returned by LDAP servers. For example if you search for "1.1" or if you ask only an unknown attribute. So I think they should be parsed. My goal is not to load them in a directory, only to be able to parse them easily.

        Anyway, as far as I understand it, your parser is not fully compliant with the BNF, as it allows LDIF without version and empty LDIF. I think it is a good thing to accept widely used LDIF.

        Regards,
        Raphaël.

        Show
        rouazana Raphaël Ouazana added a comment - Hi, I understand your point, put these LDIF with only DN are often returned by LDAP servers. For example if you search for "1.1" or if you ask only an unknown attribute. So I think they should be parsed. My goal is not to load them in a directory, only to be able to parse them easily. Anyway, as far as I understand it, your parser is not fully compliant with the BNF, as it allows LDIF without version and empty LDIF. I think it is a good thing to accept widely used LDIF. Regards, Raphaël.
        Hide
        elecharny Emmanuel Lecharny added a comment -

        It's not a bug in the LDIF parser : your LDIF file is not correct, accordingly to the RFC.

        ldif-file = ldif-content / ldif-changes
        ldif-content = version-spec 1*(1*SEP ldif-attrval-record)
        ldif-changes = version-spec 1*(1*SEP ldif-change-record)
        ldif-attrval-record = dn-spec SEP 1*attrval-spec
        ldif-change-record = dn-spec SEP *control changerecord
        attrval-spec = AttributeDescription value-spec SEP
        changerecord = "changetype:" FILL
        (change-add / change-delete /
        change-modify / change-moddn)

        So either it's a change-record, or a attrval-record, but you need to add a attrval-spec or a "changetype" at the begin of the line after the DN.

        Check your LDIF.

        Note that it makes sense to have at least the ObjectClass Attribute : how possibly your LDAP server can validate a DN which RDN is not part of the entry ? This is not a legal entry.

        Show
        elecharny Emmanuel Lecharny added a comment - It's not a bug in the LDIF parser : your LDIF file is not correct, accordingly to the RFC. ldif-file = ldif-content / ldif-changes ldif-content = version-spec 1*(1*SEP ldif-attrval-record) ldif-changes = version-spec 1*(1*SEP ldif-change-record) ldif-attrval-record = dn-spec SEP 1*attrval-spec ldif-change-record = dn-spec SEP *control changerecord attrval-spec = AttributeDescription value-spec SEP changerecord = "changetype:" FILL (change-add / change-delete / change-modify / change-moddn) So either it's a change-record, or a attrval-record, but you need to add a attrval-spec or a "changetype" at the begin of the line after the DN. Check your LDIF. Note that it makes sense to have at least the ObjectClass Attribute : how possibly your LDAP server can validate a DN which RDN is not part of the entry ? This is not a legal entry.

          People

          • Assignee:
            elecharny Emmanuel Lecharny
            Reporter:
            rouazana Raphaël Ouazana
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development