Rachel Kroll
Hello again from the land of feed reader behavioral tests. I ran through the list of participants a couple of days ago and wrote up my results. This is only for those which had polled at least once in the past seven days relative to that point.
I'm going to group some of these together, but keep in mind that some behaviors are a function of however the user configures the program. Also, at this point I'm mostly focusing on their steady-state behavior, but any previously-reported goofiness at subscribe-time is still worthy of fixing for people so inclined.
Artykul's clown fetcher is still going. They're going to make me write a 404 generator and then a 410 generator, I just know it. Then I'm going to start complaining about them not honoring either of those. All unconditional, every 2-3 hours. Terrible.
feedbase-fetcher.pl/0.5 seems fine.
Broadsheet/0.1 seems fine.
com.vanniktech.rssreader, various versions has weird timing.
NextCloud-News/1.0 - all of these have broken IMS caching. There's a fix that's been submitted but it hasn't been merged, never mind rolled up into a release. Some old versions hammer the favicon.ico needlessly. I can only guess at who's running what, since they don't ever bump their version number. It's been 1.0 forever, and I assume this will continue unabated. This makes it really hard to direct particular version-based brokenness to an appropriate handler.
Some browser extension thing. Seems fine.
Mojolicious (Perl), seems fine.
NetNewsWire with buggy LM/ETag caching, as covered in a post a while back. I don't think this has been changed upstream yet. Also has terrible timing.
newsraft/0.25, which still has buggy ETag caching. It also has terrible timing.
Bloggulus/0.3.7, seems fine.
Miniflux/2.1.4 has buggy Last-Modified caching. Miniflux/2.2.0 does too. I thought it was squared away previously, but it's still doing crazy stuff when I do the pathological test cases to check for bugginess.
FreshRSS/1.24.0 has buggy Last-Modified + ETag caching. But, others running 1.24.2 and 1.24.3 have it fixed! The author actually reached out to let me know about this. Thanks!
Feedly/1.0 which went into a "once per day, always unconditional" thing months ago. Meh.
Reeder, various versions. Has the minor timing issue where sometimes it's 59 minutes, and other times it's an hour, as explained in a prior post. Call it the "cron alone is insufficient limiting for poll scheduling" thing, I guess?
feedparser/6.0.10, running too fast: 29/30 mins.
feedparser/6.0.2, doing the minor 59m/60m timing thing.
Yarr/1.0 with terrible timing.
Another Yarr/1.0 with the 59m/60m thing.
walrss/0.3.7, seems fine.
Emacs Elfeed 3.4.1 with some odd behaviors, like there are multiple instances running that aren't sharing the data on the last-modified/etag headers from the last poll. Another instance is doing the same thing.
er0k/feeds v0.2.0, seems fine.
Rapids, seems fine.
Go-http-client/1.1, seems fine, whatever this really is. Could use a more descriptive UA, if only to not run afoul of filtering (not me, but other places).
theoldreader.com has started doing If-Modified-Since and If-None-Match. This warranted a straight-up "holy shit" from me when I saw it in the list. I have no idea if this project had anything to do with it, and I really don't care. They're doing the right thing now, and that's great.
Tiny Tiny RSS, multiple instances from various users. Not recommended.
rss2email release-3.3.1, which keeps doing unconditional requests seemingly randomly. No idea why.
NewsBlur also randomly does unconditionals: 8 of 526 polls that way for one instance (and other counts for other instances). Also no idea why.
Feedbin, which seems to have fixed its ETag bugginess. Yay?
Inoreader/1.0. It has the 59m/60m thing, and also launches unconditionals roughly daily. Dumb.
Some curl-based thing (maybe even the CLI tool?) that's doing conditional requests nicely. Has the typical (minor) 59m/60m thing.
inforss/2.3.3.0, seems fine.
haven sends 100% unconditional requests. It also happens to have the 59m/60m thing, but the complete lack of conditional requests is the showstopper here.
ureq/2.9.1, seems fine.
Friendica/2024.08, also 100% unconditional requests.
SpaceCowboys Android RSS Reader/2.4.15 occasionally has weird timing, and it just goes unconditional randomly. No idea what's going on here, either. Another one is 2.6.31 and that seems fine, so I suspect there was a bugfix release in the middle.
Netvibes, with super broken LM+ETag caching.
cry-reader v0.0, seems fine.
Another undifferentiated browser extension thing, but this one is 100% unconditional, and wacky timing on top of that.
Blogtrottr/2.0, seems fine.
Unread RSS Reader, which is no longer unloading like mad onto the test server, but it has settled into a 15 minute poll interval. Too fast.
Slackbot/1.0, this is a relatively new one, and it's terrible. It's 100% unconditional polls with awful timing: always less than an hour between checks, sometimes much less. They also inexplicably send HEADs, and receive a 405 error from me, but of course come back and do it again a few minutes later.
The whole point of HEAD is if you want the metadata but have no interest in the content. If you want the content but only want a fresh copy if it's changed, that's why we have conditional requests, and again, If-Modified-Since has been in the RFCs since *1996*.
For sites that build the feed dynamically (i.e., not mine), HEAD represents the same amount of work: they get to build the feed, provide the metadata, and then throw it away.
Unless you actually want the metadata, and never anything BUT the metadata, then fine, send HEADs. Otherwise, forget it existed.
Audrey2 RSS Reader/0.7.1, seems fine.
rss2email/3.14, has the 59m/60m thing going on, otherwise it's fine.
...
I should note that if a feed reader's only problem is the 59:xx vs. 60 minute thing then they're actually doing pretty well. There are a lot of way worse things out there.
I'd love it if they could fix this, obviously, but that's just how I am.