Stale-while-revalidate plugin bug - origin clock ahead of ATS clock
We have run into issues with the “stale-while-revalidate” feature. We have found services where the stale-while-revalidate feature seems to be engaged despite the fact that no “stale-while-revalidate” cache
control headers are being specified by the origin. A sample curl is below which illustrates the max-age=1, and the actual age=23 and the “Warning: 110 Response is stale”. The via header is decoded below as well and indicates a cache hit.
Our engineer realized this was being caused by the origin server clock moving ahead of the cache server clock which caused the freshness calculation to be thrown off. The left side of the equation was calculated
to be negative by the difference in the clocks and therefore be less than the max-age until the time between the two clocks is exceeded.
In our opinion this should be considered a bug in the plugin. The calculation should compare the txn_start date (local ATS date) to the remote date, because the cached date can't be earlier than now().