Hacker News new | ask | show | jobs
by JustARandomGuy 687 days ago
Unread RSS Reader. Godawful poll timing. 6103 requests in 52 days is about one poll every 736 seconds _on average_, but they're hugely spread out. WTF? Put it this way: the list of unique intervals (nn seconds, nn minutes, ...) is four pages tall on my web browser.

Not entirely sure what the criticism here is other than polling on average every 12 minutes seems a little excessive at best. Why does in matter it the intervals are a bit wonky? I could think of many reasons why: maybe the poll intervals are smaller during the daytime and more spread out over the night to optimize for reading conditions, etc

1 comments

Last time I checked, she wasn't including `Cache-Control` header in the responses. That means a well-behaved client would be doing heuristic caching.

Quoting from https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#de...

> As mentioned above, the default behavior for caching (that is, for a response without Cache-Control) is not simply "don't cache" but implicit caching according to so-called "heuristic caching".

And then, quoting from https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#he...

> How long to reuse is up to the implementation, but the specification recommends about 10% [...] of the time after storing.

So assuming I'm reading this correctly, if she still hasn't added `Cache-Control` headers to the feed responses, and her last post was (for example) 24 hours ago, that means a well-behaved client will check the feed again in 2.4h from now, and then again 2.64h after that, and then 2.9h after that, and so on.

If the last feed update was 1 hour ago, and no `Cache-Control` header is present, a well-behaved client would cache the response for 6 minutes (10% of 1 hour).

Quoting the next paragraph (right after my last quote):

> Heuristic caching is a workaround that came before Cache-Control support became widely adopted, and basically all responses should explicitly specify a Cache-Control header.

So a possibility is that Unread RSS Reader might be detecting the lack of `Cache-Control` (which means Rachel is not bothering to follow caching recommendations), which then might be causing Unread RSS Reader to be doing heuristic caching as per the recommendations mentioned above, and the problem is just that Rachel doesn't like this heuristic caching but also doesn't want to include `Cache-Control` in her responses.

And if I'm understanding all this correctly, the `If-Modified-Since` and `If-None-Match` headers have nothing to do with request rate (what she's complaining about), they are only used to let the server decide if it should return a full response or if a 304 is enough.

Yeah, relying too much on modified headers from requests to send the appropriate response isn't ideal, because request headers can be incorrect and largely unreliable.

Responding with a Cache-Control header with a max-age seems like a much more superior option for these cases.