Two pairs of documentation pages that disagree with each other. Both are small, but both are the kind of detail you only look up when you’re already debugging something, so having the wrong number is expensive.
1. Hit-for-pass maximum TTL
The hit-for-pass object is stored for the duration specified by its TTL, but subject to a minimum of 120 and a maximum of 3690 seconds.
Hit-for-pass objects have a 2 minute TTL by default, but will respect the response’s defined TTL … subject to a minimum of 2 minutes and a maximum of 1 hour.
The 120s / 2-minute minimum agrees. The ceiling doesn’t — 3690s vs 3600s. Which is authoritative?
(My guess is 3690, since it sits in the same family as the 3700s disk-storage threshold on the serving-stale-content page, but that’s only a guess.)
2. Accept-Encoding normalization order
The Accept-Encoding header reference describes normalization as: copy the original into Fastly-Orig-Accept-Encoding, strip it for known-broken user agents, then gzip → deflate → remove — with br handled separately inside the #FASTLY recv macro for Brotli-enabled services.
Enabling automatic compression describes it as a single br → gzip → deflate sequence applied “on inbound requests”.
The practical difference is where custom normalization has to run. If br is only normalized inside #FASTLY recv, then custom logic must sit after that macro and read from Fastly-Orig-Accept-Encoding; if it happens before vcl_recv like the others, it doesn’t. Could you confirm which describes the actual order?
An aside on discoverability
While I’m here — serving stale content is the only page in the guides that mentions the 3700s disk-vs-transient-storage threshold, and it’s tucked under a “Least Recently Used (LRU)” bullet:
objects with a TTL of 3700s or longer get written to disk, whereas objects with shorter TTLs end up in transient, in-memory-only storage. We recommend setting your TTL to more than 3700s when possible.
That’s a genuinely useful number for anyone choosing TTLs, and it’s very hard to find where it currently lives. It might be worth surfacing on the cache-freshness page too.
Thanks!