curl / Mailing Lists / curl-library / Single Mail
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: CURLOPT_ACCEPT_ENCODING not working (help)

From: Ray Satiro via curl-library <curl-library_at_cool.haxx.se>
Date: Fri, 5 Feb 2021 15:48:22 -0500

On 2/4/2021 10:07 AM, Adrián Gimeno Balaguer via curl-library wrote:
>
> I’m using a self built libcurl shared library for embedded use in a
> C++ application. In the attempt of requesting it to automatically
> decompress response data from a remote server of interest by using a
> line like the following in my request setup:
>
> curl_easy_setopt(mpCURL, CURLOPT_ACCEPT_ENCODING, "gzip");
>
> The returned data seems to remain compressed. I enabled the
> CURLOPT_HEADER option and can see that the server returns positive
> Content-Lengths, with few non-human readable characters in the body
> content. To be clear, removing the CURLOPT_ACCEPT_ENCODING option
> doesn’t make any difference.
>
> The libcurl library compilation is done in a custom automated CI/CD in
> the cloud which also compiles OpenSSL and ZLib as shared libraries in
> separate pipelines, with libcurl pipeline pulling from the master
> branch (from official libcurl’s repo) and a compilation script like
> the following:
>
> cmake -Bbuild -DBUILD_SHARED_LIBS=OFF -DCMAKE_BUILD_TYPE=MinSizeRel
> -DCMAKE_POSITION_INDEPENDENT_CODE=ON -DCURL_DISABLE_COOKIES=ON
> -DCURL_DISABLE_CRYPTO_AUTH=ON -DCURL_DISABLE_LDAP=ON
> -DCURL_DISABLE_PROXY=ON -DENABLE_IPV6=OFF -DENABLE_UNIX_SOCKETS=OFF
> -DHTTP_ONLY=ON
> -DOPENSSL_CRYPTO_LIBRARY=$(Pipeline.Workspace)/ssl/lib/libcrypto.so.1.1
> -DOPENSSL_INCLUDE_DIR=$(Pipeline.Workspace)/ssl/include
> -DOPENSSL_SSL_LIBRARY=$(Pipeline.Workspace)/ssl/lib/libssl.so.1.1
> -DZLIB_INCLUDE_DIR=$(Pipeline.Workspace)/zlib/include
> -DZLIB_LIBRARY=$(Pipeline.Workspace)/zlib/lib/libz.so.1 . && cmake
> --build build
>
> I can see the following possible relevant build output lines (not
> contiguous) that may indicate ZLib gets correctly integrated:
>
> Found ZLIB: /home/vsts/work/1/zlib/lib/libz.so.1 (found version "1.2.11")
>
> Enabled features: SSL libz AsynchDNS alt-svc HTTPS-proxy
>
> However, I’ve seen in the following answer:
> https://stackoverflow.com/a/29966893
> <https://stackoverflow.com/a/29966893>. Looking at my generated
> libcurl headers, I can’t find any match for “HAVE_LIBZ” (neither in my
> build output).
>

The proper way to specify OpenSSL and zlib locations is by using
OPENSSL_ROOT_DIR [1] and ZLIB_ROOT variables [2], because we call
cmake's find_package and that's what they use. For example:

-DCMAKE_USE_OPENSSL=ON -DOPENSSL_ROOT_DIR=C:\somewhere -DCURL_ZLIB=ON
-DZLIB_ROOT=C:\somewhere

This assumes you've already installed openssl and zlib to those
locations and they have lib,bin,etc. To set the install location when
configuring zlib via cmake you can use -DCMAKE_INSTALL_PREFIX:PATH=. To
set the install location when configuring openssl via Configure you can
use --prefix= and --openssldir=.

Setting ACCEPT_ENCODING to a specific string is almost never used
correctly. What you should do instead is set it to an empty string ""
and libcurl will only send the encodings it actually supports [3].

printf("%s\n", curl_version()) to make sure your program is actually
using the libcurl you built and not some other one in the path.

[1]: https://github.com/Kitware/CMake/blob/master/Modules/FindOpenSSL.cmake
[2]: https://github.com/Kitware/CMake/blob/master/Modules/FindZLIB.cmake
[3]: https://curl.se/libcurl/c/CURLOPT_ACCEPT_ENCODING.html



-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2021-02-05