RE: Windows autobuilds broken since df69440d05f1133a9053e19a9bf576c8b13514b9

2013-09-17 Thread Steve Holme
On Mon, 16 Sep 2013, Guenter wrote:

 somehow the commit df69440d05f1133a9053e19a9bf576c8b13514b9
 broke the Windows autobuilds; ATM I'm a bit clueless why the
 compiler breaks only for Windows builds while other platforms work fine
...
 please take a look at it - some other eyes or minds may have an idea -
hopefully ...

I managed to get my own local Windows builds working with the fixes I posted
in commit c243d45aadb502301e but the remaining error has me flummoxed
somewhat.

I did wonder if this was a problem was with the interface parameter in
Curl_set_dns_interface(), which then clashes with something declared in a
MinGW header file, as I can't really see anything else wrong - but without
access to a MinGW environment I didn't want to randomly committing possible
fixes.

Anyone else have any thoughts?

Kind Regards

Steve


---
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html


Re: any libcurl API to delete expired cookies?

2013-09-17 Thread YAMADA Yasuharu
Hi Daniel,

2013/9/13 Daniel Stenberg dan...@haxx.se

 On Fri, 28 Jun 2013, YAMADA Yasuharu wrote:

  I think the feature of removing expired cookies should be separate from
 the one that limits the total amount of cookies. I'm convinced there are
 people who might want that expiring feature without the max limit set.


 I quarry expired cookies patch from my [new feature] Maximum limitation
 of cookies patch. Please check.


 Hello again Yamada,

 I found this old patch by accident lingering around and I thought I'd take
 a look and see if we can merge this. I can't apply it since both git and
 patch says the patch file is illegally formatted.

 Could you please give it a quick check and if possible submit a fixed
 version that I can try out?


I create patch again which branch is branched from curl git master today.
Please check it.
https://github.com/aYasuharuYamada/curl/commit/b30ce0b990e52ea4b447cfbfbb21e77b5c399200
In this, test number 9001 is just dummy.

And I do curl tests related cookie and all tests are ok.
$ ./runtests.pl 6 7 8 27 31 46 53 61 62 73 171 172 179 506 598 1024 1025
1104 1105 1216 1218 1228 1331 1401 1408 9001
* System characteristics 
* curl 7.33.0-DEV (i686-pc-cygwin)
* libcurl/7.33.0-DEV OpenSSL/1.0.1e zlib/1.2.8 libidn/1.26
* Features: IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP
* Host: nordica
* System: CYGWIN_NT-6.1-WOW64 nordica 1.7.22(0.268/5/3) 2013-07-22 17:06
i686 Cygwin
* Server SSL:OFF  libcurl SSL:  ON
* debug build:   OFF  track memory: OFF
* valgrind:  OFF  HTTP IPv6 ON
* FTP IPv6   ON   Libtool lib:  OFF
* Shared build:  yes
* SSL library:   OpenSSL
* Ports:
*   HTTP/8990 FTP/8992 FTP2/8995 RTSP/9007
*   TFTP/8997 HTTP-IPv6/8994 RTSP-IPv6/9008 FTP-IPv6/8996
*   GOPHER/9009 GOPHER-IPv6/9009
*   SSH/8999 SOCKS/9000 POP3/9001 IMAP/9003 SMTP/9005
*   POP3-IPv6/9002 IMAP-IPv6/9004 SMTP-IPv6/9006
*   HTTPTLS/9011 HTTPTLS-IPv6/9012
*   HTTP-PIPE/9014
*
test 006...[HTTP with simple cookie send]
-d-p--e--- OK (1   out of 25 , remaining: 00:52)
test 007...[HTTP with cookie parser and header recording]
-d-p-oe--- OK (2   out of 25 , remaining: 00:26)
test 008...[HTTP with cookie parsing from header file]
-d-p--e--- OK (3   out of 25 , remaining: 00:17)
test 027...[Get same cookie page several times]
-d-p--e--- OK (4   out of 25 , remaining: 00:14)
test 031...[HTTP with weirdly formatted cookies and cookiejar storage]
-d-p-oe--- OK (5   out of 25 , remaining: 00:11)
test 046...[HTTP, get cookies and store in cookie jar]
-d-p-oe--- OK (6   out of 25 , remaining: 00:09)
test 053...[HTTP, junk session cookies]
-d-p--e--- OK (7   out of 25 , remaining: 00:07)
test 061...[HTTP with various cookies and custom Host:]
-d-p-oe--- OK (8   out of 25 , remaining: 00:06)
test 062...[HTTP, send cookies when using custom Host:]
-d-p--e--- OK (9   out of 25 , remaining: 00:05)
test 073...[HTTP, receive cookies when using custom Host:, domain using
only two dots]
-d-p-oe--- OK (10  out of 25 , remaining: 00:04)
test 171...[HTTP, get cookie with dot prefixed full domain]
-d-p-oe--- OK (11  out of 25 , remaining: 00:04)
test 172...[HTTP with cookies file and custom added cookie]
-d-p--e--- OK (12  out of 25 , remaining: 00:03)
test 179...[HTTP using proxy and cookies with path checks]
-d-p--e--- OK (13  out of 25 , remaining: 00:03)
test 506...[HTTP with shared cookie list (and dns cache)]
soe--- OK (14  out of 25 , remaining: 00:02)
test 598...[curl_easy_reset with referer and other strings set]
-d-p--e--- OK (15  out of 25 , remaining: 00:02)
test 1024...[HTTP Location: following with cookies]
-d-p--e--- OK (16  out of 25 , remaining: 00:02)
test 1025...[HTTP Location: following with command-line and server cookies]
-d-p--e--- OK (17  out of 25 , remaining: 00:01)
test 1104...[HTTP cookie expiry date at Jan 1 00:00:00 GMT 1970]
-d-p--e--- OK (18  out of 25 , remaining: 00:01)
test 1105...[HTTP with cookie parser and header recording]
-d-p-oe--- OK (19  out of 25 , remaining: 00:01)
test 1216...[HTTP cookie domains tailmatching the host name]
-d-p--e--- OK (20  out of 25 , remaining: 00:01)
test 1218...[HTTP cookies and domains with same prefix]
-d-p--e--- OK (21  out of 25 , remaining: 00:00)
test 1228...[HTTP cookie path match]
-d-p--e--- OK (22  out of 25 , remaining: 00:00)
test 1331...[HTTP --proxy-anyauth and 407 with cookies]
-d-p--e--- OK (23  out of 25 , remaining: 00:00)
test 1401...[--libcurl for GET with various options]
-d-p-oe--- OK (24  out of 25 , remaining: 00:00)
test 1408...[HTTP receive cookies over IPV6]
---p--e--- OK (25  out of 25 , remaining: 00:00)
Warning: test9001 not present in tests/data/Makefile.am
test 9001...[Delete expired cookies]
-d-p-oe--- OK (26  out of 26 , remaining: 00:00)
TESTDONE: 26 tests out of 26 reported OK: 100%
TESTDONE: 26 tests were considered during 7 seconds.

