3 ms·

cache-control doesn't completely replace Expires for some use cases. If you have a scheduled task that generates data every hour, you can set Expires according

cache-control doesn't completely replace Expires for some use cases. If you have a scheduled task that generates data every hour, you can set Expires accordingly so all clients will refresh the data as soon as the hour rolls over. You can do this using max-age but then you have to dynamically calculate this header per request which means you can't do things like upload your data to s3 and set the cache-control header on it. With expires, I can upload a file to s3 and set Expires: ... 17:00 and then not have to touch it again for an hour. you can work around this client side with per hour filenames or the other usual cache busting tricks, but that's annoying.

AbacusAvenger 8y ago
It seems like kind of an unlikely scenario that you'd want to expire content at a specific time. I mean, if someone chooses to do that, they better know what the impact could be. With the Expires header, all clients that retrieved that content would expire at the exact same time, which could cause some disproportionately high load in the few seconds after that (the "thundering herd" problem). The Cache-Control solution will stagger the expirations (relative to when the client last retrieved it) so the server doesn't get trampled.
- AstralStorm 8y ago
  Congratulations, your infrastructure stability now depends on particular web browsers and caches implementing their caches and headers correctly... It takes just one big bad actor to break. Reminds me of certain routers damaging NTP traffic.
  - AbacusAvenger 8y ago
    That's a cynical view, and I don't think I said you should depend on Cache-Control working. Yes, there will be bad actors, but the majority of clients are good actors. It's just one of several measures you should take to even out the load. Of course you'd want a caching layer in front of the server doing the actual work, but it's still possible to "thundering herd" the cache server if you use an Expires header. Even if the herd doesn't hurt your backend server, it can still make the load on your caching frontend servers spike at specific time periods with every good actor refreshing the content at the same time. So it's still ideal to try and even out that load with Cache-Control.
    - ponyfleisch 8y ago
      The use case of having hourly updated data (e.g. weather data) on an S3 bucket behind a CloudFront distribution is not that niche. Thundering herd may or may not be an issue depending on the amount of traffic you normally get, the architecture of your backend (e.g. AWS Lambda or S3 which can most likely deal with this easily) and the primary purpose of your CDN usage (e.g. caching data closer to the users for faster delivery world wide rather than reducing back end load).
laumars 8y ago
I get your point but it's such a niche use case that I can't see it coming up in real world situations. I mean, "never say never", but it's a solution that creates as many problems as it solves. I used to build online games that fed off real world events. Eg football managers based on real football matches, games based on horse racing, F1, tour de France, and many others. We needed to change feeds when the match started and ended, but sometimes events are delayed or run into extra time. So we needed a way to change that quickly. We also needed to present different screens at the start and end of the event to the live scoring during the event. This all meant it was easier handling times based cut offs in JavaScript with the live scoring JSON files (which were being fed from S3) using cache control header because it was easier to set an X seconds into he future time out for that than rewriting the S3 tags every few seconds with a new expires header. On paper our use case should be precisely what you described but even we found expires to be unnecessary.

AbacusAvenger 8y ago

It seems like kind of an unlikely scenario that you'd want to expire content at a specific time. I mean, if someone chooses to do that, they better know what the impact could be. With the Expires header, all clients that retrieved that content would expire at the exact same time, which could cause some disproportionately high load in the few seconds after that (the "thundering herd" problem). The Cache-Control solution will stagger the expirations (relative to when the client last retrieved it) so the server doesn't get trampled.

AstralStorm 8y ago
Congratulations, your infrastructure stability now depends on particular web browsers and caches implementing their caches and headers correctly... It takes just one big bad actor to break. Reminds me of certain routers damaging NTP traffic.
- AbacusAvenger 8y ago
  That's a cynical view, and I don't think I said you should depend on Cache-Control working. Yes, there will be bad actors, but the majority of clients are good actors. It's just one of several measures you should take to even out the load. Of course you'd want a caching layer in front of the server doing the actual work, but it's still possible to "thundering herd" the cache server if you use an Expires header. Even if the herd doesn't hurt your backend server, it can still make the load on your caching frontend servers spike at specific time periods with every good actor refreshing the content at the same time. So it's still ideal to try and even out that load with Cache-Control.
  - ponyfleisch 8y ago
    The use case of having hourly updated data (e.g. weather data) on an S3 bucket behind a CloudFront distribution is not that niche. Thundering herd may or may not be an issue depending on the amount of traffic you normally get, the architecture of your backend (e.g. AWS Lambda or S3 which can most likely deal with this easily) and the primary purpose of your CDN usage (e.g. caching data closer to the users for faster delivery world wide rather than reducing back end load).

laumars 8y ago

I get your point but it's such a niche use case that I can't see it coming up in real world situations. I mean, "never say never", but it's a solution that creates as many problems as it solves. I used to build online games that fed off real world events. Eg football managers based on real football matches, games based on horse racing, F1, tour de France, and many others. We needed to change feeds when the match started and ended, but sometimes events are delayed or run into extra time. So we needed a way to change that quickly. We also needed to present different screens at the start and end of the event to the live scoring during the event. This all meant it was easier handling times based cut offs in JavaScript with the live scoring JSON files (which were being fed from S3) using cache control header because it was easier to set an X seconds into he future time out for that than rewriting the S3 tags every few seconds with a new expires header. On paper our use case should be precisely what you described but even we found expires to be unnecessary.