3 ms·

> I requested the feed in my browser _twice_ and already received a 429 with a Retry-After of 24 hours! My guess: No `Cache-Control` response header. checks

> I requested the feed in my browser _twice_ and already received a 429 with a Retry-After of 24 hours! 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=86400

thaumasiotes 2y ago
Well, come on. It's your responsibility as a client to check for fresh content in a manner that takes her posting patterns into account. It's not her responsibility as a server to provide content in a manner that takes her posting patterns into account.
- quectophoton 2y ago
  Serious or not (sounded like sarcasm but one can never be too sure!), I'll elaborate on this point. I 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.

thaumasiotes 2y ago

Well, come on. It's your responsibility as a client to check for fresh content in a manner that takes her posting patterns into account. It's not her responsibility as a server to provide content in a manner that takes her posting patterns into account.

quectophoton 2y ago
Serious or not (sounded like sarcasm but one can never be too sure!), I'll elaborate on this point. I 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.