-- 
.


The contents of this e-mail 

Re: HTTP NTLM user authentication

2013-09-17 Thread Václav Zeman
On 15 September 2013 19:31, Daniel Stenberg dan...@haxx.se wrote:
 On Sat, 14 Sep 2013, Václav Zeman wrote:

 We are trying to use libcurl to do POST requests with SOAP payload. We are
 using libcurl 7.18.0 and we have tested the same code against IIS server
 with Basic authentication enabled. Now we have turned on NTLM as well and we
 are seeing that our client is not able to authenticate. I am attaching
 (anonymized) log file of one session that shows how it cycles the requests
 and dies after 16 attempts (limit set up by our code).

 I would like to know if this is a know bug in older libcurl or if this can
 be caused by our code and the way we set up libcurl?


 I don't know. Try the latest libcurl version and see if the problem is still
 there. If it is, show us some code on how to repeat the problem and we can
 tell if the code looks correct or not.

Just FYI, the problem was with Connection: close that was added by
gSOAP. (We use libcurl as back-end for gSOAP).

-- 
VZ

---
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html

Re: best practices: c-ares vs threaded resolver

2013-09-17 Thread Gisle Vanem

m brandenberg mcb...@panix.com wrote:


So these and other issues make me want to use the system resolver
library.  When it fails, there's a general system/network
configuration issue that doesn't become a support issue for us.


