Since #36833, the Store no longer uses or trusts the X-Content-Digest header present on a response, since that may come (in the case of using CachingHttpClient) from upstream HTTP sources. Instead, the X-Content-Digest is re-computed every time a response is written by the Store.

Additionally, the Store is implemented in a way that when restoring responses, it does not actually load the response body, but just keeps the file path to the content on disk in another internal header called X-Body-File. It is up to others (HttpCache, for example) to actually load the content from there. For reasons I could not determine, the file path is also set as the response body.

When the HttpCache performs revalidations, it may happen that it wants the Store to persist a previously restored response. In that case, the Store fails to honor its own X-Body-File header. Instead, it would compute (since #36833) the X-Content-Digest, which now is a hash of the cache file path.

So, we end up with a response that still carries X-Body-File for the original, correct response. Since the HttpCache honors this value, we don't immediately notice that. But inside the Store, the request is now associated with the new (bogus) content entry.

It takes another round of looking up the content in the Store to now get a response where the X-Body-File also points to the wrong content entry.

Although I feel a bit uncomfortable with trusting headers that seemingly need to be evaluated in different classes and may come from elsewhere, my suggestion is to skip the write inside Store if X-Body-File and X-Content-Digest are both present and consistent with each other.

Additionally, a file_exists check could be added to provide additional assertions, at the cost of accessing the filesystem.