You know what's funny I'm a fool that still had "disable cache" checked in the dev tools from a previous session when I was checking the request headers. At the current moment now that I have unchecked that in dev tools it is actually respecting the cache for those images. I can't definitively say if that is different than before but either way at least it seems cache is verifiably working with it normally now that I have that unchecked.
Can't tell from your UI screenshot, but quite often loading a page with devtools open will disable the cache. I forget if this is the default behavior or not.
The flipside of 1. though is that cached images can't be hijacked and have vulnerabilities injected, or from a non security standpoint, have breaking changes introduced which mean the image no longer builds and/or runs how you're expecting.
Hehe, that specific case is probably something that most people run into at least once. I've seen several cases of it in production too, where someone refactored something years in the past and accidentally disabled the cache without anyone noticing.
Caching without a Cache-Control header is a bug, agreed. The point is that in the original bug report the Cache-Control header was set in a way that implied the resource to be cacheable, but only for 0 seconds. This kind of declarations are perfect "worms' can openers".
It's useful for development environments to cache things which have not changed in order to shorten the feedback loop. Many do.
The problem is guaranteeing correctness. Correct cache invalidation is Hard(TM). Therefore, the CI system builds from scratch in order to guarantee a clean, correct and reproducible output from a given snapshot of the source.
As for 'live programming' against a running image, this write-up starts with the implicit assumption that this is always a good thing. While it can be useful on occasion, the reason for restarting the application after changing its source code is the same reason we favour functional, immutable styles: mutable state is a pain and it's best to push it out of the thing you're working with if at all possible. Modifying the running image risks ending up with internal states which no single snapshot of the source could ever have yielded.
No, latest is just a tag and is not handled differently. There is a CLI flag to ignore cached layers. This however does not effect the FROM line, so if you have the image, there will be no pull.
I think that would happen in combination with the remote server replying "304 Not Modified"
Now that you mentioned it tho, I'm not sure whether developer tools is showing me the ground truth, how does it give me 200 OK from cache without asking the remote whether the resource has changed? My memory agrees with you, something has changed in the matrix.
Typically when you "cache" something, you're gonna expire it at some point...no? If the image is patched, it eventually gets refreshed in the mirror. If the image dissapears at least we still have it until we figure out where the heck it went.
reply