Hi, @luksak. The default cache control headers have a purpose which is described in this blog post:
It is true we don’t have a header which shows the cache hits and misses (and there are reasons why we don’t have one).
Regarding being able to see which CDN location is used, yes, there is no header that exposes that. However, that can be determined via the IP address and a geo-ip lookup. For example, using GeoIP2 Databases Demo | MaxMind.
The CDN node for all three x-nf-request-ids shared was one hosted in AWS in the eu-central-1 (Frankfurt) availability zone using the IP address
184.108.40.206. All three used that same node.
Now, I also consider it both unusual and wrong for the repeated requests not to be cached. It is true that they were not being cached but should have been.
So, before I filed a bug report for this, I wanted to make sure I wasn’t missing something. To this end, I was in the process of filing a research request to have our developers take a look at the non-caching behavior. In that research request I was attempting to include instructions to explain to our developers how to see the caching failure.
However, something has changed and I can not longer reproduce the cache misses!
Even with the CDN node which was misbehaving before, the requests are all cache hits now. Note, previously I was able to reproduce the issue with all CDN nodes, not just the Frankfurt one. Now, I cannot reproduce it with any.
I also ran a report for the example URL above (which was
In the last 24 hours, there have been 2341 distinct requests for that specific URL. Of those requests the cache hit and miss counts are as follows:
In other words, the URL is being cached now. Are you still seeing the slow loading behavior now?