A Bypass Header Works Only Where a Rule Reads It
X-Cache-Bypass is not an HTTP standard. A cache steps aside only if a written rule reads it, and the LB cache on the proxy route had no such rule.
X-Cache-Bypass is not an HTTP standard. A cache steps aside only if it has a written rule that reads it.
The numbers in the last post pointed to the route (Symptom: HTML, CSS, and JS Keep Going to Origin). I went back and looked at the LB cache on both routes. Their rules were different.
LB cache on the bucket backend (has a bypass rule):
If request.header has X-Cache-Bypass → go straight to storage
else → reply with the copy if there is one, otherwise go to storage
LB cache on the proxy backend (no bypass rule):
ignores the header → reply with the copy if there is one, otherwise go to the proxyHow I Proved It
- I called the load balancer directly with
X-Cache-Bypass: yes. - The proxy route returned
age: 77. This means it used a copy it had stored. - The bucket route returned
x-cache: uncacheable. This means it did not use a copy.
When I read the config files, I thought bypass worked for every request (Two Cache Layers: What I Believed). In reality, it works only for the bucket route. For images, 97.9% of requests do not leave the edge, because images really have only one cache layer.
A header does not work by itself. The rule that reads it makes it work.
Related: Load Balancer: One Entrance, Many Backends by Rule, Cache Headers: Who Sets, Who Reads, Two Cache Layers: What I Believed, Symptom: HTML, CSS, and JS Keep Going to Origin, Stale-While-Revalidate: Serve Old First, Refresh in the Background. Or go back to the series overview.