| Age | Commit message (Collapse) | Author |
|---|
|
|
|
test a report that the size didn't work, but these test cases pass.
|
|
researching it, it turned out he got a 550 response back from a SIZE command
and then I fell over the text in RFC3659 that says:
The presence of the 550 error response to a SIZE command MUST NOT be taken
by the client as an indication that the file cannot be transferred in the
current MODE and TYPE.
In other words: the change I did on September 30th 2008 and that has been
included in the last two releases were a regression and a bad idea. We MUST
NOT take a 550 response from SIZE as a hint that the file doesn't exist.
|
|
with and without --location-trusted
|
|
|
|
|
|
used. It has been used since forever but it was never a good idea to use
unless explicitly asked for.
|
|
while still causing a timeout during the data phase.
|
|
|
|
This test was added after the HTTPS-using-multi-interface with OpenSSL
regression of 7.19.1 to hopefully prevent this embarassing mistake from
appearing again... Unfortunately the bug wasn't triggered by this test, which
presumably is because the connect to a local server is too fast/different
compared to the real/distant servers we saw the bug happen with.
|
|
|
|
|
|
test #559 tests internal hash create/add/destroy
|
|
|
|
now to minimally exercise some internal hash routines.
|
|
|
|
|
|
|
|
|
|
|
|
use the startup of the IPv6 test server as a substitute check for this).
|
|
|
|
All but the first test cause an infinite loop or other failure and so
are added to DISABLED.
|
|
fixed a CURLINFO_REDIRECT_URL memory leak and an additional wrong-doing:
Any subsequent transfer with a redirect leaks memory, eventually crashing
the process potentially.
Any subsequent transfer WITHOUT a redirect causes the most recent redirect
that DID occur on some previous transfer to still be reported.
|
|
|
|
CURLINFO_REDIRECT_URL leaking memory and returning incorrect results when
two URLs are requested. Reported by vmpdemo in bug #2152270
|
|
|
|
a fresh connection to be made in such cases and the request retransmitted.
This should fix test case 160. Added test case 1079 in an attempt to
test a similar connection dropping scenario, but as a race condition, it's
hard to test reliably.
|
|
|
|
gets a 550 response back for the cases where a download (or NOBODY) is
wanted. It still allows a 550 as response if the SIZE is used as part of an
upload process (like if resuming an upload is requested and the file isn't
there before the upload). I also modified the FTP test server and a few test
cases accordingly to match this modified behavior.
|
|
|
|
|
|
date parser function. This makes our function less dependent on system-
provided functions and instead we do all the magic ourselves. We also no
longer depend on the TZ environment variable.
|
|
Markus Moeller reported: http://curl.haxx.se/mail/archive-2008-09/0016.html
- recv() errors other than those equal to EAGAIN now cause proper
CURLE_RECV_ERROR to get returned. This made test case 160 fail so I've now
disabled it until we can figure out another way to exercise that logic.
|
|
|
|
|
|
|
|
request.
Detect cases where an upload must be sent chunked and the server supports
only HTTP 1.0 and return CURLE_UPLOAD_FAILED.
|
|
CURLOPT_POST301 (but adds a define for backwards compatibility for you who
don't define CURL_NO_OLDIES). This option allows you to now also change the
libcurl behavior for a HTTP response 302 after a POST to not use GET in the
subsequent request (when CURLOPT_FOLLOWLOCATION is enabled). I edited the
patch somewhat before commit. The curl tool got a matching --post302
option. Test case 1076 was added to verify this.
|
|
new date strings to get tested too.
|
|
to HTTP 1.0 upon receiving a response from the HTTP server. Tests 1072
and 1073 are similar to test 1069 in that they involve the impossible
scenario of sending chunked data to a HTTP 1.0 server. All these currently
fail and are added to DISABLED.
Added test 1075 to test --anyauth with Basic authentication.
|
|
|
|
"Connection: close" and actually close the connection after the
response-body, libcurl could still have outstanding data to send and it
would not properly notice this and stop sending. This caused weirdness and
sad faces. http://curl.haxx.se/bug/view.cgi?id=2080222
Note that there are still reasons to consider libcurl's behavior when
getting a >= 400 response code while sending data, as Craig Perras' note
"http upload: how to stop on error" specifies:
http://curl.haxx.se/mail/archive-2008-08/0138.html
|
|
files bing mirrored) and thus I've changed the URL in the cookiejar header
to no longer use curlm.haxx.se but instead use the main site curl.haxx.se
|
|
the HTTP method to GET (or HEAD) when given a value of 0.
|
|
in a similar manner to test 1065 so is added to DISABLED.
|
|
in a similar manner to test 1065 so is added to DISABLED.
|
|
|
|
|
|
|
