Diagnosing Stale HTTP Responses After Symfony 6.4 Deployments

Recognizable condition

After a Symfony deployment, some users keep seeing old pages or assets even after you run php bin/console cache:clear. Browsers and CDNs may hold the previous response because the HTTP freshness validators did not change. The useful takeaway: check whether the Cache-Stamp response header changes after a deploy. If it does not, your HTTP cache layer has no signal to replace the stored response.

What you will see

• You deploy new code or templates.
• You run php bin/console cache:clear in production.
• Some users still receive the previous HTML, CSS, or JSON.
• The problem appears behind Varnish, Cloudflare, or another reverse proxy, but not on your local machine.

Cause and diagnostic table

Observation	Likely cause	Where to check
Cache-Stamp header is missing	Custom cache provider does not emit it	Response headers
Cache-Stamp value is identical before and after deploy	Stamp generation did not refresh after cache rebuild	curl -I before and after
ETag or Last-Modified stays the same	HTTP cache validators tied to unchanged stamp	Response headers
Issue only behind a reverse proxy	Proxy honors Cache-Stamp; browser may not	Proxy configuration

Ordered checks

1. Confirm the header exists

Run from any terminal with network access:

curl -I https://your-site.com/some-page

Required permissions: none for a read-only request. Replace your-site.com and the path with your own values.

Expected check: Cache-Stamp appears in the response. If absent, Symfony or your cache provider is not emitting it.

Risk: none; this only reads headers.

2. Compare the stamp across a deploy

Run before and after clearing the cache:

curl -sI https://your-site.com/some-page | grep -i cache-stamp

Expected check: the timestamp or hash changes after cache:clear. If it stays the same, the stamp is not regenerating.

Risk: none.

3. Check the cache provider

Run in your project root:

grep -R "Cache-Stamp" vendor/symfony/cache --include="*.php" -n

Required permissions: read access to the vendor/ directory.

Expected check: Symfony cache classes reference the header. If your project uses a custom Psr\Cache\CacheItemPoolInterface implementation, it may not emit the header.

Risk: none.

4. Inspect reverse-proxy behavior

If you use Varnish or Cloudflare, purge the URL and request again:

curl -I https://your-site.com/some-page

Expected check: after purge, the response body and validators match the deployed code.

Fixes tied to findings

If Cache-Stamp is missing

Switch to the default Symfony cache adapter or verify that your custom provider sets the header. Review config/packages/cache.yaml for the adapter in use.

If the stamp does not change

Verify that cache:clear removed the affected pool. Clear a specific pool if needed:

php bin/console cache:pool:clear cache.app

Where: project root. Required permissions: filesystem write to the cache directory, typically var/cache/.

Expected check: a subsequent curl -I shows a new Cache-Stamp value.

Risk: clearing cache temporarily increases backend load while items are regenerated.

If the reverse proxy ignores the stamp

Adjust proxy VCL or cache rules to treat Cache-Stamp as part of the cache key, or purge the proxy cache as part of your deployment script.

Escalation criteria

• The header is still missing after switching to Symfony's default adapter.
• The stamp changes but users still see stale content after a proxy purge.
• Multiple cache pools exist and you cannot identify which one backs the HTTP response layer.

In these cases, involve the infrastructure team for proxy logs and provide a curl -v trace showing request and response headers.

Limitations

This guide covers Symfony 6.4 with symfony/cache 6.4.x. Behavior in earlier versions or with third-party bundles may differ. Cache-Stamp is not a standard HTTP header; its handling depends on your reverse proxy or CDN. Header generation behavior in symfony/cache 6.4.x should be confirmed in your environment before relying on it for invalidation.

Practical verification

After applying a fix, deploy to staging, run cache:clear, then:

curl -I https://staging.your-site.com/page

Confirm Cache-Stamp differs from the pre-deploy value and that the response body contains the new content. Then purge the production proxy cache for the same URL and repeat the check.