Curl/libcurl with HTTP/2 support

As far as I understand, the default libcurl in OpenWrt is built without the HTTP/2 support which results in some DoH servers not working with https-dns-proxy on OpenWrt.

I don't know wherever it's a curl/libcurl compile-time setting or hard dependency on libwolfssl (even tho libopenssl is installed), the end result is that HTTP/2 is not supported on OpenWrt.

I've had a look at the Makefile but it's too complicated for me to understand/try to fix.

I'm not sure if @Kaloz is still active on the forum/as a package maintainer, but I figured I'd ask here for pointers first before emailing Imre.

How can I get a version of curl/libcurl which would support HTTP/2?

I think you should compile libcurl with HTTP2 support. To do so:
main menuconfig ---> Libraries --> Libcurl (choose the package) ---> choose "HTTP2 protocol". Build openwrt.


You are looking at the wrong file.

the makefile shows this

define Package/libcurl/config
  source "$(SOURCE)/"

which means that some libcurl compile options are set by a file in the same folder as the Makefile, this

look what we have there

	bool "HTTP2 protocol"
	default n

the HTTP2 protocol is disabled by default.

the options in this file can be modified for your local build in the make-menuconfig interface (as said by the other person).

If your packages need this feature it is probably a good idea to send a PR to flip this switch by default

1 Like

Thanks! But that would bring (or it should then bring, as curl won't work without) the libnghttp which is a 67Kb library compared to 168Kb for libcurl itself.

Do you have an idea how to create a variant (libcurl-http2 for the new library or libcurl-http1 for the old one) so that there's an option of using curl without HTTP/2 on space-constrained devices?

yeah it's better to make a variant, 70kb addition can upset a lot of current users that don't need that.

I have never done this, but I would look at the openvpn makefile/structure to learn how to do this.

as that's a package that uses the external config file and has multiple versions in the same makefile.

1 Like

Thanks again, I've created PR for the change (, that would hopefully get the ball rolling in the correct direction, even if that'd require a variant.

@bobafetthotmail dude, you should totally check that PR link, you started it. :wink:

nah they are bickering about project politics and stuff, let's see if I can steer that back to something more productive

EDIT: sorry for siding with the people that want you to do more work lol. Imho dangowrt's argument on "making a variant is too hard" is invalid because he is assuming the two variants should be compatible with each other, and this is not a requirement here (as one lib is actually a superset of the other, you can just replace the smaller one with the bigger one and still have 100% the same functionality of the smaller one)

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.