Re: Old Curl Project

[Don Landsom]

Thanks again Joel.

If there were a contest to see how many erogenous warning and errors that could 
be generated from developing on an old platform, we might be in the running. 
From missing declarations from the most basic such as WIN32 to others that have 
much more of an obscure nature to them. To problems occurring from subsystems 
like PDSK and LDAP that happen to be insufficient in their library versions, to 
completely missing libraries and header files. One can sit watching the 
compiler and or linker scroll volumes of errors for what seems like an eternity.
Then comes the order in which products must be installed as when attempting to 
correct issue with say the MS SDK and it’s inability to load while the C 
redistributable is installed. And don’t even want to get into the OS, and 
development tool service packs which at times appear to have a desire be loaded 
and then reloaded as other products are added. After a while you start to feel 
like a dog that’s chasing his own tail.

While it did mean leavening all of this behind, thank goodness, moving to the 
new version was definitely the way to go, thanks for getting us headed in the 
right direction.

This is neither here nor there, but I’ve noticed when checking file sizes for 
Curl dll’s and library files, they seem to be all over the place. Up for some 
and down in others, which is to be expected as the product grows, but it seems 
unusual for later releases to be smaller then previous ones. Is this possibly 
coming from the particular features the Curl version was built with?

Thanks

  - Original Message - 
  From: Joel Winarske 
  To: libcurl development 
  Sent: Thursday, May 17, 2018 12:48 PM
  Subject: Re: Old Curl Project


  Either should work fine.  I just used the most current release for my CMake 
file.


  Whichever VS version you do use, ensure you have the proper tool chain 
installed to support XP prior to using CMake.


  On Thu, May 17, 2018 at 9:16 AM, Don Landsom  wrote:

Thanks for the help and links. We have no problem going after a build with 
the latest and greatest. We already have 7.59, but noticed that 7.60 was just 
recently released. Should we go ahead and grab 60 and work with it instead of 
59?

  - Original Message - 
  From: Joel Winarske 
  To: libcurl development 
  Sent: Thursday, May 17, 2018 11:31 AM
  Subject: Re: Old Curl Project


  I just tested the follow work via CMake and VS2015: 
  
https://gist.github.com/INRIX-joel-winarske/beb8a4a1192d5737fd789f05b22590ca



  Copy CMakeLists.txt to a folder, create a subfolder called build.  cd 
into that, and issue the solution generator command:



  cmake -G"Visual Studio 14 2015" ..



  This does need to be run on the build machine, and note it will have hard 
coded paths to the build machine.  


  Swap out the below string depending on which VS variant you want:
Visual Studio 14 2015

Visual Studio 12 2013
Visual Studio 11 2012
Visual Studio 10 2010
Visual Studio 9 2008
Visual Studio 8 2005


  After that open your selected VS as admin (to allow installation), and 
open the solution.
  Ensure your target for each project is as you want, then build 
"BUILD_ALL".


  You may need to right-click solution, and select retarget picking the 
proper sdk/toolchain for XP.


  Note I am running the generator cmd in a generic windows cmd prompt.  
Just ensure CMake is in your path.




  Joel


  On Thu, May 17, 2018 at 6:09 AM, Don Landsom  
wrote:

Joel, Thanks for the XP and VS2015 link, much appreciated.

As for any preferences towards OpenSSL or any other libraries, we have 
none with our primary goal being to simply get our interim fix up and running. 
If Mbedtls makes for an easy drop in replacement for OpenSSL then there would 
be no objection.
  - Original Message - 
  From: Joel Winarske 
  To: libcurl development 
  Sent: Thursday, May 17, 2018 8:48 AM
  Subject: Re: Old Curl Project


  Hi Don, 


  You can Target XP with visual studio 2015.  Clues found here:  
https://msdn.microsoft.com/en-us/library/jj851139.aspx


  CMake has supported VS2015 solution generation for a while.  I would 
avoid OpenSSL hair pulling and use Mbedtls with the latest curl release, unless 
there is something particular you're using in OpenSSL, that Mbedtls doesn't 
have.




  Joel


  On Thu, May 17, 2018, 5:19 AM Don Landsom  
wrote:

Thanks for the message and guidance provided, and yes trying to 
build apps 
on old systems has it’s challenges, and more times then not proves 
to be 
more work then it’s worth. However being under time constraints 
paints a 
different picture pushing us down the path of adopting 

