librtmp is often statically linked and using sub dependencies like
OpenSSL, so we need to make sure we can actually link with it properly
before enabling it. Otherwise we easily end up trying to link with a
RTMP lib that fails.
1 - libcurl assumes that there are gcrypt functions available when
GnuTLS is.
2 - GnuTLS can be built to use libnettle instead as crypto library,
which breaks assumption (1)
This change makes configure make sure that if GnuTLS is requested and
detected, it also makes sure that gcrypt is present or it errors
out. This is mostly a way to make the user more aware of this flaw, the
correct fix would be to detect which crypto layer that is in use and
adapt our code to use that instead of blindly assuming gcrypt.
Reported by: Michal Gorny
Bug: http://curl.haxx.se/bug/view.cgi?id=3071038
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.
Rodric provide an awesome recipe that proved libcurl didn't timeout at
the requested time - it instead often timed out at [connect time] +
[timeout time] instead of the documented and intended [timeout time]
only. This bug was due to the code using the wrong base offset when
comparing against "now". I could also take the oppurtinity to simplify
the code by properly using of the generic help function for this:
Curl_timeleft.
Reported by: Rodric Glaser
Bug: http://curl.haxx.se/bug/view.cgi?id=3061535
As this function uses return code 0 to mean that there is no timeout, it
needs to check that it doesn't return a time left value that is exactly
zero. It could lead to libcurl doing an extra 1000 ms select() call and
thus not timing out as accurately as it should.
I fell over this bug when working on the bug 3061535 but this fix does
not correct that problem alone, although this is a problem that needs to
be fixed.
Reported by: Rodric Glaser
Bug: http://curl.haxx.se/bug/view.cgi?id=3061535
1. Remove the comment warning that it's "not been verified to work". It
works with no problems in my testing.
2. Remove 2 unnecessary includes.
3. Remove the myrealloc(). Initialize chunk.memory with malloc() instead
of NULL. The comments for these two parts contradicted each other.
4. Handle out of memory from realloc() instead of continuing.
5. Print a brief status message at the end.
The timeout is set for the connect phase already at the start of the
request so we should not add a new one, and we MUST not set expire to 0
as that will remove any other potentially existing timeouts.
When curl calls a function from that library then it needs to
explicitly link to the library instead of piggybacking on
libcurl's own dependency. Without this, GNU ld with the
--no-add-needed flag fails when linking (which Fedora now does
by default).
Reported by: Quanah Gibson-Mount
Bug: http://curl.haxx.se/mail/lib-2010-09/0085.html
The code reading chunked encoding attempts to rewind the code if it had
read more data than the chunky parser consumes. The rewinding can fail
and it will then cause an error. This change now makes the rewinding
only happen if pipelining is in use - as that's the only time it really
needs to be done.
Bug: http://curl.haxx.se/mail/lib-2010-08/0297.html
Reported by: Ron Parker
Curl_getconnectinfo() is changed to return a proper curl_socket_t for
the last socket so that it'll work more portably (and cause less
compiler warnings).
Add a timeout check for handles in the state machine so that they will
timeout in all states disregarding what actions that may or may not
happen.
Fixed a bug in socket_action introduced recently when looping over timed
out handles: it wouldn't assign the 'data' variable and thus it wouldn't
properly take care of handles.
In the update_timer function, the code now checks if the timeout has
been removed and then it tells the application. Previously it would
always let the remaining timeout(s) just linger to expire later on.
Each easy handle has a list of timeouts, so as soon as the main timeout
for a handle expires, we must make sure to get the next entry from the
list and re-add the handle to the splay tree.
This was attempted previously but was done poorly in my commit
232ad6549a.
When a new transfer is about to start we now set the proper timeouts to
expire for the multi interface if they are set for the handle. This is a
follow-up bugfix to make sure that easy handles timeout properly when
the times expire and the multi interface is used. This also improves
curl_multi_timeout().
