Summarizing the last 45 days of feed reader behaviors
In mid-January, I made an announcement that the feedscore system would be resetting the logs for a fresh start, and was bumping the URL along to cast off forgotten readers. This had the desired effect of focusing on those people who are actively involved and let the others start getting DNS failures without bothering my servers. Win-win!
Anyway, this means we now have about 45 days of data to look at, and it's possible to build a report based on the latest observed behaviors.
The usual caveats apply: if one reader instance is being odd, that might be one user smacking the refresh button over and over and/or using terrible settings. If multiple instances of the same program are behaving the same way, it's probably the program itself.
Let's start with the ones that seem to have their conditional request situations figured out. This is clearly the biggest part of the list, and it's great to see things lining up like this.
First up, there's one that's not published yet, and they're doing fine. I hope their efforts are paying off and they have a successful launch when they are ready.
There are a bunch of newer Minifluxes doing their thing, with no problems to report. It seems rather popular.
One of the Miniflux users has a different reader program using the same key and it's screwing up the reporting. You should retire that key and get two more from me. This advice goes for anyone: don't point more than one instance at any given key. It renders the data unusable.
There are several NetNewsWire instances doing their thing with no trouble. I haven't been able to trip them up with pathological (and yet totally valid) bumps of the Last-Modified and ETag values yet. This is good! Some of them have bizarre polling intervals... guessing that's user-driven?
There are a couple of SpaceCowboys Android RSS reader instances which seem to be doing fine. One of them has a bunch of oddly-timed unconditional requests which I assume is the user smacking that refresh button. Smack that button with care!
A couple of Vienna instances are doing fine.
Audrey2 RSS reader is fine.
A couple of Emacs Elfeed instances are fine.
"unnamed-feed-reader" (yes, really, that's what it sends) is doing fine.
There's something which doesn't send a User-Agent at all (okay...), and it has some bizarre anomaly of sending a "" INM at startup, but then has been behaving. (Hint: just drop the header if you don't have a value for it!)
Someone put a lot of work into making a curl instance do the right thing, and it's running great.
Roy and Rianne's Righteously Royalty-free RSS Reader is fine.
github.com/er0k/feeds is fine.
walrss is fine.
feedmail.org/0 is fine.
MANOS is fine. (Is that the feed reader of fate?)
Bloggulus is fine.
There's some unidentified browser extension that's doing fine.
feedbase-fetcher is doing fine.
inforss is doing fine.
feedparser/6.0.2 is *so close*. It just needs the 59/60 minute timing adjustment thing (assuming it's going for 1 poll per hour).
...
There are a few which are still "double-tapping" the server when the feed is first added. This would trip a 429 on the real feed and generally indicates a problem with the data model. Another reason for the URL change for this project was to get readers to run their "new feed" flow again.
Two Feedbin instances did this same thing when they were added.
Yarr/1.0 did a second poll about 300 milliseconds later, and a third poll another 27 seconds after that. This is the wrong way to do things. The other timing also seems to not follow any real pattern.
...
Now let's talk about readers with some cache bugginess:
A couple of Newsboat instances still can be tripped up and will keep sending old values in their If-None-Match headers.
There's a BazQux instance which has the same INM bugginess. I wonder if they're using the same library for their HTTP comms.
...
Then there are some weird ones:
rss2email randomly goes unconditional at times. No idea why.
NextCloud-News/25.x.x still sent at least one 1800 IMS. I don't get this. If you weren't sent a value, don't return it in a header. On a positive note, it's no longer beating the hell out of the server trying to get a favicon this week (which isn't in the reports, but I can see it on my side).
...
Finally, everything else:
Something claims to be a browser (Chrome 77? Sure...) and sends 100% unconditionals. This is bad. It also sends HEAD requests which aren't visible in the report, but I can see them, and they're broken and pointless.
One key either has two separate Thunderbird instances banging away (bad! get separate keys!) or has one terrible implementation that always polls twice. Either way, it's not usable data.
There are also two FreshRSS instances which are both sending 100% unconditionals. What happened here? Over and over, it's just this sort of request:
Host: <redacted> User-Agent: FreshRSS/1.26.1-dev (Linux; https://freshrss.org) Accept: */* Accept-Encoding: deflate, gzip, br, zstd
I just don't understand.