I tend to agree. The systems resolver seems alway to work best
for me. At least when I use a VPN. Then (without messing with my routing-
table, C-ares is using the default interface which doesn't work). I whish
there could be a config-file similar to '/etc/resolv.conf' for C-ares/Win.

Besides the new C-ares functions for specifying DNS addr/iface that's
recently been added to curl does nothing on Windows; '--dns-interface'
boils down to 'setsockopt (..SO_BINDTODEVICE)' and '--dns-ipvX-addr'
boils down to a 'bind(..ipvX-addr)' which AFAICS is useful only for those 
running a DNS-server locally. I doesn't do any good on my Winsock. The

'--dns-ipvX-addr' option should IMHO be used to specify what DNS-server
to connect to.

--gv
---
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html


Re: best practices: c-ares vs threaded resolver

2013-09-17 Thread Ben Greear

On 09/17/2013 09:46 AM, Gisle Vanem wrote:

m brandenberg mcb...@panix.com wrote:


So these and other issues make me want to use the system resolver
library.  When it fails, there's a general system/network
configuration issue that doesn't become a support issue for us.


I tend to agree. The systems resolver seems alway to work best
for me. At least when I use a VPN. Then (without messing with my routing-
table, C-ares is using the default interface which doesn't work). I whish
there could be a config-file similar to '/etc/resolv.conf' for C-ares/Win.

Besides the new C-ares functions for specifying DNS addr/iface that's
recently been added to curl does nothing on Windows; '--dns-interface'
boils down to 'setsockopt (..SO_BINDTODEVICE)' and '--dns-ipvX-addr'
boils down to a 'bind(..ipvX-addr)' which AFAICS is useful only for those 
running a DNS-server locally. I doesn't do any good on my Winsock. The
'--dns-ipvX-addr' option should IMHO be used to specify what DNS-server
to connect to.


Even on Linux, you might have to play some routing-table tricks to make the 
bind(local-ip) work
as expected, but at least it can be done.

I have no idea how to make this sort of thing function fully proper on Windows, 
though
I would expect binding to a local IP might be useful on a multi-homed machine.

I know BSD doesn't have SO_BINDTODEVICE, but I do not know the exact behaviour
of binding to local IP.

Thanks,
Ben



--gv
---
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html



--
Ben Greear gree...@candelatech.com
Candela Technologies Inc  http://www.candelatech.com

---
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html


Library error while debugging (fwd)

2013-09-17 Thread Daniel Stenberg

Forwarding your mail to the correct address...

--

 / daniel.haxx.se

-- Forwarded message --
Date: Tue, 17 Sep 2013 17:54:03
From: Soni, Vijay vijay.s...@voith.com
To: curl-library-ow...@cool.haxx.se curl-library-ow...@cool.haxx.se
Subject: Library error while debugging

Hi,

Thanks for creating cURL.

I am a beginner and was trying to use libcurl in my test application and 
followed all the steps as detailed in the 
Using-libcurl-with-SSH-support-in-Visual-Studio-2010.pdf.
Errors
1libcurl.lib(ldap.obj) : error LNK2019: unresolved external symbol 
__imp__ldap_unbind_s referenced in function _Curl_ldap
1libcurl.lib(ldap.obj) : error LNK2019: unresolved external symbol 
__imp__ldap_msgfree referenced in function _Curl_ldap
1libcurl.lib(ldap.obj) : error LNK2019: unresolved external symbol 
__imp__ber_free referenced in function _Curl_ldap
1libcurl.lib(ldap.obj) : error LNK2019: unresolved external symbol 
__imp__ldap_memfree referenced in function _Curl_ldap
1libcurl.lib(ldap.obj) : error LNK2019: unresolved external symbol 
__imp__ldap_value_free_len referenced in function _Curl_ldap
1libcurl.lib(ldap.obj) : error LNK2019: unresolved external symbol 
__imp__ldap_get_values_len referenced in function _Curl_ldap
1libcurl.lib(ldap.obj) : error LNK2019: unresolved external symbol 
__imp__ldap_next_attribute referenced in function _Curl_ldap
1libcurl.lib(ldap.obj) : error LNK2019: unresolved external symbol 
__imp__ldap_first_attribute referenced in function _Curl_ldap
1libcurl.lib(ldap.obj) : error LNK2019: unresolved external symbol 
__imp__ldap_get_dn referenced in function _Curl_ldap
1libcurl.lib(ldap.obj) : error LNK2019: unresolved external symbol 
__imp__ldap_next_entry referenced in function _Curl_ldap
1libcurl.lib(ldap.obj) : error LNK2019: unresolved external symbol 
__imp__ldap_first_entry referenced in function _Curl_ldap
1libcurl.lib(ldap.obj) : error LNK2019: unresolved external symbol 
__imp__ldap_search_s referenced in function _Curl_ldap
1libcurl.lib(ldap.obj) : error LNK2019: unresolved external symbol 
__imp__ldap_simple_bind_s referenced in function _Curl_ldap
1libcurl.lib(ldap.obj) : error LNK2019: unresolved external symbol 
__imp__ldap_init referenced in function _Curl_ldap
1libcurl.lib(ldap.obj) : error LNK2019: unresolved external symbol 
__imp__ldap_set_option referenced in function _Curl_ldap
1libcurl.lib(ldap.obj) : error LNK2019: unresolved external symbol 
__imp__ldap_err2string referenced in function _Curl_ldap


Please help what should I do now.

Thanks in advance
Vijay

---
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html


RE: Windows autobuilds broken since df69440d05f1133a9053e19a9bf576c8b13514b9

2013-09-17 Thread Daniel Stenberg

On Tue, 17 Sep 2013, Steve Holme wrote:

I did wonder if this was a problem was with the interface parameter in 
Curl_set_dns_interface(), which then clashes with something declared in a 
MinGW header file, as I can't really see anything else wrong - but without 
access to a MinGW environment I didn't want to randomly committing possible 
fixes.


Ah, that seems to be it! We did a similar commit already before:

See commit 4c4e8ba1f060f

--

 / daniel.haxx.se
---
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html


RE: Windows autobuilds broken since df69440d05f1133a9053e19a9bf576c8b13514b9

2013-09-17 Thread Steve Holme
On Tue, 17 Sep 2013, Steve Holme wrote:

  Ah, that seems to be it! We did a similar commit already before:
 
  See commit 4c4e8ba1f060f

 Cheers. I'll fix it up and push a commit out ;-)

Pushed as commit 158dfe2c5c9e4 - Hopefully I've got them all and haven't
made things worse!

I'll keep any eye on the auto builds over the next few hours.

Kind Regards

Steve
---
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html


Re: PATCH: Curl makefile.in of lib directory change(order of variables for linking)

2013-09-17 Thread Daniel Stenberg

On Mon, 16 Sep 2013, Arunav Sanyal wrote:

Certain versions of HP-UX does not allow linking using 
SHLIB_PATH(counterpart of LD_LIBRARY_PATH). As a result, custom library 
linking was failing. Following change fixes the linking issue:-


Which version did you see this problem with? We did modify the LDFLAGS usage 
in there rather recently.



Note: $(CURL_HOME)/lib/Makefile.in was changed


The Makefile.in file is generated from the Makefile.am file though so that's 
where a change needs to be done - if any. When I look in the 
generated lib/Makefile.in I have, it looks like similar to what your patch 
seems to want... ?


--

 / daniel.haxx.se
---
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html


Re: [PATCH ] Add new options negotiate-gssapi=service and proxy-negotiate-gssapi-service

2013-09-17 Thread Daniel Stenberg

On Sat, 14 Sep 2013, Markus Moeller wrote:


Could this now go into the next release ?


(this being curl-7.31.0-gssapi-service-v3.patch)

It doesn't apply cleanly anymore since there have been new values added in the 
CINIT list in curl.h.


I don't like how you removed backwards compatibility. This will unnecessarily 
break some existing applications. Can't we just use the old name by default 
and use the new option to override the default?


I would prefer to drop the negotiate part from the names all over to make 
them shorter and thus more readable.


--

 / daniel.haxx.se
---
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html


Re: best practices: c-ares vs threaded resolver

2013-09-17 Thread m brandenberg

On Tue, 17 Sep 2013, Daniel Stenberg wrote:


On Mon, 16 Sep 2013, m brandenberg wrote:


* General unreliability on platforms with DNS timeouts on all
  three platforms.


This sounds like a bug, in either c-ares or libcurl.


Possibly.  But it could also be multiple causes.  The
problem in these scenarios is that it is the result of the
local environment.  I have very little success reproducing
these in the development environment.


* OS X is having trouble keeping /etc/resolv.conf valid.  Either
  the symlink is damaged or the target (/var/run/resolv.conf)
  isn't being regenerated reliably on network reconfigurations.
  Result is a broken server list in c-ares.


This sounds like a broken OS X or that c-ares needs to get its list of 
servers differently.


Both, I think.  But using the native system to extract server
information while supporting multiple OS versions leaves you
chasing changes.  Like the transition away from NetInfo in
the case of OSX.


* Magical failures.


More c-ares bugs?


No, environment, I think, and c-ares is the victim.  As the
main OSs have acquired deeper networking functions and things
like anti-viruses and firewalls keep adding new features to
attract users, surprising behaviors are coming out of the
systems.

But looking at the implementation of the threaded resolver makes me ask a 
few questions.  It's a thread-per-request scheme.  Good for avoiding a 
stall behind a request that will timeout or be answered slowly.  But this 
makes unbounded demands on thread count.


Yes. Of course that could be modified/improved but it would also make things 
more complicated and you'd also get problems with one slow resolve hogging 
the other subsequent resolves if you just use a queue in a single resolver 
thread.


Yep, I am thinking of an optional something in between one or all.
Parameter on a multi limiting the number of outstanding requests
or an EAGAIN-like status between libcurl and the c-ares/TR api.
*If* it is a problem in practice.  I wonder if anyone has seen
a problem with the threaded resolver in the field.

The c-ares we're using *is* old, 1.7.1, and that will get bumped up but 
maybe it's time to change.


Some of your problems may have been fixed since that version. Development may 
be slow in c-ares but there are like 8 releases done since that version.


Yeah, I will likely roll forward anyway.  The test cycle is
sadly slow and unreliable for this set of problems...

m

--
Monty Brandenberg
---
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html