Unknown Content-Encoding values cause Client::Get to fail #2518

I ran into this while looking at llama.cpp issue #26400. It seems to come from a change in how cpp-httplib handles unknown Content-Encoding values.

This URL returns a normal JPEG with HTTP 200:

https://help-static-aliyun-doc.aliyuncs.com/file-manage-files/zh-CN/20241022/emyrja/dog_and_girl.jpeg

However, the response also includes:

Content-Encoding: UTF-8

UTF-8 is not an HTTP content coding, so I assume the server intended to describe a character encoding and used the wrong header. In this unexpected situation, older versions of cpp-httplib still returned the raw response body, while current versions return a null Result with:

Failed to read connection

A minimal reproduction is:

#include <iostream>

#define CPPHTTPLIB_OPENSSL_SUPPORT
#include "httplib.h"

int main() {
  httplib::Client cli(
      "https://help-static-aliyun-doc.aliyuncs.com:443");

  auto res = cli.Get(
      "/file-manage-files/zh-CN/20241022/emyrja/dog_and_girl.jpeg");

  if (res) {
    std::cout << res->status << " " << res->body.size() << '\n';
  } else {
    std::cout << httplib::to_string(res.error()) << '\n';
  }
}

I believe this regression was introduced in PR #2281; according to GPT 5.6 Sol (which I had investigate this issue by going back through the commits until it wasn't reproducible), the issue is that before #2281, cpp-httplib only rejected recognized encodings such as gzip when the corresponding decompression support was unavailable. An unknown value fell through and the raw body was returned. After #2281, every nonempty Content-Encoding is passed to create_decompressor. When that returns null, prepare_content_receiver sets status 415 and fails. The caller ultimately sees the more generic Error::Read, so it is not especially clear that the encoding caused the failure.

I think this could be solved by better error handling to make it clear to the caller that this is caused by a bad server response, or making this error more of a warning and still handling the response the way that it was handled before #2281. I think that second option makes more sense.