Age | Commit message (Collapse) | Author |
|
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.
|
|
|
|
when using CURL_AUTH_ANY" (http://curl.haxx.se/bug/view.cgi?id=1945240).
The problem was that when libcurl rewound a stream meant for upload when it
would prepare for a second request, it could accidentally continue the
sending of the rewound data on the first request instead of on the second.
Ben also provided test case 1030 that verifies this fix.
|
|
redirections and thus cannot use CURLOPT_FOLLOWLOCATION easily, we now
introduce the new CURLINFO_REDIRECT_URL option that lets applications
extract the URL libcurl would've redirected to if it had been told to. This
then enables the application to continue to that URL as it thinks is
suitable, without having to re-implement the magic of creating the new URL
from the Location: header etc. Test 1029 verifies it.
|
|
|
|
and --help options.
|
|
easy. This was reported not working by Penugonda Chenna Reddy in
http://curl.haxx.se/mail/lib-2008-04/0046.html but I fail to repeat that
problem.
|
|
|
|
by Ben Combee where libcurl would send the wrong cookie to a redirected
server. libcurl was doing the right thing in this test case.
|
|
|
|
|
|
SFTP quote command reported by Vincent Le Normand, but left it disabled.
|
|
reproduce the --ftp-create-dirs problem reported by Brian Ulm, but that
seems to need a call curl_easy_reset() which this test case doesn't do.
|
|
(test 620 tests the just-fixed problem reported by Brian Ulm).
|
|
files, as questioned by Mike Protts. SFTP does for me but SCP doesn't
so test 617 is disabled for now.
|
|
such as the CURLOPT_SSL_CTX_FUNCTION one treat that as if it was a Location:
following. The patch that introduced this feature was done for 7.11.0, but
this code and functionality has been broken since about 7.15.4 (March 2006)
with the introduction of non-blocking OpenSSL "connects".
It was a hack to begin with and since it doesn't work and hasn't worked
correctly for a long time and nobody has even noticed, I consider it a very
suitable subject for plain removal. And so it was done.
|
|
|
|
--vernum
|
|
|
|
provided for bug report #1871269, fixed on Jan 14 2008 before the 7.18.0
release.
|
|
already worked for FTP:// URLs
|
|
(http://curl.haxx.se/bug/view.cgi?id=1850730) I wrote up test case 552. The
test is doing a 70K POST with a read callback and an ioctl callback over a
proxy requiring Digest auth. The test case code is more or less identical to
the test recipe code provided by Spacen Jasset (who submitted the bug report).
|
|
A failed attempt to repeat bug report #1850730 (ie the test works fine).
|
|
|
|
|
|
|
|
protocols listed in curl --version
|
|
failed one using the multi interface
|
|
Disable valgrind in test case 1004 due to a libtool bug.
|
|
Tests 35, 544 545 added: binary data POSTs.
|
|
Added test cases 2002 and 2003 (the latter disabled for now)
|
|
same easy handle
Fixed the filecheck: make target to work outside the source tree
|
|
This happened because the tftp code always uncondionally did a bind()
without caring if one already had been done and then it failed. I wrote a
test case (1009) to verify this, but it is a bit error-prone since it will
have to pick a fixed local port number and since the tests are run on so
many different hosts in different situations I add it in disabled state.
|
|
Added test case 1008 to verify. Note that #47 is still there.
|
|
target called 'filecheck' so that if you run 'make filecheck' in this directory
it'll check if the local files are also mentioned in the Makefile.am so that
they are properly included in release archives!
|
|
function do wrong on all input bytes that are >= 0x80 (decimal 128) due to a
signed / unsigned mistake in the code. I fixed it and added test case 543 to
verify.
|
|
curl_easy_setopt() that alters how libcurl functions when following
redirects. It makes libcurl obey the RFC2616 when a 301 response is received
after a non-GET request is made. Default libcurl behaviour is to change
method to GET in the subsequent request (like it does for response code 302
- because that's what many/most browsers do), but with this CURLOPT_POST301
option enabled it will do what the spec says and do the next request using
the same method again. I.e keep POST after 301.
The curl tool got this option as --post301
Test case 1011 and 1012 were added to verify.
|
|
URLs ending with a slash properly (it should list the contents of that
directory). Test case 351 brought back and also test 1010 was added.
|
|
- Bug report #1792649 (http://curl.haxx.se/bug/view.cgi?id=1792649) pointed
out a problem with doing an empty upload over FTP on a re-used connection.
I added test case 541 to reproduce it and to verify the fix.
- I noticed while writing test 541 that the FTP code wrongly did a CWD on the
second transfer as it didn't store and remember the "" path from the
previous transfer so it would instead CWD to the entry path as stored. This
worked, but did a superfluous command. Thus, test case 541 now also verifies
this fix.
|
|
(to validate bug #1790403).
|
|
case 615 to test an SFTP upload failure.
|
|
out that libcurl didn't deal with large responses from server commands, when
the single response was consisting of multiple lines but of a total size of
16KB or more. Dan Fandrich improved the ftp test script and provided test
case 1006 to repeat the problem, and I fixed the code to make sure this new
test case runs fine.
|
|
multiple lines (similar to test case 1003).
|
|
empty proxy server is selected.
|
|
out that libcurl didn't deal with very long (>16K) FTP server response lines
properly. Starting now, libcurl will chop them off (thus the client app will
not get the full line) but survive and deal with them fine otherwise. Test
case 1003 was added to verify this.
|
|
(http://curl.haxx.se/bug/view.cgi?id=1776235) about ftp requests with NOBODY
on a directory would do a "SIZE (null)" request. This is now fixed and test
case 1000 was added to verify.
|
|
range. They are about FTP but the 100-199 range is full.
|
|
HTTP PUT using Digest authentication. Test case 5320 and 5322 were also
added to verify the functionality.
|
|
after 7.16.2. This is much due to the different treatment file:// gets
internally, but now I added test 231 to make it less likely to happen again
without us noticing!
|
|
verifies the bug fix in #1757328.
|