[BUG]: The ETag header is ignored if it's all lowercase

[guihkx]

Brief description of the issue

Version 4.5.2 introduced support for caching through ETag/If-None-Match headers, when supported by the server.

However, if the server responds with that header in any other form than ETag (e.g. etag, Etag, eTaG), RSS Guard won't save it.

For example, this feed (which is 2 MiB) responds with etag, and so RSS Guard ignores it:

$ curl -I https://thisweek.gnome.org/index.xml
HTTP/2 200 
server: nginx/1.25.3
content-type: text/xml; charset=utf-8
cache-control: max-age=600, private
etag: "b02ff10da71968c5c347ef93853ef1ca07bbbafca26e1db7753dcba6613b9388"
...

As you might know, HTTP header fields are case-insensitive.

How to reproduce the bug?

1. Add this feed which responds with an etag header: https://thisweek.gnome.org/index.xml
2. Fetch that feed twice
3. Observe the log output from RSS Guard

What was the expected result?

When the ETag header is used by RSS Guard, a message similar to this one shows up in the logs:

time="  1406.163" type="debug" -> Using ETag value: '"xxxxxxxxxx"'.

What actually happened?

The Using ETag value: ... message doesn't show up in logs after that second feed refresh.

Debug log

log.txt (it was too large to fit directly in here)

Operating system and version

• OS: Arch Linux
• RSS Guard version: master (4cd363e)

[martinrotter]

FIxed hopefully, re-test and let know result please.

[guihkx]

Confirming fixed, thanks!

time="    35.521" type="debug" -> core: Downloading URL 'https://thisweek.gnome.org/index.xml' to obtain feed data.
time="    35.521" type="debug" -> Using ETag value: '"c8ec4932421ffe7f0bf6994837a53762a9c85f37c73c575ddaf7774d2c390617"'.

$ curl -sI https://thisweek.gnome.org/index.xml | grep -i etag
etag: "c8ec4932421ffe7f0bf6994837a53762a9c85f37c73c575ddaf7774d2c390617"

[God-damnit-all]

The fix for this issue (eb6332c) is unfortunately causing some weirdness where certain pages fail to be retrieved. For some reason, going into the properties and doing 'Fetch metadata' fixes it for a bit, but it breaks again later.

https://sk-data.special-k.info/repository.json is one such page. Not really sure what's going on.