Age | Commit message (Collapse) | Author |
|
"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
|
|
|
|
wants to send data
|
|
- Enabling and disabling of large file support is now complete.
|
|
- Logic based on CURL_SIZEOF_CURL_OFF_T and SIZEOF_OFF_T already adjusted.
- Test case 557 already passes on all autobuilds.
- System off_t, or equivalent, size is finally not recorded in curlbuild.h
for this release. SIZEOF_OFF_T from config file is used.
|
|
http://curl.haxx.se/mail/archive-2008-08/0075.html
|
|
this really hasn't bitten anyone else. The issuer of the report (Felix) suggested
the closure himself and he will get back when (if?) he manage to get a more
reliable way to see the problem.
154 - bug #2041827 "Segfault in http_output_auth w/ FORBID_REUSE (7.18.2)"
|
|
adjusted.
Old logic based on CURL_SIZEOF_CURL_OFF_T is only partially adjusted.
|
|
Add more tasks to #144.
|
|
|
|
155 - bug #2038004 "Curl OpenSSL not compatible with 7.17 or 7.18"
156 - proxy CONNECT issue (details not public yet due to possible security impact)
|
|
|
|
|
|
|
|
has to be revisited and adjusted as appropriate.
Enabling and disabling of large file support needs further inspection.
|
|
|
|
Rebooting the problematic system, releasing allocated memory and swap,
has allowed buildconf and configure to complete sucessfully since then.
|
|
connection with the multi interface even if a previous use of it caused a
CURLE_PEER_FAILED_VERIFICATION to get returned. I now make sure that failed
SSL connections properly close the connections.
|
|
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.
|
|
Third version of the patch fixing a failure to chose a proper data
type submitted to the mailing list 2008-08-04.
|
|
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.
|
|
Rebooting the Solaris system, releasing allocated memory and swap,
has allowed buildconf and configure to complete sucessfully. Further
tests on the system might allow determination of the problem origin.
Solaris AutoBuilds suceeded on August 2 and 3.
|
|
submitted to the mailing list 2008-07-31. Awaiting Ok to commit.
|
|
|
|
145 - Phil Blundell's CURLOPT_SCOPE patch/work
|
|
147 - PHP's bug report #43158 (http://bugs.php.net/bug.php?id=43158) identifies
a true bug in libcurl built with OpenSSL.
|
|
|
|
|
|
|
|
|
|
|
|
Added #148 and # 149
|
|
146 - Yehoshua Hershberg's re-using of connections that failed with
CURLE_PEER_FAILED_VERIFICATION
147 - PHP's bug report #43158 (http://bugs.php.net/bug.php?id=43158) identifies
a true bug in libcurl built with OpenSSL.
|
|
because at the current point in time I think the benefit of adding that new
return code is very slim and it is a lot of work to introduce new return codes
(for docs and maintenance etc)
I added "145 - Phil Blundell's CURLOPT_SCOPE patch/work" since I want it
sorted/committed.
|
|
|
|
OpenSSL, NSS and GnuTLS-built libcurls.
|
|
OpenSSL, NSS and GnuTLS-built libcurls.
|
|
|
|
Moved 144 to 7.18.3 instead
|
|
144 - Help apps use 64bit/LFS libcurl
|
|
releases
|
|
136 - adding easy handles when using curl_multi_socket* by
Markus Koetter
|
|
|
|
- Christopher Palow
|
|
|
|
|
|
GET simply because previously when you set CURLOPT_NOBODY to TRUE first and
then FALSE you'd end up in a broken state where a HTTP request would do a
HEAD by still act a lot like for a GET and hang waiting for the content etc.
|
|
|
|
removed
133 - Setting CURLOPT_NOBODY to "false" causes cURL to wait for content if a
content-length header is read
added
|
|
done
|