This objection might make more sense if the purpose of a feed reader was to do nothing except check rachelbythebay.com for updates.
Looking at my access logs, some RSS readers are well-behaved and get served 304s. Some of them however not only request feed.xml without caching, but they don't even set the HTTP header "Accept-Encoding: gzip". They download feed.xml every time and they download it uncompressed.
I'm hosting my blog on a feeble 5-year old Synology NAS located in my apartment. It's not seeing a lot of traffic so it's currently not a problem, but these RSS readers are wasting several orders of magnitude more of network bandwidth and CPU resources (gotta encrypt it for HTTPS) on my end than well-behaved RSS readers.
It's just plain embarrassing.
There are surely a lot of badly behaved clients out there and I sympathize with that, but the author's policies seem rather heavy handed and counterproductive to providing an open feed. God forbid their most dedicated readers receive the most timely updates.
Given the update frequency and kind of content it does not seem much of an issue does it?
> the author's policies seem rather heavy handed and counterproductive to providing an open feed
It’s not though? “Open feed” is just that, it’s not a license to be a resource hog because you refuse to be a good citizen.
> God forbid their most dedicated readers receive the most timely updates.
Rachel does not post day to day life updates. “Most timely updates” is not a thing, it’s not a storm reporting feed. Latency is not a concern.
You are free to not serve such requests, but as a blogger you might want to consider that such bot traffic serves your legitimate readers. It appears to me that the author is also rate limiting well behaved clients that are already trying to be respectful of resources using conditional requests.
Why install a lecture in the feed reader? Just have a banner/toast/status-bar-message/whatever that says "This feed will update in X minutes/hours/days.".
If you're going to show that message, why are you a feed reader at all? Open the webpage and show the content.
GP seemed fixated on showing a lecture, which I thought was strictly worse than just showing a short message.
> If you're going to show that message, why are you a feed reader at all?
What? The feed readers I used showed status messages. Status messages are nice, they give the operator a fighting chance to understand what's going on and fix things if they've gone wrong.
Which resources are you "hogging" by reloading a webpage twice?
My guess: No `Cache-Control` response header.
checks
Yup, no `Cache-Control` response header. So she doesn't want more than one request per day, but also doesn't want to add this header to the responses:
Cache-Control: public, max-age=86400, stale-if-error=86400I think it's both parties' responsibility. Well, "responsibility" may be a strong word, but it depends what you want to achieve.
It's okay to return 429 if you receive more than one request per day. But if the goal is to not get those requests in the first place, you can make it way easier with that Cache-Control header.
A client might not support the Retry-After header; after all, it's not widely supported by web browsers, so I can see how some libraries might not even bother with adding that maintenance burden.
But Cache-Control is more widely supported, so it's more likely to be already implemented in client libraries (or even caching proxies).
If someone doesn't support Retry-After, and also ignores Cache-Control, by all means, return an error. It's probably a misconfiguration of their client library at best, or a broken client at worst.
I'm not saying one should bend backwards and put unrealistic effort into stuff like this; what I'm saying is, if the HTTP 429 thingy was an acceptable amount of effort, then the Cache-Control thing should be similar (actually way less) effort and time and should slightly reduce the amount of requests received.
It can certainly guess, based on that retry-after header, that she doesn't post more than once a day, and should respect that.
If I have 500 feeds in my reader, most of whom update weekly at most, I would assume the reader does something smarter that mindlessly launch 500 requests every 5 minutes.
Aside from respecting any 429 headers, what is a reader supposed to do without custom update heuristics for each feed that would be considered more than mindless?
I would highly recommend she sets `Cache-Control: max-age=3600` or something similar. That is at least a method that can automatically be applied. Sure, right now most readers just use fixed intervals, but further support for this is a standard that can be pushed slowly. Plus some readers probably use HTTP libraries that would automatically cache the response so some clients will accidentally have support.