Если ваш сервер не посылает заголовки, связанные с кэшированием, то по умолчанию, браузеры ориентируются на заголовок Last-Modified. Если и эту дату не ставить (или всегда оставлять там текущее время), то ничего закэшировано не будет. Не могу сказать, что когда-то сильно парился по этому поводу как бэкэндер — обычно всякие API должны отвечать самыми свежими данными, а этим вопросом занимались фронты/девопсы/SRE (если занимались, конечно). Да и у многих фреймворков и проксей вполне адекватные настройки по умолчанию (например, всякие эндпоинты, которые статику отдают, нормально и заголовки кэширования из коробки дают).

И вот на прошлой неделе я как пользователь-админ делаю всякую мелочевку в нашем древнем MPA-монолите приложении с SSR, а страничка не обновляется. Возвращается результат из кэша. Самое страшное — даже в приватном режиме возвращается та же страница, где я “залогинен” и видны админские функции. Это Cloudflare решил любезно закэшировать страницу, и пофиг что ее нельзя кэшировать — ведь там есть .jar в URL! Абсолютно пофиг, что содержимое — это HTML страничка.

Решение вроде как очевидное — посылать правильный заголовок Cache-Control и Cloudflare настроить. Но с заголовками и нашим приложением возникла небольшая проблемка: если содержимое страницы отличается для разных пользователей, то надо эти кэши как-то разделять. Для этого есть Vary, но браузеры не заставишь посылать дополнительный заголовок, а Vary: Cookie — это антипаттерн. Другая проблема — CSRF-токены в HTML. В итоге сильно вкладываться в исправление проблемы не было ни желания, ни ресурсов, тупо отключили кэш, а в критическом месте оставили Vary: Cookie, потому что от этого, несмотря на проблемы, выиграет большинство пользователей. Но осадочек от Cloudflare остался. И ощущение, как будто “классический” web тут уступает современным фреймворкам: почти везде рекомендуют в подобных сценариях отдавать статический HTML, чтобы он кэшировался, а наполнять его на стороне клиента.