Re: Asiohiper example program delay

[Daniel Stenberg]

On Thu, 17 May 2018, Sean Miller wrote:


1) In the WAITCONNECT state, libcurl calls multi_timer_cb(200) and registers 
interest in writing.
2) The FSM transitions first to SENDPROTOCONNECT and then to PROTOCONNECT.
3) Libcurl calls remsock() through sock_cb().
4) ... Nothing happens until the timer fires ~165 ms later.

What should the example do, if possible, to avoid this delay?


I think you've stepped on a libcurl bug!

Are you doing HTTPS through a HTTP proxy by any chance? That's what the 
PROTOCONNECT state is for basically.


While in this state, libcurl does not extract and return the correct socket to 
wait for and this is probably what causes this for you. I *think* this bug is 
present there because the CONNECT procedure was once blocking so then this 
state would never return a socket... and when we made that non-blocking, I 
probably missed this part.


Does it seem like that could be what happens in your case? If so, I'll write 
up a patch you can test...


--

 / daniel.haxx.se
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Asiohiper example program delay

[Sean Miller]

I added simple logging and a debug function to the following Boost ASIO-based 
example program:

https://curl.haxx.se/libcurl/c/asiohiper.html

Summary:

1) In the WAITCONNECT state, libcurl calls multi_timer_cb(200) and registers 
interest in writing.
2) The FSM transitions first to SENDPROTOCONNECT and then to PROTOCONNECT.
3) Libcurl calls remsock() through sock_cb().
4) ... Nothing happens until the timer fires ~165 ms later.

What should the example do, if possible, to avoid this delay? I appreciate any 
ideas/clues/hints. Until then, I'm investigating the differences between this 
and the other example programs.

I'm including the log (trimmed to point of interest) below:

