Five Parts Make One Loop

For a large file on the proxy route, every request runs this loop again. In my tests, these were mainly large HTML files.

Each earlier post was only one part. When I connect them, they explain why HTML keeps going back to the origin (Symptom: HTML, CSS, and JS Keep Going to Origin).

1. The Akamai copy is expired, so it asks the next layer (Cache Freshness: Fresh, Stale, and 304).
2. The proxy route has no bypass rule, so the LB cache takes the request (A Bypass Header Works Only Where a Rule Reads It).
3. The LB cache answers 304 at once with the old copy (Stale-While-Revalidate: Serve Old First, Refresh in the Background).
4. The LB cache refreshes in the background with HEAD. Step 3 and step 4 happen at the same time.
5. The proxy accepts only GET, so it returns 405 (The Proxy Rejects HEAD, So the Refresh Always Fails). The copy stays expired.
6. The copy is already expired when it reaches Akamai, so Akamai keeps it for only 1 second.

Step	Evidence	Type
1, 6	The Akamai debug header showed TCP_REFRESH_HIT and max-age=1 three times	Fact
4, 5	7 requests matched 7 lines of HEAD 405 in the proxy log in the same second	Fact
3	The Age on the 304 is above 3600	Inference, because from Taiwan I cannot see the LB cache in the US

When the loop exists, the curl output shows max-age=1 and TCP_REFRESH_HIT. I fetched the same file from the old domain that does not use the proxy. The TTL was normal, and after that every request was a cache hit.

Each part looks reasonable alone. Connected, they make a loop that cannot stop.

Related: Symptom: HTML, CSS, and JS Keep Going to Origin, A Bypass Header Works Only Where a Rule Reads It, Stale-While-Revalidate: Serve Old First, Refresh in the Background, The Proxy Rejects HEAD, So the Refresh Always Fails, What I Learned: A Cache Is a Chain, Not a Box. Or go back to the series overview.