Bugs, bugs, bugs!
Look out, I'm talking about feed stuff again.
Since last week's post with the latest report on feed reader behaviors, a fair number of things have happened.
First up, I reported that two FreshRSS instances were sending unconditional requests. This turned out to be a pair of interacting bugs, and the developers hopped right on that and stamped it out. Their dev instances shifted right away. That's great.
Then, something funny happened. I wrote that post about the modem noises and it included a MP3 file. The way I do this in my stuff here is that I have some commands baked into my page generator that knows how to create the <audio> container and then put one or more <source> elements into it. So, I did that for the (admittedly crappy) recording and shipped it off.
I didn't know this at the time, but this immediately triggered strange behavior in a number of feed readers, FreshRSS included. They all started sending the wrong data. That is, they'd get the latest version of the feed with the "2025/03/05/1670" post in it, but on their next poll they'd still be sending the If-Modified-Since and/or If-None-Match values from the previous version.
This sent me down the road of trying to flush out this behavior on the feed score project side of things, but nothing I did would reproduce it. Again, I didn't know that something about that specific post was responsible, so I was groping around in the dark.
Finally, I reported this to the FreshRSS devs, and they came right back and showed me my problem: my feed says it's xhtml, but it was doing something that's not valid: <audio controls>. That's not valid XML, so it's not valid XHTML by extension. It's just fine in a regular web page, naturally.
I hate the web.
How did this happen? Easy: In 2023, I rewrote my generator for these web pages and the feeds. There's now a bunch of code that *tries* to crap out reasonable (and validating) results instead of doing "HTML by printf" like it had been before.
Along the way, I obviously didn't internalize the rule that "in XHTML, attribute minimization is forbidden". It sounds like the kind of thing I would have read once back in the 90s when I was trying to get pages to validate as XHTML 1.0 for some cursed reason, and then promptly forgot. So, it would do a bare "controls" attribute and thought it was fine.
In practical terms, it means you can't do this:
<audio controls loop>
But instead you have to do this:
<audio controls="controls" loop="loop">
So yeah, I wrote something terrible. Again, I hate the web.
Anyway, what was happening is that a single post within the feed was failing validation as a self-proclaimed xhtml document, so the feed readers were rejecting the _entire poll_ and were not updating their caches. The next time they polled, it was as if they had never sent the request in the first place (as far as they were concerned).
Once I shipped a fixed version of the feeds, they went back to normal.
I'd snark about something here, but clearly, I'm no better at this.
What's different now? Well, my bits of code which are responsible for attributes ("controls", "loop", "href", ...) now refuse to generate a minimized attribute when being used for XML, and that includes the feed stuff. They'll blow up before they ship garbage like that again.
My thanks to the FreshRSS team for being responsive and helping me out.
Now, where did I put my clown nose...