the curl_multi_socket() API with HTTP pipelining enabled and could lead to
the pipeline basically stalling for a very long period of time until it took
off again.
provided excellent repeat recipes. I fixed the cases I managed to reproduce
but Jeff still got some (SCP) problems even after these fixes:
http://curl.haxx.se/mail/lib-2008-05/0342.html
due to KfW's library header files exporting symbols/macros that should be
kept private to the KfW library. See ticket #5601 at http://krbdev.mit.edu/rt/
how the HTTP redirect following code didn't properly follow to a new URL if
the new url was but a query string such as "Location: ?moo=foo". Test case
1031 was added to verify this fix.
_ Updated packages/OS400/curl.inc.in with new definitions.
_ New connect/bind/sendto/recvfrom wrappers to support AF_UNIX sockets.
_ Include files line length shortened below 100 chars.
_ Const parameter in lib/qssl.[ch].
_ Typos in packages/OS400/initscript.sh.
interface problems:
o with pipelining disabled, the state should never be set to WAITDO but
rather go straight to DO
o we had multiple states for which the internal function returned no socket
at all to wait for, with the effect that libcurl calls the socket callback
(when curl_multi_socket() is used) with REMOVE prematurely (as it would be
added again within very shortly)
o when in DO and DOING states, the HTTP and HTTPS protocol handler functions
didn't return that the socket should be waited for writing, but instead it
was treated as if no socket was needing monitoring so again REMOVE was
called prematurely.
go straight to DO
we had multiple states for which the internal function returned no socket at
all to wait for, with the effect that libcurl calls the socket callback (when
curl_multi_socket() is used) with REMOVE prematurely (as it would be added
again within very shortly)
handler functions didn't return that the socket should be waited for writing,
but instead it was treated as if no socket was needing monitoring so REMOVE
was called prematurely
