Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feed Reader Scorer #2675

Open
1 task done
psa opened this issue May 31, 2024 · 3 comments
Open
1 task done

Feed Reader Scorer #2675

psa opened this issue May 31, 2024 · 3 comments

Comments

@psa
Copy link

psa commented May 31, 2024

A feed reader verifier is being turned up and it seemed like something you might like to point miniflux at for external verification. Mentioning here in case you weren't yet aware.

Posts about the service spin up:

If you want to see how miniflux fares from a feed server perspective, you can contact Rachel to set it up via: https://rachelbythebay.com/contact/

@setupminimal
Copy link

As I happens, I wrote to Rachel asking whether any Miniflux instances had been tested. She said that they were all behaving well, except for the first bug described here: https://rachelbythebay.com/w/2024/06/11/fsr/

Bug: It's entirely possible for a feed's Last-Modified value (seconds) to remain the same while the ETag (length + microseconds on stock Apache) changes. More than a few feed readers assume if they get the same value for Last-Modified, then they don't have to update the cached ETag value. This causes them to effectively make unconditional requests until the feed changes again. Watch out for shortcut evaluations in your caching code!

... which I hope won't be too difficult to fix. I will look into putting a PR together when I get some spare time, but that might not be for a while.

@jvoisin
Copy link
Contributor

jvoisin commented Jun 16, 2024

Uhuh, I also sent her an email, and got a similar reply:

Miniflux is so close. It just has this one bug that I've seen in a few readers - if the Last-Modified header doesn't change, then it doesn't pick up the change in the ETag header. It'll keep sending the old value in If-None-Match and that makes for an unconditional request.

I should have looked at the bugtracker first.

@jvoisin
Copy link
Contributor

jvoisin commented Jun 16, 2024

It seems that this behaviour is on purpose though:

// We update caching headers only if the feed has been modified,
// because some websites don't return the same headers when replying with a 304.
originalFeed.EtagHeader = responseHandler.ETag()
originalFeed.LastModifiedHeader = responseHandler.LastModified()

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

3 participants