Open ehamberg opened 3 months ago
Sounds about right, open rsss talks about issue too in https://openrss.org/issue/54
We already have a bug about OpenRSS and rate limiting: https://github.com/Ranchero-Software/NetNewsWire/issues/4224
And I’m not too concerned about the timing issues in Rachel’s report — you can do a manual refresh any time you want in NetNewsWire, and that will result in a new request. So any crazy timing is just that.
But the conditional GET bugs are concerning. Here’s the actual report: https://rachelbythebay.com/api/fsr/4467c09c31370b8375c6b2a320aa77cd5d999cd4
(I had the test feed running on my personal laptop, and it reflects my use. You can even see when I went on a long vacation and left the laptop at home.)
I’ve identified one issue — I don’t know if it’s the only one or not. Here’s the scoop:
If the server returns a raw feed that is unchanged from the previous request, we ignore any updated Last-Modified or Etag headers. We make the assumption that those headers would not have changed if the raw feed hasn’t changed. This is surely true almost all the time in the real world!
There may be other issues too, of course, and it’s possible my theory isn’t the cause of the issues here. But it’s still a thing to fix.
I’ve asked Rachel to add a column for http response code — I have a suspicion that this might tell me more. Fingers crossed that the data is available and added to the report.
Follow-up: I asked Rachel about the http response codes for the test feed — it’s always 200.
Blogged about this: https://inessential.com/2024/08/03/netnewswire_and_conditional_get_issues.html
Not any specifics, unfortunately, but from http://rachelbythebay.com/w/2024/08/02/fs/ it sounds like NetNewsWire (or its HTTP library, I guess) is not doing conditional HTTP requests correctly: