Describe the bug

I recently switched to FreshRSS and found one of my feeds not working. It returned the following error in the logs:

A feed could not be found at `https://blog.example.com/index.xml`; the status code is `200` and content-type is `` [https://blog.example.com/index.xml]

After googling a bit, I came across the advise to try adding #force_feed to the end of the feed URL. This lead to the following error message:

A feed could not be found at `https://blog.example.com/index.xml`. Empty body. [https://blog.example.com/index.xml#force_feed]

Fetching the index.xml manually via cURL worked and returned the expected result. But it had this header set:

Content-Encoding: aws-chunked

This seems to be an issue of how Ceph S3 works with Hugo's deploy functionality, so it will be fixed in the blog's setup.

But because the W3C Feed Validator thought the feed was fine, I decided to dig a bit further, and I believe I found a bug in FreshRSS. I added a number of debug prints throughout the code in the 1.28.0 version and ended up here:

When outputting $file->get_body_content(), it is entirely empty. At the same time, the $file->get_status_code is still 200. This then leads to the rest of the function to be executed, trying to find a feed, but not being able to.

I then dug a bit into the actual fetching code, and finally found the issue here:

Outputting the curl error:

cURL error 61: Unrecognized content encoding type. libcurl understands deflate, gzip, br, zstd content encodings

And the responseHeaders:

HTTP/2 200 \r\naccept-ranges: bytes\r\ncontent-encoding: aws-chunked\r\ncontent-type: application/rss+xml\r\ndate: Tue, 30 Dec 2025 22:50:37 GMT\r\netag: "xxxxx"\r\nlast-modified: Sat, 13 Dec 2025 21:23:42 GMT\r\nserver: Ceph Object Gateway (squid)\r\nx-amz-meta-md5chksum: yyyyy\r\ncontent-length: 11242\r\n\r\n\r\n

Meaning the error does make sense. Looking further, I found that the CURLOPT_ENCODING option is deprecated, and setting it to none likely doesn't have any effect anymore. As a consequence, the retry of the fetch in line 152 also fails. This failure then seems to be uncaught, and execution continues as if the fetch succeeded, but the body is left empty.

See the deprecation info in the PHP docs. The replacement seems to be the CURLOPT_ACCEPT_ENCODING option.

I was able to fix the issue by changing line 150 to this:

curl_setopt($fp, CURLOPT_ACCEPT_ENCODING, null);

Then, using the original feed worked. But it still needed the #force_feed appended, otherwise no articles are loaded, likely due to the same content-encoding issue.

To Reproduce

1. Go to a page which sends a content-encoding: aws-chunked header for its feed file
2. Try to add that file as a feed in FreshRSS, either with or without #force_feed appended
3. Observe that FreshRSS says there's no feed to be found
4. Check the W3C feed validator to see that it thinks the feed is perfectly fine

Expected behavior

The feed is correctly fetched and added to FreshRSS.

FreshRSS version

1.28.0

System information

• Database version: SQLite
• PHP version: From Docker container for v1.28.0
• Installation type: Docker
• Web server type: Apache from Docker container, fronted by Traefik as a proxy
• Device: Desktop
• OS: Gentoo Linux
• Browser: Firefox 146.0

Additional context

No response