Re: [PATCH] always multi v5
Attached file logs_7_tests.tar.gz has test traces for test cases 64, 69, 90, 153, 160, 1079 and 1095. These http tests have in common that http test server is instructed to close connection with 'swsclose', while test case is doing more than one request. Above seven tests needed kiil -9 to stop them, otherwise they seem to run for ever, and trace files edited to remove trailing lines which repeat. Attached file logs_238.tar.gz has full logs for test case 238 an ftp one. This also needs kill -9 in order to stop it, but trace238 and memdump do not grow endlessly. Attached file logs_1059.tar.gz has full logs for test case 1059. Given that tis is an 'HTTP CONNECT with proxytunnel to unsupported FTP URL' test, fixing server disconnection handling in 7 cases above most probably will also fix this. -- -=[Yang]=- logs_7_tests.tar.gz Description: GNU Zip compressed data logs_238.tar.gz Description: GNU Zip compressed data logs_1059.tar.gz Description: GNU Zip compressed data --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
#include setup.h in libtest
Yang, I think you forgot about patching tests/libtest. Some files under tests\libtest, includes setup.h. (e.g. in chkhostname.c). Shouldn't that be '#include curl_setup.h'? --gv --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
[Patch] packages/DOS/common.dj
gcc on DOS hasn't really supported COFF-debug (-gcoff) on djgpp for a long time. Eli Zaretskii wrote in: http://newsgroups.derkeiler.com/Archive/Comp/comp.os.msdos.djgpp/2012-01/msg00070.html Sounds like the COFF debug info generation has bit-rotted in GCC. Nothing new here, no other platform uses COFF AFAIK. So lets drop it too: --- packages\DOS\common.dj.old 2013-01-07 02:56:35.65625 +0100 +++ packages\DOS\common.dj 2013-01-10 15:53:34.335625000 +0100 @@ -92,7 +92,7 @@ CC = gcc YACC = bison -y -CFLAGS = -g -gcoff -O2 -I. -I$(TOPDIR)/include -I$(TOPDIR)/lib \ +CFLAGS = -g -O2 -I. -I$(TOPDIR)/include -I$(TOPDIR)/lib \ -I$(WATT32_ROOT)/inc -Wall -DHAVE_CONFIG_H ifeq ($(USE_SSL),1) --gv --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: USE_ARES in config-win32.h
Hi Gisle, On Thu, Jan 10, Gisle Vanem wrote: lib/Makefile.m32 has this: ifdef ARES INCLUDES += -I$(LIBCARES_PATH) CFLAGS += -DUSE_ARES Yes that's a problem with makefiles which don't write a curl_config.h file and expect to fully control build behavior even when a config-platform.h provided file defines default settings, and both try to define build time macros.. config-platform.h in this case (config-win32.h) should be defining USE_ARES and verifying that USE_THREADS_WIN32 is not defined when WITH_ARES or ENABLE_ARES is defined. config-win32.h should verify that USE_ARES and USE_THREADS_WIN32 are none defined when WITH_SYNC_DNS or ENABLE_SYNC_DNS is defined. config-win32.h should define USE_THREADS_WIN32 and verify that USE_ARES is not defined when WITH_THREADS_WIN32 or ENABLE_THREADS_WIN32 is defined. (This should also be the default behavior when none of WITH_ARES or ENABLE_ARES, WITH_SYNC_DNS or ENABLE_SYNC_DNS are defined). In this way makefiles could define one of WITH_ARES, WITH_SYNC_DNS or WITH_THREADS_WIN32 (ENABLE_ARES, ENABLE_SYNC_DNS or ENABLE_THREADS_WIN32) and merrily expect intended behavior. Notice that changing this in config-win32.h affects all makefiles which can be used to build a win32/64 target. Your proposed change would equally affect same number of makefiles. Decoupling of non-configure make-time macro names from those used to actually configure the build is something we should be aiming at. And as this case shows it is even mandatory to allow full option usage. I'm personally not going to make this changes happen any time soon, nor I'm ready for another naming-quarrel. So if you or anyone else wants to take on this, please do so. Thanks, -- -=[Yang]=- --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: [Patch] packages/DOS/common.dj
On Thu, Jan 10, 2013 Gisle Vanem wrote: gcc on DOS hasn't really supported COFF-debug (-gcoff) on djgpp for a long time. Eli Zaretskii wrote in: [...] So lets drop it too: Pushed. https://github.com/bagder/curl/commit/b35a176c Thanks, -- -=[Yang]=- --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: [PATCH] always multi v5
Daniel, Some tests I've done... Forced libcurl to build using select() instead of poll() to rule out any problem in that area. No joy, exhibits same behavior. Used http test server sws.c rolled back to commit d759a70d and also back to commit 4d3fb91f. But it exhibits same behavior. And, given that without the 'always multi' patch tests succeed, it has to be something closely related, or a sws.c weakness it uncovers. Thanks, -- -=[Yang]=- --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: [PATCH] always multi v5
On Thu, 10 Jan 2013, Yang Tse wrote: Attached file logs_7_tests.tar.gz has test traces for test cases 64, 69, 90, 153, 160, 1079 and 1095. These http tests have in common that http test server is instructed to close connection with 'swsclose', while test case is doing more than one request. Thanks, this is helpful! Lets focus on the single test 64 first. What's the exact test target/OS/version etc you're using to trigger this? Does it fail on all runs? Also, can you show us the log/http_server.log after a run where the test fails? Clearly when you run this test case it doesn't properly detect that the connection is dead when the second request is made and goes on, while in my end it detects the problem, creates a new connection and everything is fine. Compare to my log/trace64 piece: 22:34:20.834635 == Info: Ignoring the response-body 22:34:20.835136 = Recv data, 26 bytes (0x1a) : This is not the real page. 22:34:20.850927 == Info: Connection #0 to host 127.0.0.1 left intact 22:34:20.853020 == Info: Issue another request to this URL: 'http://127.0.0.1:8990/64' 22:34:20.855881 == Info: Found bundle for host 127.0.0.1: 0x780bf58 22:34:20.856924 == Info: Connection 0 seems to be dead! 22:34:20.859015 == Info: Closing connection 0 22:34:20.863244 == Info: The cache now contains 0 members 22:34:20.869979 == Info: About to connect() to 127.0.0.1 port 8990 (#1) 22:34:20.870115 == Info: Trying 127.0.0.1... 22:34:20.870228 == Info: connected 22:34:20.870345 == Info: Connected to 127.0.0.1 (127.0.0.1) port 8990 (#1) 22:34:20.870461 == Info: 0x76955f8 is at send pipe head! 22:34:20.871375 == Info: STATE: CONNECT = DO handle 0x77eb418; line 1025 (connection #1) 22:34:20.892268 == Info: Server auth using Digest with user 'testuser' 22:34:20.893184 = Send header, 222 bytes (0xde) : GET /64 HTTP/1.1 0012: Authorization: Digest username=testuser, realm=testrealm, no 0052: nce=1053604145, uri=/64, response=c55f7f30d83d774a3d2dcacf7 0092: 25abaca 009c: User-Agent: curl/7.28.2-DEV 00b9: Host: 127.0.0.1:8990 00cf: Accept: */* ... and the log/http_server.log shows this a few milliseconds before: 22:34:20.793753 Sent off 200 bytes 22:34:20.793770 Sent off 45 bytes 22:34:20.793784 Response sent (245 bytes) and written to log/server.response 22:34:20.793794 instructed to close connection after server-reply 22:34:20.793803 Client disconnect 0 Right now I'm leaning towards a problematic test case/test server since this is code that really isn't affected by my changes - I've just changed some timing and code flows, not the actual real socket/TCP handling. -- / daniel.haxx.se --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Re: [PATCH] always multi v5
On Thu, Jan 10, Daniel Stenberg wrote: Lets focus on the single test 64 first. What's the exact test target/OS/version etc you're using to trigger this? Does it fail on all runs? cygwin 1.5.25 on w2k. Yes it fails in all runs. Also, can you show us the log/http_server.log after a run where the test fails? I've just run it again to get a fresh and full set of logs. Attached logs_64.tar.gz with them. I've let the test run for about 1 minute and then killed the curl tool process from another shell. Server seems to disconnect when instructed to do so. I'll study your trace, compare with mine and later on start to debug this. Just wanted now to handle you all logs for test 64. -- -=[Yang]=- logs_64.tar.gz Description: GNU Zip compressed data --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Find wrong certificate domain
Hello, I'm using libcurl to send SMTP emails. I also set CURLOPT_SSL_VERIFYPEER and CURLOPT_SSL_VERIFYHOST to check the certificate. Some customers are getting an error because the SSL certificate does not match the domain name of the smtp server. I now like to show them the domain name of the certificate. How do I get the name of the certificate domain after such an error? I don't want to use debugging and parse the whole debug output for that. Is there an easy way to get the certificate or the certificate domain name after such failure? Best, Volker --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
Prevent curl to trigger progressbar on 302 redirections
Hi all I'm curious about this. The thing is that I'm using a redirector on my server (using Mirrorbrain) and when curl download a file from there it trigger the progressbar twice, downloading just bytes (I assume that it is the redirection) in the first one, and the proper file in the second one. My headers are big, because Mirrorbrain puts a lot of stuff there: [faidoc@Delorean ~]$ curl -sD- -o/dev/null http://mirrors.cinnarch.com/cinnarch-core/x86_64/cinnarch-keyring-20120717-3-any.pkg.tar.xz HTTP/1.1 302 Found Date: Fri, 11 Jan 2013 00:14:12 GMT Server: Apache/2.2.16 (Debian) X-MirrorBrain-Mirror: softlibre.unizar.es X-MirrorBrain-Realm: country Link: http://mirrors.cinnarch.com/cinnarch-core/x86_64/cinnarch-keyring-20120717-3-any.pkg.tar.xz.meta4; rel=describedby; type=application/metalink4+xml Link: http://softlibre.unizar.es/cinnarch/cinnarch-core/x86_64/cinnarch-keyring-20120717-3-any.pkg.tar.xz; rel=duplicate; pri=1; geo=es Link: http://www.mirrorservice.org/sites/repo.cinnarch.com/cinnarch-core/x86_64/cinnarch-keyring-20120717-3-any.pkg.tar.xz; rel=duplicate; pri=2; geo=gb Link: http://cinnarch.limun.org/cinnarch-core/x86_64/cinnarch-keyring-20120717-3-any.pkg.tar.xz; rel=duplicate; pri=3; geo=de Digest: MD5=rmURnbMAoRYoNhtja1VQgA== Digest: SHA=Hu0X2ym8sBEUQGaXjvFQHdIctgw= Digest: SHA-256=nfFkPNZd8vq05MUCxOVqlwE3YMrAJzT9R0xga6P0DNY= Location: http://softlibre.unizar.es/cinnarch/cinnarch-core/x86_64/cinnarch-keyring-20120717-3-any.pkg.tar.xz Vary: Accept-Encoding Content-Length: 369 Content-Type: text/html; charset=iso-8859-1 But this is not happening with others 302 redirections, which just trigger once the progressbar: [faidoc@Delorean ~]$ curl -sD- -o/dev/null https://www.archlinux.org/packages/extra/i686/aalib/download/ HTTP/1.1 302 FOUND Date: Fri, 11 Jan 2013 00:14:50 GMT Server: Apache X-Frame-Options: DENY Content-Length: 0 Location: http://mirror.us.leaseweb.net/archlinux/extra/os/i686/aalib-1.4rc5-9-i686.pkg.tar.xz Vary: User-Agent,Accept-Encoding Content-Type: text/html; charset=utf-8 Could you explain me this? Thanks --- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
