Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: Recommended way of using a custom build of libcurl in a Node.js addon
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Darshan Sen via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 22 Mar 2023 18:35:05 +0530
To be clear, I work at Postman and I was experimenting on adding support
for sending HTTP3 requests to the Postman app. For a network debugging tool
like Postman, I guess it makes sense to give our users full capability of
sending any kind of network requests they would prefer, including fully
experimental HTTP3 requests. I think the same thing applies for HTTP2
requests as well. Since libcurl supports both (well, experimental support
for HTTP3) and also allows using OpenSSL, I thought that libcurl would be
the right option.
Since we also allow folks to download the application zip from the website
and run it on their systems, I guess bundling libcurl along with its
dependencies (I guess at least the ones that are not usually present on the
systems of most users) would be a hard requirement.
I don't know if there are any other ways of bundling libcurl and its
dependencies along with the binding other than the 2 options I mentioned.
If there aren't, I was wondering which one of the two - fully static
library / fully relocatable dynamic library would be the most sensible
approach here. Are any of the two approaches officially supported for
libcurl built from source? If not officially supported, are there any
projects that have found ways to bundle libcurl along with its dependencies?
On Tue, Mar 21, 2023 at 10:07 PM Timothe Litt <litt_at_acm.org> wrote:
> HTTP/3 is experimental. Do you want your non-technical users to rely on
> an experimental implementation?
>
> Do you have http/3 -only servers that your addon must communicate with?
> (That would be unusual.)
>
> Unless that's the case, in the situation you describe, I'd wait for http/3
> to be in the standard, packaged builds.
>
> Daniel probably has current statistics, but last I knew sites that support
> http/3 only were rare. And something like 75% of web browsers support
> http3 - so any http3-only site is unable to communicate with 25% of
> browsers.
>
> https://w3techs.com/technologies/details/ce-http3 indicates that only 25%
> of websites support http3. In fact, only about 40% support http/2...
> https://w3techs.com/technologies/comparison/ce-http2,ce-http3
>
> http/3 has some performance advantages, but for a well-designed website
> with a typical load they aren't huge. I don't think apache httpd has
> support for it yet - and it still has about 1/3 of the webserver
> deployments. (Tied with nginx).
>
> But you can certainly go ahead with your plans. I'm just sharing one
> perspective.
>
> Timothe Litt
> ACM Distinguished Engineer
> --------------------------
> This communication may not represent the ACM or my employer's views,
> if any, on the matters discussed.
>
> On 21-Mar-23 10:36, Darshan Sen wrote:
>
> The primary reason why I thought that the deps should be bundled with the
> addon is that the application that would be using the addon needs libcurl
> with HTTP3 support through OpenSSL. The only option I found is to use the
> first one from https://curl.se/docs/http3.html - the ngtcp2 version which
> uses the quictls fork of OpenSSL. I tried but I wasn't able to find a way
> in which libcurl with HTTP3 support from quictls can be used on macOS,
> Windows and Linux without building curl from source and my users lack the
> technical skills required to build curl from source. That's why, I created
> this thread to learn about solutions for this problem that I'm trying to
> solve and find out which one is the most reasonable to use here.
>
> On Tue, Mar 21, 2023 at 5:18 PM Timothe Litt via curl-library <
> curl-library_at_lists.haxx.se> wrote:
>
>>
>> On 21-Mar-23 04:34, Darshan Sen via curl-library wrote:
>>
>> Hi! I'd like to incorporate a custom build of libcurl (with HTTP3
>> support) into a Node.js C++ addon <https://nodejs.org/api/addons.html>
>> that is going to be shipped to some systems that don't have curl or its
>> dependencies installed.
>> From what I can tell, the possible ways in which this can be done are -
>>
>> - build a fully relocatable version of libcurl and the dependency
>> libraries
>> - statically compile libcurl into my application
>>
>> I'm not sure if there are any better solutions to this. What is the
>> recommended way of doing this?
>>
>> It depends. So you'll probably get several answers.
>>
>> If you take either of the choices you suggest, you also take on the
>> maintenance task for libcurl and the libraries it depends on. That means
>> you'll have to update your addon whenever they have an issue that affects
>> your addon - including security issues.
>>
>> The more components you ship, the greater the work you take on. And a
>> normal build of libcurl has quite a few dependencies. I only build a
>> subset, but a quick ldd on libcurl.so lists 26. (Of course, some will be
>> installed on most any system.) There is no unified schedule for their
>> releases, so across all the libraries, you may see an issue every week.
>> But the advantage is that your customers have a simple install, and only
>> one vendor (you) to deal with.
>>
>> The alternative is to simply state that libcurl (and thus its
>> dependencies) is a dependency of your addon, and require that it's
>> installed. If you are distributing your addon via a package manager, this
>> is pretty simple - you specify libcurl and it's minimum version, and the
>> rest is handled automatically. The distributions enforce a release
>> schedule for the other libraries that consolidates the library updates.
>> The downside is you don't control the exact configuration of libcurl, and
>> your addon will probably encounter more versions of libcurl than if you
>> packaged it. libcurl has a stable API, but if you accidentally (or
>> intentionally) rely on undocumented behaviors, this could be an issue.
>>
>> Unless you have the resources to devote to supporting a private
>> distribution of libcurl et. al. for your customers, I'd simply make libcurl
>> a dependency. It's less work for you, and consistent with the way most
>> distributions work.
>>
>> I'd have to see a very compelling use case to invest resources in a
>> private distribution. While it may seem simpler now, the long-term costs
>> tend to become large.
>>
>> You'll have to decide what's best for you and your customers.
>>
>> Timothe Litt
>> ACM Distinguished Engineer
>> --------------------------
>> This communication may not represent the ACM or my employer's views,
>> if any, on the matters discussed.
>>
>> --
>> Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
>> Etiquette: https://curl.se/mail/etiquette.html
>>
>
Date: Wed, 22 Mar 2023 18:35:05 +0530
To be clear, I work at Postman and I was experimenting on adding support
for sending HTTP3 requests to the Postman app. For a network debugging tool
like Postman, I guess it makes sense to give our users full capability of
sending any kind of network requests they would prefer, including fully
experimental HTTP3 requests. I think the same thing applies for HTTP2
requests as well. Since libcurl supports both (well, experimental support
for HTTP3) and also allows using OpenSSL, I thought that libcurl would be
the right option.
Since we also allow folks to download the application zip from the website
and run it on their systems, I guess bundling libcurl along with its
dependencies (I guess at least the ones that are not usually present on the
systems of most users) would be a hard requirement.
I don't know if there are any other ways of bundling libcurl and its
dependencies along with the binding other than the 2 options I mentioned.
If there aren't, I was wondering which one of the two - fully static
library / fully relocatable dynamic library would be the most sensible
approach here. Are any of the two approaches officially supported for
libcurl built from source? If not officially supported, are there any
projects that have found ways to bundle libcurl along with its dependencies?
On Tue, Mar 21, 2023 at 10:07 PM Timothe Litt <litt_at_acm.org> wrote:
> HTTP/3 is experimental. Do you want your non-technical users to rely on
> an experimental implementation?
>
> Do you have http/3 -only servers that your addon must communicate with?
> (That would be unusual.)
>
> Unless that's the case, in the situation you describe, I'd wait for http/3
> to be in the standard, packaged builds.
>
> Daniel probably has current statistics, but last I knew sites that support
> http/3 only were rare. And something like 75% of web browsers support
> http3 - so any http3-only site is unable to communicate with 25% of
> browsers.
>
> https://w3techs.com/technologies/details/ce-http3 indicates that only 25%
> of websites support http3. In fact, only about 40% support http/2...
> https://w3techs.com/technologies/comparison/ce-http2,ce-http3
>
> http/3 has some performance advantages, but for a well-designed website
> with a typical load they aren't huge. I don't think apache httpd has
> support for it yet - and it still has about 1/3 of the webserver
> deployments. (Tied with nginx).
>
> But you can certainly go ahead with your plans. I'm just sharing one
> perspective.
>
> Timothe Litt
> ACM Distinguished Engineer
> --------------------------
> This communication may not represent the ACM or my employer's views,
> if any, on the matters discussed.
>
> On 21-Mar-23 10:36, Darshan Sen wrote:
>
> The primary reason why I thought that the deps should be bundled with the
> addon is that the application that would be using the addon needs libcurl
> with HTTP3 support through OpenSSL. The only option I found is to use the
> first one from https://curl.se/docs/http3.html - the ngtcp2 version which
> uses the quictls fork of OpenSSL. I tried but I wasn't able to find a way
> in which libcurl with HTTP3 support from quictls can be used on macOS,
> Windows and Linux without building curl from source and my users lack the
> technical skills required to build curl from source. That's why, I created
> this thread to learn about solutions for this problem that I'm trying to
> solve and find out which one is the most reasonable to use here.
>
> On Tue, Mar 21, 2023 at 5:18 PM Timothe Litt via curl-library <
> curl-library_at_lists.haxx.se> wrote:
>
>>
>> On 21-Mar-23 04:34, Darshan Sen via curl-library wrote:
>>
>> Hi! I'd like to incorporate a custom build of libcurl (with HTTP3
>> support) into a Node.js C++ addon <https://nodejs.org/api/addons.html>
>> that is going to be shipped to some systems that don't have curl or its
>> dependencies installed.
>> From what I can tell, the possible ways in which this can be done are -
>>
>> - build a fully relocatable version of libcurl and the dependency
>> libraries
>> - statically compile libcurl into my application
>>
>> I'm not sure if there are any better solutions to this. What is the
>> recommended way of doing this?
>>
>> It depends. So you'll probably get several answers.
>>
>> If you take either of the choices you suggest, you also take on the
>> maintenance task for libcurl and the libraries it depends on. That means
>> you'll have to update your addon whenever they have an issue that affects
>> your addon - including security issues.
>>
>> The more components you ship, the greater the work you take on. And a
>> normal build of libcurl has quite a few dependencies. I only build a
>> subset, but a quick ldd on libcurl.so lists 26. (Of course, some will be
>> installed on most any system.) There is no unified schedule for their
>> releases, so across all the libraries, you may see an issue every week.
>> But the advantage is that your customers have a simple install, and only
>> one vendor (you) to deal with.
>>
>> The alternative is to simply state that libcurl (and thus its
>> dependencies) is a dependency of your addon, and require that it's
>> installed. If you are distributing your addon via a package manager, this
>> is pretty simple - you specify libcurl and it's minimum version, and the
>> rest is handled automatically. The distributions enforce a release
>> schedule for the other libraries that consolidates the library updates.
>> The downside is you don't control the exact configuration of libcurl, and
>> your addon will probably encounter more versions of libcurl than if you
>> packaged it. libcurl has a stable API, but if you accidentally (or
>> intentionally) rely on undocumented behaviors, this could be an issue.
>>
>> Unless you have the resources to devote to supporting a private
>> distribution of libcurl et. al. for your customers, I'd simply make libcurl
>> a dependency. It's less work for you, and consistent with the way most
>> distributions work.
>>
>> I'd have to see a very compelling use case to invest resources in a
>> private distribution. While it may seem simpler now, the long-term costs
>> tend to become large.
>>
>> You'll have to decide what's best for you and your customers.
>>
>> Timothe Litt
>> ACM Distinguished Engineer
>> --------------------------
>> This communication may not represent the ACM or my employer's views,
>> if any, on the matters discussed.
>>
>> --
>> Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
>> Etiquette: https://curl.se/mail/etiquette.html
>>
>
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-03-22