4 ms·

I'd like to have a way to force If-Modified type checks on cached assets after a deployment, but not if no deployment occurred.

jrochkind1 9y ago
I mean, there's no way to tell remote agents which aren't in contact with you to contact you, or that the cache should be busted. There's no way to broadcast this "NOW you need an if-modified check, cause I just did a deployment" to all possible caching agents. Not even really any reasonably sane way theoretically/hypothetically, on the internet we've got. Either you've got to tell the remote agent how long to cache for without checking in, or it's got to check in regularly to see if it's cache is still good, I think that's a basic constraint that can't be gotten around. You can use an ETag of a checksum, instead of a checksum in the filename. Now a user-agent can just check with an if-modified-since and get a response quickly. But it's still got to check regularly. That or guaranteed changed URLs when content changes are about the only way it's ever going to work in the HTTP client-server architecture, I think. Maybe there's a creative way to come up with guaranteed-changed-url that isn't as inconvenient in development for you, but most people find the current practices a pretty good spot I think.
- masterleep 9y ago
  It can be done if resources are associated, perhaps by site, or by path within a site, and if there's at least one non-cached resource. For example: Add a HTTP header on resource responses that is 1:1 with the deployment. When this header changes on any response, treat any associated resources in the cache as needing an If-Modified checkin. Then add that header to a non-cached dynamic page, like the user's home page. When the browser checks this page and sees a deployment change, it'll know to check the static assets.

4 ms·

I'd like to have a way to force If-Modified type checks on cached assets after a deployment, but not if no deployment occurred.

by masterleep 9y ago

jrochkind1 9y ago
I mean, there's no way to tell remote agents which aren't in contact with you to contact you, or that the cache should be busted. There's no way to broadcast this "NOW you need an if-modified check, cause I just did a deployment" to all possible caching agents. Not even really any reasonably sane way theoretically/hypothetically, on the internet we've got. Either you've got to tell the remote agent how long to cache for without checking in, or it's got to check in regularly to see if it's cache is still good, I think that's a basic constraint that can't be gotten around. You can use an ETag of a checksum, instead of a checksum in the filename. Now a user-agent can just check with an if-modified-since and get a response quickly. But it's still got to check regularly. That or guaranteed changed URLs when content changes are about the only way it's ever going to work in the HTTP client-server architecture, I think. Maybe there's a creative way to come up with guaranteed-changed-url that isn't as inconvenient in development for you, but most people find the current practices a pretty good spot I think.
- masterleep 9y ago
  It can be done if resources are associated, perhaps by site, or by path within a site, and if there's at least one non-cached resource. For example: Add a HTTP header on resource responses that is 1:1 with the deployment. When this header changes on any response, treat any associated resources in the cache as needing an If-Modified checkin. Then add that header to a non-cached dynamic page, like the user's home page. When the browser checks this page and sees a deployment change, it'll know to check the static assets.