Age | Commit message (Collapse) | Author |
|
libcurl always and unconditionally overwrote a stack-based array with 3 zero
bytes. I edited the fix to make it less likely to occur again (and added
a comment explaining the reason to the buffer size).
|
|
even if no errorbuffer is set.
|
|
libcurl without cookie support. This is mainly useful if you want to build a
minimalistic libcurl with no cookies support at all. Like for embedded
systems or similar.
|
|
response. Previously, libcurl would re-resolve the host name with the new
port number and attempt to connect to that, while it should use the IP from
the control channel. This bug made it hard to EPSV from an FTP server with
multiple IP addresses!
|
|
|
|
at a chunk boundary it was not considered an error and thus went unnoticed.
Added test case 207 to verify.
|
|
|
|
(http://qa.mandrakesoft.com/show_bug.cgi?id=12285), when connecting to an
IPv6 host with FTP, --disable-epsv (or --disable-eprt) effectively disables
the ability to transfer a file. Now, when connected to an FTP server with
IPv6, these FTP commands can't be disabled even if asked to with the
available libcurl options.
|
|
(http://qa.mandrakesoft.com/show_bug.cgi?id=12289), curl would print a newline
to "finish" the progress meter after each redirect and not only after a
completed transfer.
|
|
If EPSV, EPRT or LPRT is tried and doesn't work, it will not be retried on
the same server again even if a following request is made using a persistent
connection.
If a second request is made to a server, requesting a file from the same
directory as the previous request operated on, libcurl will no longer make
that long series of CWD commands just to end up on the same spot. Note that
this is only for *exactly* the same dir. There is still room for improvements
to optimize the CWD-sending when the dirs are only slightly different.
Added test 210, 211 and 212 to verify these changes. Had to improve the
test script too and added a new primitive to the test file format.
|
|
|
|
with Msys/Mingw on Windows.
|
|
systems that can't run it fine.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
'curl -v writes debugging to its network socket if stderr is closed'
|
|
|
|
|
|
|
|
pkg-config on the build host in order to detect OpenSSL compiler options.
|
|
|
|
|
|
file that was already completely downloaded caused an error, while it
doesn't if you don't use --fail! I added test case 194 to verify the fix.
Grrr. CURLOPT_FAILONERROR is now added to the list stuff to remove in
libcurl v8 due to all the kludges needed to support it.
|
|
good. I fixed.
|
|
|
|
both source and destination being the same host. It can be useful if you want
to move a file on a server or similar.
|
|
|
|
|
|
initiate the specific language operations, to make the IDN stuff work better.
|
|
|
|
fine even for third party transfers.
|
|
|
|
|
|
and password fields properly in URLs, like
ftp://us?er:pass?word@site.com/. Added test 191 to verify the fix.
|
|
|
|
|
|
|
|
CURLOPT_FOLLOWLOCATION, libcurl reported error if a redirect happened even if
the new URL would provide the resumed file. Test case 188 added to verify the
fix (together with existing test 99).
|
|
|
|
|
|
|
|
based) IDN conversion fails. This is really due to a missing suitable
function in the libidn API that I hope we can remove once libidn gets a
function like this.
|
|
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=134133) and not to anyone
involved in the curl project! This happens when you try to curl a file from a
proftpd site using SSL. It seems proftpd sends a somewhat unorthodox PASS
response code (232 instead of 230). I relaxed the response code check to deal
with this and similar cases.
|
|
formposts no longer include the path part. If you _really_ want them, you
must provide your preferred full file name with CURLFORM_FILENAME.
Added detection for libgen.h and basename() to configure. My custom
basename() replacement function for systems without it, might be a bit too
naive...
Updated 6 test cases to make them work with the stripped paths.
|