| Age | Commit message (Collapse) | Author |
|---|
|
header, you got _two_ User-Agent headers in the CONNECT request...! Added
test case 287 to verify the fix.
|
|
|
|
|
|
|
|
|
|
something went wrong like it got a bad response code back from the server,
libcurl would leak memory. Added test case 538 to verify the fix.
I also noted that the connection would get cached in that case, which
doesn't make sense since it cannot be re-use when the authentication has
failed. I fixed that issue too at the same time, and also that the path
would be "remembered" in vain for cases where the connection was about to
get closed.
|
|
|
|
when more than FD_SETSIZE file descriptors are open.
This means that if for any reason we are not able to
open more than FD_SETSIZE file descriptors then test
518 should not be run.
test 537 is all about testing libcurl functionality
when the system has nearly exhausted the number of
free file descriptors. Test 537 will try to run with
very few free file descriptors.
|
|
case when 401 or 407 are returned, *IF* no auth credentials have been given.
The CURLOPT_FAILONERROR option is not possible to make fool-proof for 401
and 407 cases when auth credentials is given, but we've now covered this
somewhat more.
You might get some amounts of headers transferred before this situation is
detected, like for when a "100-continue" is received as a response to a
POST/PUT and a 401 or 407 is received immediately afterwards.
Added test 281 to verify this change.
|
|
case 535 and it now runs fine. Again a problem with the pipelining code not
taking all possible (error) conditions into account.
|
|
|
|
but that worked nicely in 7.15.5. I converted it into test case 532 and
fixed the problem.
|
|
|
|
would crash if a bad function sequence was used when shutting down after
using the multi interface (i.e using easy_cleanup after multi_cleanup) so
precautions have been added to make sure it doesn't any more - test case 529
was added to verify.
|
|
|
|
(http://curl.haxx.se/bug/view.cgi?id=1561470) that is said to crash when an
FTP upload fails with the multi interface. It did not, but I made a failed
upload still assume the control connection to be fine.
|
|
empty password or no password at all. Test case 278 and 279 were added to
verify.
|
|
FTP 3rd party transfers to that file for now until I have them sorted out.
|
|
|
|
cache within the multi handle.
|
|
|
|
|
|
occurred when asking libcurl to follow HTTP redirects and the original URL had
more than one question mark (?). Added test case 276 to verify.
|
|
|
|
same server
|
|
(http://curl.haxx.se/bug/view.cgi?id=1338648) which really is more of a
feature request, but anyway. It pointed out that --max-redirs did not allow
it to be set to 0, which then would return an error code on the first
Location: found. Based on Nis' patch, now libcurl supports CURLOPT_MAXREDIRS
set to 0, or -1 for infinity. Added test case 274 to verify.
|
|
(wrongly) sends *two* WWW-Authenticate headers for Digest. While this should
never happen in a sane world, libcurl previously got into an infinite loop
when this occurred. Dave added test 273 to verify this.
|
|
to the remote one
|
|
|
|
|
|
from the command line tool with --ignore-content-length. This will make it
easier to download files from Apache 1.x (and similar) servers that are
still having problems serving files larger than 2 or 4 GB. When this option
is enabled, curl will simply have to wait for the server to close the
connection to signal end of transfer. I wrote test case 269 that runs a
simple test that this works.
|
|
|
|
|
|
trailer is then sent to the normal header callback/stream.
|
|
fix the CONNECT authentication code with multi-pass auth methods (such as
NTLM) as it didn't previously properly ignore response-bodies - in fact it
stopped reading after all response headers had been received. This could
lead to libcurl sending the next request and reading the body from the first
request as response to the second request. (I also renamed the function,
which wasn't strictly necessary but...)
The best fix would to once and for all make the CONNECT code use the
ordinary request sending/receiving code, treating it as any ordinary request
instead of the special-purpose function we have now. It should make it
better for multi-interface too. And possibly lead to less code...
Added test case 265 for this. It doesn't work as a _really_ good test case
since the test proxy is too stupid, but the test case helps when running the
debugger to verify.
|
|
with CURLOPT_PROXY can use a http:// prefix and user + password. The user
and password fields are now also URL decoded properly.
Test case 264 added to verify.
|
|
address was not possible to use. It is now, but requires it written
RFC2732-style, within brackets - which incidently is how you enter numerical
IPv6 addresses in URLs. Test case 263 added to verify.
|
|
binary zeroes within the headers. They confused libcurl to do wrong so the
downloaded headers become incomplete. The fix is now verified with test case
262.
|
|
|
|
"http://somehost?data" as it added a slash too much in the request ("GET
/?data/"...). Added test case 260 to verify.
|
|
HTTP test server is a bit limited though, as it never responds to the POST
request until all data has been sent (and received)...
|
|
.netrc, and when following a Location: the subsequent requests didn't properly
use the auth as found in the netrc file. Added test case 257 to verify my fix.
|
|
|
|
used the default port. He was right. I fixed the problem and added the test
cases 521, 522 and 523 to verify the fix.
|
|
level stuff. The FTP server communicates with sockfilt using perl's open2().
This enables easier IPv6 support and hopefully FTP-SSL support in the future.
Added four test cases for FTP-ipv6.
|
|
when the response come in many small chunks.
|
|
|
|
|
|
also affecting NTLM and Negotiate.) It turned out that if the server responded
with 100 Continue before the initial 401 response, libcurl didn't take care of
the response properly. Test case 245 and 246 added to verify this.
|
|
But this works just fine on my host. Plain HTTP POST using Digest.
|