2018-05-17 21:06:11,461 INFO  root - opensocket:
2018-05-17 21:06:11,461 INFO  root - from libcurl:   Trying 172.217.12.4...
2018-05-17 21:06:11,461 INFO  root - from libcurl: TCP_NODELAY set
2018-05-17 21:06:11,461 INFO  root - from libcurl: STATE: WAITRESOLVE => 
WAITCONNECT handle 0x1d97188; line 1539 (connection #0)
2018-05-17 21:06:11,461 INFO  root - sock_cb (sock=6, what=2)
2018-05-17 21:06:11,461 INFO  root - sock_cb: adding data: OUT
2018-05-17 21:06:11,461 INFO  root - addsock (action=2)
2018-05-17 21:06:11,461 INFO  root - setsock (sock=6, action=2, oldact=0)
2018-05-17 21:06:11,461 INFO  root - setsock: watching for socket to become 
writable
2018-05-17 21:06:11,461 INFO  root - multi_timer_cb (timeout_ms=200)
2018-05-17 21:06:11,461 INFO  root - check_multi_info; remaining=1
2018-05-17 21:06:11,494 INFO  root - event_cb (sock=6, action=2)
2018-05-17 21:06:11,494 INFO  root - event_cb: running multi socket action
2018-05-17 21:06:11,494 INFO  root - from libcurl: Connected to www.google.com 
(172.217.12.4) port 80 (#0)
2018-05-17 21:06:11,494 INFO  root - from libcurl: STATE: WAITCONNECT => 
SENDPROTOCONNECT handle 0x1d97188; line 1591 (connection #0)
2018-05-17 21:06:11,494 INFO  root - from libcurl: Marked for [keep alive]: 
HTTP default
2018-05-17 21:06:11,494 INFO  root - from libcurl: STATE: SENDPROTOCONNECT => 
PROTOCONNECT handle 0x1d97188; line 1605 (connection #0)
2018-05-17 21:06:11,494 INFO  root - sock_cb (sock=6, what=4)
2018-05-17 21:06:11,494 INFO  root - remsock
2018-05-17 21:06:11,494 INFO  root - check_multi_info; remaining=1
2018-05-17 21:06:11,494 INFO  root - event_cb: keep watching...?
2018-05-17 21:06:11,662 INFO  root - timer_cb: 
2018-05-17 21:06:11,662 INFO  root - from libcurl: STATE: PROTOCONNECT => DO 
handle 0x1d97188; line 1626 (connection #0)
2018-05-17 21:06:11,662 INFO  root - from libcurl: STATE: DO => DO_DONE handle 
0x1d97188; line 1688 (connection #0)
2018-05-17 21:06:11,662 INFO  root - from libcurl: STATE: DO_DONE => 
WAITPERFORM handle 0x1d97188; line 1813 (connection #0)
2018-05-17 21:06:11,662 INFO  root - from libcurl: STATE: WAITPERFORM => 
PERFORM handle 0x1d97188; line 1823 (connection #0)
2018-05-17 21:06:11,662 INFO  root - sock_cb (sock=6, what=1)
2018-05-17 21:06:11,662 INFO  root - sock_cb: adding data: IN
2018-05-17 21:06:11,662 INFO  root - addsock (action=1)
2018-05-17 21:06:11,662 INFO  root - setsock (sock=6, action=1, oldact=0)
2018-05-17 21:06:11,662 INFO  root - setsock: watching for socket to become 
readable
2018-05-17 21:06:11,662 INFO  root - multi_timer_cb (timeout_ms=1000)
2018-05-17 21:06:11,662 INFO  root - check_multi_info; remaining=1

Thanks,
Sean M.



---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Re: Old Curl Project

[Joel Winarske]

Either should work fine.  I just used the most current release for my CMake
file.

Whichever VS version you do use, ensure you have the proper tool chain
installed to support XP prior to using CMake.

On Thu, May 17, 2018 at 9:16 AM, Don Landsom 
wrote:

> Thanks for the help and links. We have no problem going after a build with
> the latest and greatest. We already have 7.59, but noticed that 7.60 was
> just recently released. Should we go ahead and grab 60 and work with it
> instead of 59?
>
> - Original Message -
> *From:* Joel Winarske 
> *To:* libcurl development 
> *Sent:* Thursday, May 17, 2018 11:31 AM
> *Subject:* Re: Old Curl Project
>
> I just tested the follow work via CMake and VS2015:
> https://gist.github.com/INRIX-joel-winarske/beb8a4a1192d5737fd789f05b22590
> ca
>
> Copy CMakeLists.txt to a folder, create a subfolder called build.  cd into
> that, and issue the solution generator command:
>
> cmake -G"Visual Studio 14 2015" ..
>
> This does need to be run on the build machine, and note it will have hard
> coded paths to the build machine.
>
> Swap out the below string depending on which VS variant you want:
>   Visual Studio 14 2015
>   Visual Studio 12 2013
>   Visual Studio 11 2012
>   Visual Studio 10 2010
>   Visual Studio 9 2008
>   Visual Studio 8 2005
>
> After that open your selected VS as admin (to allow installation), and
> open the solution.
> Ensure your target for each project is as you want, then build "BUILD_ALL".
>
> You may need to right-click solution, and select retarget picking the
> proper sdk/toolchain for XP.
>
> Note I am running the generator cmd in a generic windows cmd prompt.  Just
> ensure CMake is in your path.
>
>
> Joel
>
> On Thu, May 17, 2018 at 6:09 AM, Don Landsom 
> wrote:
>
>> Joel, Thanks for the XP and VS2015 link, much appreciated.
>>
>> As for any preferences towards OpenSSL or any other libraries, we have
>> none with our primary goal being to simply get our interim fix up and
>> running. If Mbedtls makes for an easy drop in replacement for OpenSSL then
>> there would be no objection.
>>
>> - Original Message -
>> *From:* Joel Winarske 
>> *To:* libcurl development 
>> *Sent:* Thursday, May 17, 2018 8:48 AM
>> *Subject:* Re: Old Curl Project
>>
>> Hi Don,
>>
>> You can Target XP with visual studio 2015.  Clues found here:
>> https://msdn.microsoft.com/en-us/library/jj851139.aspx
>>
>> CMake has supported VS2015 solution generation for a while.  I would
>> avoid OpenSSL hair pulling and use Mbedtls with the latest curl release,
>> unless there is something particular you're using in OpenSSL, that Mbedtls
>> doesn't have.
>>
>>
>> Joel
>>
>> On Thu, May 17, 2018, 5:19 AM Don Landsom 
>> wrote:
>>
>>> Thanks for the message and guidance provided, and yes trying to build
>>> apps
>>> on old systems has it’s challenges, and more times then not proves to be
>>> more work then it’s worth. However being under time constraints paints a
>>> different picture pushing us down the path of adopting this interim step.
>>>
>>> Initially looked at taking the leap to the latest curl version only to
>>> realize how many subsystems wouldn’t be easily adapted to the old XP
>>> platform and it’s development tools. Parallel efforts are underway,
>>> slapping
>>> a Band-Aid on the old, and creating the new through the migration of the
>>> legacy systems to a current development environment.
>>>
>>> The version of libcurl being used appears to be linked with
>>> openssl-0.9.7e,
>>> c-ares-1.2.1 and zlib-1.2.1. The interface calls made from VB6 through
>>> the
>>> wrapper makes use of the Curl ‘easy’ interface.
>>>
>>> The hopes were that the Band-Aid approach could mimic the build above,
>>> substituting Curl-7.13 with Curl-7.20 just long enough to bridge the gap
>>> between now and when the migration to the new system is complete.
>>>
>>> A preliminary test showed that the basic Curl-7.20 version builds
>>> successfully on XP, however it would seem that this build is void of the
>>> required libraries: openssl, c-ares or zlib.
>>>
>>> If we can incorporate these additional libraries into our successful
>>> test
>>> build of 7-20, we could have our Band-Aid.
>>>
>>> - Original Message -
>>> From: "Daniel Stenberg" 
>>> To: "libcurl development" 
>>> Sent: Thursday, May 17, 2018 4:26 AM
>>> Subject: Re: Old Curl Project
>>>
>>>
>>> > On Thu, 17 May 2018, Don Landsom wrote:
>>> >
>>> >> I'm new here and was hoping to learn more about Curl in the attempts
>>> to
>>> >> breath some life into an old project until it can be brought up to
>>> date
>>> >> through a complete overhaul.
>>> >
>>> > You're most welcome!
>>> >
>>> >> Not looking to take too big of a leap hear as everything is to be
>>> >> replaced so I searched to find 

Re: Old Curl Project

[Don Landsom]

Thanks for the help and links. We have no problem going after a build with the 
latest and greatest. We already have 7.59, but noticed that 7.60 was just 
recently released. Should we go ahead and grab 60 and work with it instead of 
59?

  - Original Message - 
  From: Joel Winarske 
  To: libcurl development 
  Sent: Thursday, May 17, 2018 11:31 AM
  Subject: Re: Old Curl Project


  I just tested the follow work via CMake and VS2015:
  https://gist.github.com/INRIX-joel-winarske/beb8a4a1192d5737fd789f05b22590ca



  Copy CMakeLists.txt to a folder, create a subfolder called build.  cd into 
that, and issue the solution generator command:



  cmake -G"Visual Studio 14 2015" ..



  This does need to be run on the build machine, and note it will have hard 
coded paths to the build machine.  


  Swap out the below string depending on which VS variant you want:
Visual Studio 14 2015

Visual Studio 12 2013
Visual Studio 11 2012
Visual Studio 10 2010
Visual Studio 9 2008
Visual Studio 8 2005


  After that open your selected VS as admin (to allow installation), and open 
the solution.
  Ensure your target for each project is as you want, then build "BUILD_ALL".


  You may need to right-click solution, and select retarget picking the proper 
sdk/toolchain for XP.


  Note I am running the generator cmd in a generic windows cmd prompt.  Just 
ensure CMake is in your path.




  Joel


  On Thu, May 17, 2018 at 6:09 AM, Don Landsom  wrote:

Joel, Thanks for the XP and VS2015 link, much appreciated.

As for any preferences towards OpenSSL or any other libraries, we have none 
with our primary goal being to simply get our interim fix up and running. If 
Mbedtls makes for an easy drop in replacement for OpenSSL then there would be 
no objection.
  - Original Message - 
  From: Joel Winarske 
  To: libcurl development 
  Sent: Thursday, May 17, 2018 8:48 AM
  Subject: Re: Old Curl Project


  Hi Don, 


  You can Target XP with visual studio 2015.  Clues found here:  
https://msdn.microsoft.com/en-us/library/jj851139.aspx


  CMake has supported VS2015 solution generation for a while.  I would 
avoid OpenSSL hair pulling and use Mbedtls with the latest curl release, unless 
there is something particular you're using in OpenSSL, that Mbedtls doesn't 
have.




  Joel


  On Thu, May 17, 2018, 5:19 AM Don Landsom  wrote:

Thanks for the message and guidance provided, and yes trying to build 
apps 
on old systems has it’s challenges, and more times then not proves to 
be 
more work then it’s worth. However being under time constraints paints 
a 
different picture pushing us down the path of adopting this interim 
step.

Initially looked at taking the leap to the latest curl version only to 
realize how many subsystems wouldn’t be easily adapted to the old XP 
platform and it’s development tools. Parallel efforts are underway, 
slapping 
a Band-Aid on the old, and creating the new through the migration of 
the 
legacy systems to a current development environment.

The version of libcurl being used appears to be linked with 
openssl-0.9.7e, 
c-ares-1.2.1 and zlib-1.2.1. The interface calls made from VB6 through 
the 
wrapper makes use of the Curl ‘easy’ interface.

The hopes were that the Band-Aid approach could mimic the build above, 
substituting Curl-7.13 with Curl-7.20 just long enough to bridge the 
gap 
between now and when the migration to the new system is complete.

A preliminary test showed that the basic Curl-7.20 version builds 
successfully on XP, however it would seem that this build is void of 
the 
required libraries: openssl, c-ares or zlib.

If we can incorporate these additional libraries into our successful 
test 
build of 7-20, we could have our Band-Aid.

- Original Message - 
From: "Daniel Stenberg" 
To: "libcurl development" 
Sent: Thursday, May 17, 2018 4:26 AM
Subject: Re: Old Curl Project


> On Thu, 17 May 2018, Don Landsom wrote:
>
>> I'm new here and was hoping to learn more about Curl in the attempts 
to 
>> breath some life into an old project until it can be brought up to 
date 
>> through a complete overhaul.
>
> You're most welcome!
>
>> Not looking to take too big of a leap hear as everything is to be 
>> replaced so I searched to find the closest possible Curl release 
support 
>> SMPT which appears to be Curl-7.20.0.
>
> SMTP support was initially added in 7.20.0, yes. But it has also been 
> polished and bugfixed over the years so I would not recommend using 
the 
> first 

RE: Old Curl Project

[Rod Widdowson]

Don,

> A preliminary test showed that the basic Curl-7.20 version builds
> successfully on XP, however it would seem that this build is void of the
> required libraries: openssl, c-ares or zlib.

Speaking for OpenSSL and Zlib - you have to build these yourself.  We recently 
retired our XP build (as we moved off VC10) but I know that both of those 
projects build OK with the older tools.

I hear where you are coming from (change as little as possible so as to keep 
the old thing of life-support) but as a curl consumer, I would emphasise 
Daniels suggestion of going to the latest and greatest (for curl and zlib at 
least) both these products have (IMO) a good track record of not breaking the 
ABI and if Daniel says it ain't broken it probably isn’t, it certainly won't be 
purposely broken.

I don't include OpenSSL for want of evidence to the contrary.  I'll remark that 
out move to 1.2 was reasonably complicated but that was because of our need to 
dive inside OpenSLL's structures for our own needs.

FWIW
Rod


---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Re: Old Curl Project

[Joel Winarske]

Hi Don,

You can Target XP with visual studio 2015.  Clues found here:
https://msdn.microsoft.com/en-us/library/jj851139.aspx

CMake has supported VS2015 solution generation for a while.  I would avoid
OpenSSL hair pulling and use Mbedtls with the latest curl release, unless
there is something particular you're using in OpenSSL, that Mbedtls doesn't
have.


Joel

On Thu, May 17, 2018, 5:19 AM Don Landsom  wrote:

> Thanks for the message and guidance provided, and yes trying to build apps
> on old systems has it’s challenges, and more times then not proves to be
> more work then it’s worth. However being under time constraints paints a
> different picture pushing us down the path of adopting this interim step.
>
> Initially looked at taking the leap to the latest curl version only to
> realize how many subsystems wouldn’t be easily adapted to the old XP
> platform and it’s development tools. Parallel efforts are underway,
> slapping
> a Band-Aid on the old, and creating the new through the migration of the
> legacy systems to a current development environment.
>
> The version of libcurl being used appears to be linked with
> openssl-0.9.7e,
> c-ares-1.2.1 and zlib-1.2.1. The interface calls made from VB6 through the
> wrapper makes use of the Curl ‘easy’ interface.
>
> The hopes were that the Band-Aid approach could mimic the build above,
> substituting Curl-7.13 with Curl-7.20 just long enough to bridge the gap
> between now and when the migration to the new system is complete.
>
> A preliminary test showed that the basic Curl-7.20 version builds
> successfully on XP, however it would seem that this build is void of the
> required libraries: openssl, c-ares or zlib.
>
> If we can incorporate these additional libraries into our successful test
> build of 7-20, we could have our Band-Aid.
>
> - Original Message -
> From: "Daniel Stenberg" 
> To: "libcurl development" 
> Sent: Thursday, May 17, 2018 4:26 AM
> Subject: Re: Old Curl Project
>
>
> > On Thu, 17 May 2018, Don Landsom wrote:
> >
> >> I'm new here and was hoping to learn more about Curl in the attempts to
> >> breath some life into an old project until it can be brought up to date
> >> through a complete overhaul.
> >
> > You're most welcome!
> >
> >> Not looking to take too big of a leap hear as everything is to be
> >> replaced so I searched to find the closest possible Curl release
> support
> >> SMPT which appears to be Curl-7.20.0.
> >
> > SMTP support was initially added in 7.20.0, yes. But it has also been
> > polished and bugfixed over the years so I would not recommend using the
> > first public version supporting it. I think it had a few rough edges
> still
> > for some releases.
> >
> > In general you won't gain much by doing a small upgrade compared to a
> big
> > upgrade. If you instead jump to the head of the line at 7.60.0, you'll
> get
> > our attention and support if you have problems or questions. Not so much
> > for 7.20.0, which is over 8 years old by now.
> >
> > The API and behavior *should* still be the same as it was back in the
> > 7.13.0 days!
> >
> > Also note that 7.20.0 has a few known security vulnerabilities:
> >
> >   https://curl.haxx.se/docs/vuln-7.20.0.html
> >
> >> The current application is running VB6 using the dll wrapper VBLibCurl
> >> 1.0, so the big question is whether this wrapper can be interfaced with
> >> Curl-7.20.0.
> >
> > I would imagine that building stuff on such old legacy systems is a pain
> > in general.
> >
> > --
> >
> >  / daniel.haxx.se
> > ---
> > Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
> > Etiquette:   https://curl.haxx.se/mail/etiquette.html
>
> ---
> Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
> Etiquette:   https://curl.haxx.se/mail/etiquette.html
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Re: Old Curl Project

[Don Landsom]

Thanks for the message and guidance provided, and yes trying to build apps 
on old systems has it’s challenges, and more times then not proves to be 
more work then it’s worth. However being under time constraints paints a 
different picture pushing us down the path of adopting this interim step.


Initially looked at taking the leap to the latest curl version only to 
realize how many subsystems wouldn’t be easily adapted to the old XP 
platform and it’s development tools. Parallel efforts are underway, slapping 
a Band-Aid on the old, and creating the new through the migration of the 
legacy systems to a current development environment.


The version of libcurl being used appears to be linked with openssl-0.9.7e, 
c-ares-1.2.1 and zlib-1.2.1. The interface calls made from VB6 through the 
wrapper makes use of the Curl ‘easy’ interface.


The hopes were that the Band-Aid approach could mimic the build above, 
substituting Curl-7.13 with Curl-7.20 just long enough to bridge the gap 
between now and when the migration to the new system is complete.


A preliminary test showed that the basic Curl-7.20 version builds 
successfully on XP, however it would seem that this build is void of the 
required libraries: openssl, c-ares or zlib.


If we can incorporate these additional libraries into our successful test 
build of 7-20, we could have our Band-Aid.


- Original Message - 
From: "Daniel Stenberg" 

To: "libcurl development" 
Sent: Thursday, May 17, 2018 4:26 AM
Subject: Re: Old Curl Project



On Thu, 17 May 2018, Don Landsom wrote:

I'm new here and was hoping to learn more about Curl in the attempts to 
breath some life into an old project until it can be brought up to date 
through a complete overhaul.


You're most welcome!

Not looking to take too big of a leap hear as everything is to be 
replaced so I searched to find the closest possible Curl release support 
SMPT which appears to be Curl-7.20.0.


SMTP support was initially added in 7.20.0, yes. But it has also been 
polished and bugfixed over the years so I would not recommend using the 
first public version supporting it. I think it had a few rough edges still 
for some releases.


In general you won't gain much by doing a small upgrade compared to a big 
upgrade. If you instead jump to the head of the line at 7.60.0, you'll get 
our attention and support if you have problems or questions. Not so much 
for 7.20.0, which is over 8 years old by now.


The API and behavior *should* still be the same as it was back in the 
7.13.0 days!


Also note that 7.20.0 has a few known security vulnerabilities:

  https://curl.haxx.se/docs/vuln-7.20.0.html

The current application is running VB6 using the dll wrapper VBLibCurl 
1.0, so the big question is whether this wrapper can be interfaced with 
Curl-7.20.0.


I would imagine that building stuff on such old legacy systems is a pain 
in general.


--

 / daniel.haxx.se
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html 


---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Re: CoAP support in libcurl for the Internet of Things

[Olaf Bergmann]

Daniel,

Daniel Stenberg  writes:

> On Thu, 17 May 2018, Olaf Bergmann wrote:
>
>> I think the most important question Remy wanted to ask is whether or
>> not it would be useful to invest time into doing whatever it takes
>> to add CoAP support to libcurl. It would be great if you had advice
>> here as well.
>
> I think it fits into the libcurl model and concept, so if anyone wants
> to work on making this happen I will cooperate and help out to get it
> merged.

Great, thanks again for your support.

Grüße
Olaf

---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Re: CoAP support in libcurl for the Internet of Things

[Daniel Stenberg]

On Thu, 17 May 2018, Olaf Bergmann wrote:

I think the most important question Remy wanted to ask is whether or not it 
would be useful to invest time into doing whatever it takes to add CoAP 
support to libcurl. It would be great if you had advice here as well.


I think it fits into the libcurl model and concept, so if anyone wants to work 
on making this happen I will cooperate and help out to get it merged.


My comments about libcoap should all be seen from that angle: I want to be 
convinced that when we recommend people to build libcurl with a new third 
party library, that library is solid. People will view it as sort of "vouch" 
from us. Not to mention that once this is offered, a bunch of merry security 
minded people will have a go at it and see what problems we introduce with 
it... =)


And again: we need to make sure that libcurl built without coap support is as 
little affected as possible. I'm worried it will be messy.


--

 / daniel.haxx.se
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Re: CoAP support in libcurl for the Internet of Things

[Olaf Bergmann]

Daniel Stenberg  writes:

> On Tue, 8 May 2018, Olaf Bergmann wrote:
>
> I clicked "version 4.1.2" [...]  and landed
> on [a virtually] blank page.

Yes, that's the starting point where I have said that "it has improved
from", and help is underway.

> This makes it tricky for a casual observer such as myself to figure
> out and learn how the API works so that I can get an image how hard it
> would be to incorporate into something like libcurl.

Yes.

>> The current development branch that is intended to become the next
>> major release soon already has a good amount of manual pages that
>> document the API. The web site re-factoring and user guide writing
>> are in progress.
>
> So this new good documentation is not available online yet?

I did not say "good" but improved. The development branch where the next
release is being worked hard on now has good API documentation. It
currently lives here: https://github.com/obgm/libcoap

(There is a technical reason for libcoap.net currently being very
outdated which has been discussed elsewhere.)

>>>  It is also yet another dependency that relies on its own TLS library, which
>>>  seems to mostly be OpenSSL on posix systems.
>>
>> libcoap comes with an interface to enable intergration of different TLS
>> libraries. For now, these are OpenSSL and tinyDTLS, but GnuTLS
>> integration is in development as well.
>
> Cool, but may still offer a challenge for the libcurl build setup.

Yes, I agree. When I did the first PoC, I did not have the TLS code
ready, so I honestly do not know how hard (or easy) this will be.

> Do you run it through coverity or another static analyzer frequently?

Yes, (coverity). That's why it has the badge.

> I think you should consider -Werror on your travis builds and fix
> those build warnings you have.

Fixing them, yes, -Werror, no.

> I would encourage you to do what it takes to get a badge here:
>
>   https://bestpractices.coreinfrastructure.org

Thank you for your kind advice. I think the most important question Remy
wanted to ask is whether or not it would be useful to invest time into
doing whatever it takes to add CoAP support to libcurl. It would be
great if you had advice here as well.

Thanks
Olaf
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Re: CoAP support in libcurl for the Internet of Things

[Daniel Stenberg]

On Tue, 8 May 2018, Olaf Bergmann wrote:


 If I would be negative about something, then it is that libcoap is
 seriously badly documented


Since libcoap has evolved from a low-level implementation for embedded 
developers who really know (and want to know) their code into a package for 
major Linux distributions such as Debian, Ubuntu, Arch, the API as well as 
the documentation have been improved a lot.


Really? I googled "libcoap API". Found https://libcoap.net/documentation.html

I clicked "version 4.1.2" which is the latest I see there and landed on 
https://libcoap.net/doc/reference/4.1.2/index.html


That's virtually a blank page. doxygen generated. I've never seen a library 
with good API docs generated from doxygen.


Ok, go back and click "user guide" instead? That page says "Unfortunately, the 
user guide is not yet ready. There is much to do…"


This makes it tricky for a casual observer such as myself to figure out and 
learn how the API works so that I can get an image how hard it would be to 
incorporate into something like libcurl.


The current development branch that is intended to become the next major 
release soon already has a good amount of manual pages that document the 
API. The web site re-factoring and user guide writing are in progress.


So this new good documentation is not available online yet?


 It is also yet another dependency that relies on its own TLS library, which
 seems to mostly be OpenSSL on posix systems.


libcoap comes with an interface to enable intergration of different TLS
libraries. For now, these are OpenSSL and tinyDTLS, but GnuTLS
integration is in development as well.


Cool, but may still offer a challenge for the libcurl build setup.

Finally, it might be worthwhile pointing out that libcoap currently runs on 
Linux, MacOS, and Windows and has an actively contributing community.


Awesome!

Do you run it through coverity or another static analyzer frequently?

I think you should consider -Werror on your travis builds and fix those build 
warnings you have.


I would encourage you to do what it takes to get a badge here:

  https://bestpractices.coreinfrastructure.org

--

 / daniel.haxx.se---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Re: Old Curl Project

[Daniel Stenberg]

On Thu, 17 May 2018, Don Landsom wrote:

I'm new here and was hoping to learn more about Curl in the attempts to 
breath some life into an old project until it can be brought up to date 
through a complete overhaul.


You're most welcome!

Not looking to take too big of a leap hear as everything is to be replaced 
so I searched to find the closest possible Curl release support SMPT which 
appears to be Curl-7.20.0.


SMTP support was initially added in 7.20.0, yes. But it has also been polished 
and bugfixed over the years so I would not recommend using the first public 
version supporting it. I think it had a few rough edges still for some 
releases.


In general you won't gain much by doing a small upgrade compared to a big 
upgrade. If you instead jump to the head of the line at 7.60.0, you'll get our 
attention and support if you have problems or questions. Not so much for 
7.20.0, which is over 8 years old by now.


The API and behavior *should* still be the same as it was back in the 7.13.0 
days!


Also note that 7.20.0 has a few known security vulnerabilities:

  https://curl.haxx.se/docs/vuln-7.20.0.html

The current application is running VB6 using the dll wrapper VBLibCurl 1.0, 
so the big question is whether this wrapper can be interfaced with 
Curl-7.20.0.


I would imagine that building stuff on such old legacy systems is a pain in 
general.


--

 / daniel.haxx.se
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Old Curl Project

[Don Landsom]

Hello


I'm new here and was hoping to learn more about Curl in the attempts to breath 
some life into an old project until it can be brought up to date through a 
complete overhaul. 

The project manages a web-site through the use of Curl relying heavily on FTP 
along with a number of other protocols. 

A request has been made to include support for SMTP, but unfortunately the 
current build is so old that it's not supported. The system is running Windows 
XP sp3 with Curl-7.13.0 and does the job quite well.

Eventually the entire system will be upgraded with current hardware and 
software, however a short-term patch is being looked at to see if it's possible 
to get support included for SMPT.

Not looking to take too big of a leap hear as everything is to be replaced so I 
searched to find the closest possible Curl release support SMPT which appears 
to be Curl-7.20.0.

The current application is running VB6 using the dll wrapper VBLibCurl 1.0, so 
the big question is whether this wrapper can be interfaced with Curl-7.20.0.

I've tried playing around with things but appear to be causing more harm them 
good, so any help would be greatly appreciated.

Thanks.
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html