The protocol handler struct got a 'flags' field for special information
and characteristics of the given protocol.
This now enables us to move away central protocol information such as
CLOSEACTION and DUALCHANNEL from single defines in a central place, out
to each protocol's definition. It also made us stop abusing the protocol
field for other info than the protocol, and we could start cleaning up
other protocol-specific things by adding flags bits to set in the
handler struct.
The "protocol" field connectdata struct was removed as well and the code
now refers directly to the conn->handler->protocol field instead. To
make things work properly, the code now always store a conn->given
pointer that points out the original handler struct so that the code can
learn details from the original protocol even if conn->handler is
modified along the way - for example when switching to go over a HTTP
proxy.
It helps to prevent a hangup with some FTP servers in case idle session
timeout has exceeded. But it may be useful also for other protocols
that send any quit message on disconnect. Currently used by FTP, POP3,
IMAP and SMTP.
If the query result has a binary attribute, the binary attribute is
base64 encoded. But all following non binary attributes are also base64
encoded which is wrong.
This is a test (LDAP server is public).
curl
ldap://x500.bund.de:389/o=Bund,c=DE?userCertificate,certificateSerialNumber?sub
?cn=*Woehleke*
If built without HTTP or proxy support it would cause a compiler warning
due to the unused variable. I moved the declaration of it into the only
scope it is used.
bool_false is the internal name used in the setup_once.h definition
we fall back to for non-C99 non-stdbool systems, it's not the actual
name to use in assignments (we use bool_false, bool_true there to
avoid global namespace problems, see comment in setup_once.h).
The correct C99 value to use is 'false', but let's use FALSE as
used elsewhere when assigning to bits.close. FALSE is set equal
to 'false' in setup_once.h when possible.
This fixes a build problem on C99 targets.
As of curl-7.21.1 tunnelling ldap queries through HTTP Proxies is not
supported. Actually if --proxytunnel command-line option (or equivalent
CURLOPT_HTTPPROXYTUNNEL) is used for ldap queries like
ldap://ldap.my.server.com/... You are unable to successfully execute the
query. In facts ldap_*_bind is executed directly against the ldap server
and proxy is totally ignored. This is true for both openLDAP and
Microsoft LDAP API.
Step to reproduce the error:
Just launch "curl --proxytunnel --proxy 192.168.1.1:8080
ldap://ldap.my.server.com/dc=... "
This fix adds an invocation to Curl_proxyCONNECT against the provided
proxy address and on successful "CONNECT" it tunnels ldap query to the
final ldap server through the HTTP proxy. As far as I know Microsoft
LDAP APIs don't permit tunnelling in any way so the patch provided is
for OpenLDAP only. The patch has been developed against OpenLDAP 2.4.23
and has been tested with Microsoft ISA Server 2006 and works properly
with basic, digest and NTLM authentication.
makes the LDAP code much cleaner, nicer and in general being a
better libcurl citizen. If a new enough OpenLDAP version is
detect, the new and shiny lib/openldap.c code is then used
instead of the old cruft
Code by Howard, minor cleanups by Daniel.
