Что кэширует ответы с помощью s-maxage в Google App Engine flexible и как очистить этот кеш?

У меня есть приложение, работающее в настраиваемом контейнере Java на App Engine flexible. Я пытался отследить, почему я получаю устаревшие ответы, и сузил проблему до кешированных ответов.

Я знаю, что наше приложение не возвращает устаревший контент, потому что у нас нет общего кеша, а устаревшие ответы сохраняются после повторного развертывания. Мы также не используем Cloud CDN.

Когда я попадаю в API своего приложения по адресу https://[app-id].appspot.com/api/123, мое приложение возвращает Cache-Control: public, s-maxage=31536000, max-age=3600 заголовок ответа. s-maxage должен был сообщить Cloudflare (наш CDN) кэшировать ответ, и мы вручную очищаем кеш Cloudflare при обновлении контента. Однако похоже, что что-то перед нашим приложением кэширует ответы. В кешированных ответах заголовок ответа с датой остается прежним, а возраст увеличивается, показывая, что контент действительно устарел.

Я видел документацию по кэшированию в стандартных документах App Engine для app.yaml, но я не нашел упоминания об инфраструктуре кэширования в гибких документах App Engine. Моя ментальная модель заключалась в том, что балансировка нагрузки HTTPS выполнялась от имени приложения, но, похоже, это не так.

Если я попытаюсь воспроизвести эту проблему из GCP с помощью SSHing в экземпляре Compute Engine или в экземпляре App Engine Flexible, я не обнаружу никакого кеширования. Тем не менее, я пробовал это в других облаках и на ноутбуке, и кеширование стабильно. Служба поддержки Cloudflare изначально предупредила нас об этом поведении, и они видят кеширование из своих производственных центров обработки данных, которые напрямую связаны с Google через их программу CDN Interconnect.

Это должно исходить из самой инфраструктуры Google, может быть, из скрытого Google Cloud Load Balancer, используемого для App Engine, поскольку соединение зашифровано.

Что делает кеширование, как его отключить и как очистить?


comment
Предложение: прекратить изменять содержание. Используйте номера версий или хеш-значения для новых версий статических файлов в имени файла. Есть так много переменных (и устройств, кешей, прокси), которые вы не контролируете при кэшировании.   -  person John Hanley    schedule 03.12.2019
comment
Обычно это наша цель, но для некоторых вещей это не вариант или слишком сложно синхронизировать номера версий везде. Вместо этого мы можем полагаться на кеш нашей CDN, чтобы хранить контент до тех пор, пока мы не прикажем ему очистить, но при этом все клиенты будут регулярно обновляться из CDN. Мы согласны с тем, что мы не можем дать много гарантий относительно кешей в целом, но от источника до CDN мы должны точно знать, что происходит.   -  person jon_wu    schedule 03.12.2019
comment
Согласовано. Интересный вопрос.   -  person John Hanley    schedule 03.12.2019
comment
Поразмыслив еще немного, я не думаю, что должно быть что-то (неожиданное), которое мы не можем контролировать, помимо этого скрытого поведения на стороне Google - по крайней мере, при использовании curl. Я согласен с тем, что браузеры могут быть немного непредсказуемыми, но промежуточные кеши и прокси не должны быть здесь фактором, поскольку мы используем HTTPS, и ничто в середине не может читать заголовки или контент HTTP.   -  person jon_wu    schedule 05.12.2019
comment
Очень хороший комментарий, ничего посередине. Остается ваш код и браузер. Как вы думаете, какой из них нарушает цепочку кеширования? Мы вернулись к моему первому комментарию.   -  person John Hanley    schedule 05.12.2019


Ответы (1)