Aggressive caching for a Mastodon reverse proxy: what to cache, what to never cache, and why content negotiation will eventually betray you
a day ago
- Mastodon根据Accept头为同一URL提供不同的内容（HTML、ActivityPub JSON、API JSON），这需要仔细的缓存键规范化。
- 缓存键必须包含Accept头的规范化变体，以防止向客户端提供错误的内容类型。
- 关键假设：AUTHORIZED_FETCH禁用，无签名URL，联邦使用HTTP签名（而非Authorization头）。
- 绕过缓存逻辑被分解为针对方法、授权、cookie和URI模式的小型正交映射。
- 短TTL（10-30秒）用于动态公共端点，而不可变资产的TTL则为数天。
- proxy_cache_lock防止惊群效应，proxy_cache_use_stale为静态资源启用stale-while-revalidate。
- 来自上游的Vary头被忽略，代理完全负责正确的内容协商。
- 日志记录包括缓存状态和变体桶，以在生产环境中验证行为。
- 注意事项包括：短TTL消耗CPU，stale-while-revalidate可能隐藏问题，AUTHORIZED_FETCH改变缓存规则，以及绝不能缓存Set-Cookie响应。
- 主要目标是通过在代理层吸收重复的公共流量，减少到达Puma/Rails的请求。