Daniel Stenberg wrote:

>> My simple version encodes the attribute value in base64 only when
>> there's a binary zero inside. But RFC 2849 says you must encode as
>> base64 as soon as there is any unsafe character, both for the value
>> and the dn/rdn.
>
> What is a "unsafe character" in this sense? Can't we just write a
> function that scans for them and encode the data accordingly if any
> such is found?

Yes we can. I didn't, and I don't feel that motivated for it, as it's
mostly the binary zero that are really annoying (but maybe it would be
significantly better to encode CR/LF too)

>> Another point is that LDAP Browser/Editor finds a ";binary" option
>> for the entries I'm working with, but I don't where he extracts that
>> info from. I thought about systematically adding it when the entries
>> have a binary content, but I finally commented it out, and only use
>> the double colon to indicate base64 encoding. It would be better to
>> find the way to extract all the option values, and include them in
>> the output.
>
> I know nothing about things like this.

That's OK, we can forget about it for now.

>> Also I would like to add an option not to output as ldif, but to get
>> directly the raw value of an attribute (it would be left to the user
>> to properly set the URL so that it matches only one attribute).
>> base64 encoding of unsafe values wouldn't be required for that case.
>> Together with that there would an optional parameter to get only the
>> n-th value of a multi-valued attribute (and either an empty or error
>> result if it doesn't exist).
>
> ... and I don't understand this either! ;-)

A little more explanation then.

Right now instead of sending back the raw content of the LDAP entry,
libcurl formats the return value in ldif format (maybe not 100% compatible).
When you want to get only one data element from ldap (which is one of
the cases where libcurl is more convenient that a ldap browser or
programmatically interfacing to ldap), it can be convenient to get that
raw value directly, so you don't need to parse it out of the ldif result.
Even if the ldif is the standard way of representing an ldif entry, and
you will be missing important info if you have only the raw content.

But in some case, raw value doesn't mean just one block of data, but
several ; and then, it would be convenient to have an additional index
parameter to select which block in the list.

>> But I wonder what would be the recommended way of adding such options ?
>
> Are you talking about options added to curl_easy_setopt() ?

Yes.

>> Would it be to add new elements to the connectdata structure ? That's
>> the only one element available from Curl_ldap.
>
> connectdata holds connection-oriented data, and the SessionHandle
> struct keeps data associated with the easy handle (like options set
> with curl_easy_setopt). You can reach the SessionHandle by reading the
> 'data' field in the connectdata struct.

OK. Then I'd feel like adding an option like for example :
CURLOPT_LDAPRAW
as an integer with the following values :
0 /* default : do not send raw value, send an ldif formatted result */
1 /* send the raw content of the entry, this will be only the first
value in case of a multi-valued attribute */
>1 /* send the n-th value of a multi-valued attribute, send an empty
result if the n-th value doesn't exist */
Received on 2005-05-31