attribute followed by 2nd colon results in "illegal base64 data at input"
nikkicoon opened this issue · comments
given an LDIF dump with an entry containing this attribute:
dircount: some.server.domain.tld 1 76 846
I get:
Error in line 84: illegal base64 data at input byte 15
The python implementation for ldif dumps does not complain about this.
value-spec = ":" ( FILL 0*1(SAFE-STRING) /
":" FILL (BASE64-STRING) /
"<" FILL url)
; See notes 7 and 8, below
SAFE-CHAR = %x01-09 / %x0B-0C / %x0E-7F
; any value <= 127 decimal except NUL, LF,
; and CR
SAFE-INIT-CHAR = %x01-09 / %x0B-0C / %x0E-1F /
%x21-39 / %x3B / %x3D-7F
; any value <= 127 except NUL, LF, CR,
; SPACE, colon (":", ASCII 58 decimal)
; and less-than ("<" , ASCII 60 decimal)
SAFE-STRING = [SAFE-INIT-CHAR *SAFE-CHAR]
This include SPACE (32) if I'm right, so is the error right? The specs say that spaces are allowed.
curious enough this happens in a file with 8 entries. In a file with roughly 6371008 entries this doesn't get processed by what I'm using.
It's possible that this is why hspark0582@96ec9ec was done in a fork
Strange enough I'm unable to reproduce this in a test so far.
I had an error in a function dealing with the empty value bug as a workaround..
we have lines like (attribute names and values changed):
exampleAttr:: (many letters a-zA-Z)=
The double "::" seems to trip up ldif where the python one presumably deals fine with it.