| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
|
|
|
|
|
|
which caused an error when the second header was dumped due to stdout
being closed. Added test case 1066 to verify. Also fixed a potential
problem where a closed file descriptor might be used for an upload
when more than one URL is given.
|
|
|
|
|
|
formatting functionality when handling signed and unsigned longs, as well as
our curl_off_t data type.
|
|
was discovered to be problematic while investigating an incident reported by
Von back in May. curl in this case doesn't include a Content-Length: or
Transfer-Encoding: chunked header which is illegal. This test case is
added to DISABLED until a solution is found.
|
|
|
|
|
|
when a server responded with long headers and data. Luckily, the buffer
overflowed into another unused buffer, so no actual harm was done.
Added test cases 1060 and 1061 to verify.
|
|
|
|
line of a multiline FTP response whose last byte landed exactly at the end
of the BUFSIZE-length buffer would be treated as the terminal response
line. The following response code read in would then actually be the
end of the previous response line, and all responses from then on would
correspond to the wrong command. Test case 1062 verifies this.
Stop closing a never-opened ftp socket.
|
|
|
|
|
|
proved how PUT and POST with a redirect could lead to a "hang" due to the
data stream not being rewound properly when it had to in order to get sent
properly (again) to the subsequent URL. This is now fixed and these test
cases are no longer disabled.
|
|
with -C - sent garbage in the Content-Range: header. I fixed this problem by
making sure libcurl always sets the size of the _entire_ upload if an app
attemps to do resumed uploads since libcurl simply cannot know the size of
what is currently at the server end. Test 1041 is no longer disabled.
|
|
|
|
relative to end of file.
|
|
incorrectly--the host name is treated as part of the user name and the
port number becomes the password. This can be observed in test 279
(was KNOWN_ISSUE #54).
|
|
|
|
|
|
|
|
during redirects. Test cases 1052 and 1055 show problems (maybe the same
root cause as 1051) and are disabled.
|
|
by Ben Sutcliffe. The test when run manually shows a problem in curl,
but the test harness web server doesn't run the test correctly so it's
disabled for now.
|
