Re: Is it normal to the progress callback be called once again after returning non-zero value?
On 6/13/2014 5:45 PM, Daniel Stenberg wrote: On Wed, 11 Jun 2014, Ray Satiro wrote: - if(Curl_pgrsDone(conn) !result) + if((status != CURLE_ABORTED_BY_CALLBACK) Curl_pgrsDone(conn) !result) result = CURLE_ABORTED_BY_CALLBACK; Oops. I wanted that to instead be: - if(Curl_pgrsDone(conn) !result) + if(!result Curl_pgrsDone(conn)) As when we've already detected and error, whichever it may be, I don't think we should call the progress callback again. Basically that could lead to the similar problem: return an error from another callback and yet you get the progress callback called again. Ok that works on the samples. Generally speaking though if a status != CURLE_OK is passed to a done handler is it possible for that done handler to return a result of CURLE_OK? I'm trying to figure out if there will still be a scenario where Curl_pgrsDone() could be called with a bad status and whether or not it's permissible in that case. --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
[Survey] What people want us to do next
Hi I've been going through the answers people filled in to the last question in the survey: What bug/feature would you like us to work on next? We got a lot of thankyous in there and also some ramblings that really didn't contain any suggestions. I've taken the liberty of filtering out some of those responses. Otherwise the suggestions are unfiltered. I'm happy for all comments, feedback or additions you have to any of them. == This is what people ask for == World domination! SPDY More of the same - I think things are ticking along nicely. libcurl doesn't work at all with Windows SSPI when Negotiate proxy auth is enabled and a Microsoft Forefront Threat Management Server 2010 proxy is used - bug #1363 Better polling api. Easier method attachment colored output Full speed file transfers across all protocols, and continued development of mail handling protocols. Session multiplexing made easy. Applications over ssh as a transport. This survey should have a no basis for judgement option for the How good is the project and its members to handle... section. HTTPS: Live CRL checking and OCSP. HTTPS: Some type of certificate pinning and/or a generic way to evaluate the certificate chain (independent of SSL backend) would be neat. Easier build instructions for curl w/NSS on Windows. That seems rather harder than it should be. SRV records in HTTP2 implementation. Implement Mark Andrews' draft. It will push things forward. Ability to use wildcard and download multiple files without any need for additional programming. ZeroMQ support up-to-date windows binaries by knauf wget/httrack -like (and js/css/font/etc -aware) addon in the bundle for recursive fetching Support for the WinRT-Platform like it is proposed by https://github.com/martell/libcurl-winrt easily support [] chars in urls without them being interpreter as a range. from the CLI. I think we could have a little more examples. The ones in the website are very basic. The new stuff seems to not be there sometimes... I hope to be able to contribute more with libcurl in a near future. libcurl tcl api crashes in a mysterious manner when -bodyvar and -file options are both used, even at different times with the same handle. There are a couple other options which are surprisingly mutually exclusive, and not documented as such. My only preference would be if you could offer a generic makefile that would come close to working on common systems. I am using mingw-w64 on 64-bit windows. I don't use automake because it introduces a bunch of new dependencies, but it appears that automake is the only build mechanism supported for my environment. I managed to find a pre-compiled mingw-w64 version of libcurl elsewhere, and if I had not, I probably would not have used libcurl. (Although my application was developed on windows, it runs also on linux, and its libcurl file access has been use to a limited extent on linux. The standard libcurl package for that linux distribution worked out of the box with my application.) Review defaults for non functional reasons. e.g. Connection handling: timeouts tend to be far too long, allowing software developers that don't consider such things to freely sink servers. Fall fast, and make people override where there's just reason... Cifs support Curious about latest http/1.1 update in relation to libcurl. Fix the problem where header files became platform/architecture dependent (a few years ago), making cross-builds cumbersome even in such a simple scenario as building 32-bit libcurl on a 64-bit Linux system. It would seem to be a better solution to detect bitness and other platform dependent stuff dynamically inside the headers at compile-time. [Sorry if this was sorted out since.] control of curl internal buffer sizes, including option to release the buffer when not needed (such as when waiting for server response). buffer pool would be a good approach (as done with openssl MODE_RELEASE_BUFFER). I'd really like to be able to use curl as a raw tcp socket too (with optional ssl) Continue your excellent support of http and https in the areas of ipv6 and SPDY I used easy interface for a long time, but once tried multy for the one of my C++ projects and had a lot of problems with it. There are was a race condition in host resolving and main thread on Windows, so all FTP connections failed. Latest release seems to fix it, but another bug has appeared - url_open example, on which based my FTP streaming solution, stop working with latest libcurl on Windows. There are infinite loop in socket reading. So I stop using multy interface at all and switch to easy interface with my own threading implementation. I was very surprised as there are so buggy multy interface implementation on Windows. The same code works great on Unix. So I discovered libcurl is not so good for crossplatform development Rsync copy, delta is not
Re: the survey summary
On Fri, 13 Jun 2014, Daniel Stenberg wrote: http://curl.haxx.se/docs/survey/survey2014.html One of the most surprising results (to me) is that docs was voted the most worst area in the project with a big margin. (Admittedly twice as many also voted it as one of the best areas). I'd like to understand this better. What exactly is considered bad and what can we do about it? I think I'm having my nose a little too deep in all the details to see this clearly. I was under the impression our documentation was pretty good... What's the biggest problem with the current docs? What's the biggest thing we lack? Please share some ideas and thoughts here! -- / daniel.haxx.se --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Is it normal to the progress callback be called once again after returning non-zero value?
On Sat, 14 Jun 2014, Ray Satiro wrote: think we should call the progress callback again. Basically that could lead to the similar problem: return an error from another callback and yet you get the progress callback called again. Ok that works on the samples. Generally speaking though if a status != CURLE_OK is passed to a done handler is it possible for that done handler to return a result of CURLE_OK? Yes, that's up to the done handler. I'm trying to figure out if there will still be a scenario where Curl_pgrsDone() could be called with a bad status and whether or not it's permissible in that case. It is for example possible in the FTP case where the problem isn't considered to be bad enough to tear down the control channel. That would not include CURLE_ABORTED_BY_CALLBACK though. -- / daniel.haxx.se --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: [Survey] What people want us to do next
Daniel, thanks for gathering the feedback! On 14.06.2014 23:16, Daniel Stenberg wrote: up-to-date windows binaries by knauf If I would know which type of Windows builds are the most frequently requested ones, I could setup my Windows testing buildbots [1] to produce curl and libcurl binaries and make them available for download. My biggest issue is that the key feature I need is only available with the OpenSSL backend. For my application (and frankly most others, they just don't actually care enough), it's essential to be able to control validation of the server's key while setting up a TLS connection. Without that feature, use of TLS is completely unsafe for applications, and right now that's OpenSSL only. So the portability to other back-ends is both not useful, and has actually caused bugs in the OpenSSL back-end because of the complexity of supporting the others. I understand the concerns regarding the mismatch of the supported SSL/TLS features by each individual crypto backend, but I actually think that supporting different crypto backends is one of curls most valuable assets. Of course, the vtls abstraction and especially the niche backends definitely require some hard work and love. [1] http://curlbuild.uxnr.de/waterfall --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: weak randomness with some TLS backends
On 04.06.2014 14:55, Pierre Joye wrote: I think it is time to drop windows 2000. Maybe even xp at some point. But this function is available for xp, so it is not a issue at this point. I also suggest dropping support for Windows 2000 and Windows XP before Service Pack 3 if we want to have reliable native support of the Windows platform. An alternative to loading Advapi32.dll dymically using LoadLibrary could be to statically link with Advapi32.lib which takes care of it. This could also be an approach for other areas in libcurl which do currently use LoadLibrary, for example: lib/curl_sspi.c: s_hSecDll = LoadLibrary(TEXT(security.dll)); lib/curl_sspi.c: s_hSecDll = LoadLibrary(TEXT(secur32.dll)); lib/telnet.c: wsock2 = LoadLibrary(TEXT(WS2_32.DLL)); Besides the CryptoAPI CryptGenRandom function [1], we could of course also the WinCNG [2] BCryptGenRandom function [3], though that is only available since Windows Vista. [1] http://msdn.microsoft.com/en-us/library/windows/desktop/aa379942.aspx [2] http://msdn.microsoft.com/en-us/library/windows/desktop/aa376210.aspx [3] http://msdn.microsoft.com/en-us/library/windows/desktop/aa375458.aspx --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: [Survey] What people want us to do next
rip out all openSSL replace with libreSSL On Sat, Jun 14, 2014 at 5:44 PM, Marc Hoersken i...@marc-hoersken.de wrote: Daniel, thanks for gathering the feedback! On 14.06.2014 23:16, Daniel Stenberg wrote: up-to-date windows binaries by knauf If I would know which type of Windows builds are the most frequently requested ones, I could setup my Windows testing buildbots [1] to produce curl and libcurl binaries and make them available for download. My biggest issue is that the key feature I need is only available with the OpenSSL backend. For my application (and frankly most others, they just don't actually care enough), it's essential to be able to control validation of the server's key while setting up a TLS connection. Without that feature, use of TLS is completely unsafe for applications, and right now that's OpenSSL only. So the portability to other back-ends is both not useful, and has actually caused bugs in the OpenSSL back-end because of the complexity of supporting the others. I understand the concerns regarding the mismatch of the supported SSL/TLS features by each individual crypto backend, but I actually think that supporting different crypto backends is one of curls most valuable assets. Of course, the vtls abstraction and especially the niche backends definitely require some hard work and love. [1] http://curlbuild.uxnr.de/waterfall --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: [Survey] What people want us to do next
On Sat, 14 Jun 2014, Corey Feldman-Haim wrote: rip out all openSSL replace with libreSSL They're supposedly API compatible so what exactly are you suggesting we do? AFAIK, libressl is only for OpenBSD still too, or am I wrong? -- / daniel.haxx.se --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: weak randomness with some TLS backends
On 14.06.2014 23:56, Marc Hoersken wrote: An alternative to loading Advapi32.dll dymically using LoadLibrary could be to statically link with Advapi32.lib which takes care of it. This could also be an approach for other areas in libcurl which do currently use LoadLibrary, for example: lib/curl_sspi.c: s_hSecDll = LoadLibrary(TEXT(security.dll)); lib/curl_sspi.c: s_hSecDll = LoadLibrary(TEXT(secur32.dll)); lib/telnet.c: wsock2 = LoadLibrary(TEXT(WS2_32.DLL)); Besides the CryptoAPI CryptGenRandom function [1], ... Fun fact: we already depend on the CryptoAPI for _WIN32 *if* no other crypto backend is available to provide md5 since the introduction of my patch on the 11th September 2012 [1]. [1] https://github.com/bagder/curl/commit/4d384a87142dccb13b8198147b5db15a4aaa9906 --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: Test 584 failures on FreeBSD after 5b2342d3772
On Thu, 5 Jun 2014, Fabian Keil wrote: I assume that's because the info() call has the side effect of slightly delaying Curl_addHandleToPipeline(), but I haven't confirmed that. The attached patch uses wait_ms(1) instead of info() and works around the problem as well, so I consider this theory confirmed. Oh yes indeed. Annoying. I still wonder if this is truly a problem on that platform in real-life or only a test problem... that is not terribly easy to tell. Regarding the patch, we do have a portable Curl_wait_ms() function that could be used. -- / daniel.haxx.se --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
