No Cache-Control header on the PAC response
medium
Without Cache-Control the browser decides when to re-fetch the PAC (hours or the whole session). A proxy change then takes effect at unpredictable times per client. An explicit max-age makes the roll-out window known and controllable.
Why it matters
Engines keep a fetched PAC for an engine-specific default period when the server says
nothing; the defaults differ (Chromium re-fetches periodically, Firefox is reported to keep
it for the session). During a proxy migration or an emergency fix that means some clients
pick up the change in minutes and others the next day, and “clear cache and restart” advice
to users does not scale. Cache-Control: max-age=N with N between ten minutes and a day
gives a predictable window; shorter values trade freshness for fetch load.
How to fix
Send Cache-Control with max-age (e.g. max-age=3600) from the PAC server.
Examples
Bad
HTTP/1.1 200 OK
Content-Type: application/x-ns-proxy-autoconfig
Content-Length: 1234
Good
HTTP/1.1 200 OK
Content-Type: application/x-ns-proxy-autoconfig
Cache-Control: max-age=3600
Content-Length: 1234
Engine behaviour
| Engine | Behaviour | Source |
|---|---|---|
| chromium | Without caching headers the PAC is re-fetched on an internal schedule and on network changes. | expert, unverified |
| firefox | Reported to keep the PAC for the session when no caching headers are present. | expert, unverified |
Related rules
- PAC marked no-cache / no-store / max-age=0 PAC-D004
- PAC cached for more than a day PAC-D005