Какие заголовки запроса должны быть отправлены на сервер, чтобы он служил вам не кэшированным ответом

Question

В https://kith.com/products.json отправляется определенный заголовок ответа, уведомляющий меня, что я обращаюсь к кэшированным данным x-cache: hit, client Я хочу обойти это и получить заголовок ответа x-cache: miss

Я прошел вЗаголовки запроса

 'cache-control': 'no-store',
 'pragma': 'no-cache'

Вот локон

curl --location --request GET 'https://kith.com/products.json' \
--header 'Cache-Control:  no-store' \
--header 'Pragma: no-cache'

Answer 1

Это немного ужасный взлом, но тестирование в браузере, похоже, приводит к ошибкам в кеше. Протокол GET разрешает строку запроса, которая должна предположить, что cloudflare даст разные результаты. Однако, если вы отправите строку запроса, которую ваша цель будет игнорировать, например https://kith.com/products.json?a=a, а затем https://kith.com/products.json?b=b, это вызовет промах кэша, но kith.com все равно будет обслуживать тот же файл.

Answer 2

Нет надежного способа заставить любой сервер обойти механизмы кэширования владельца сайта. Кэширование на сервере находится под контролем владельца веб-сайта, и они могут по своему усмотрению настраивать чахеинг. Если они так решат, они могут игнорировать любые заголовки и / или строки запросов во входящих запросах, тогда любая ваша попытка принудительно пропустить кэш не будет работать.

Сказав это, если владелец сайта установил правиладля кеширования, которое позволяет определенным типам запросов обходить кеш, вы можете воспользоваться этим , даже если вы на самом деле не используете этот тип запроса . Помещение ложных строк запроса GET в URL является показательным примером. Другим часто используемым уловкой является отправка запроса POST вместо GET - большинство веб-сайтов обрабатывают сообщения POST как входящие сообщения с данными и пересылают их на серверы, а большинство серверов обрабатывают запрос POST как GET, если они не ожидаютФорма подачи. Но имейте в виду, что на самом деле это злоупотребление веб-сайтом: владелец использует кеширование, чтобы попытаться снизить нагрузку на основные серверы, поэтому попытки обхода кеша фактически являются пальцем в глазу и оскорблением длявладелец веб-сайта, который имеет право быть оскорбленным.

Если вам действительно нужен доступ к исходной версии данных веб-сайта, для какой-либо хорошей и серьезной цели вам, возможно, следует обратиться квладелец, чтобы выяснить, будут ли они готовы предоставить вам доступ (возможно, через непубличный URL) к исходной серверной версии данных, но вам нужно будет привести веские доводы, и я подозреваю, что у вас могут возникнуть трудностиубедить их.

Answer 3

Обратите внимание, что любые связанные с кэшем заголовки, отправленные клиентом с запросом, могут не соблюдаться сервером, хотя любой прокси-сервер с хорошим поведением (например, CloudFlare в этом случае) должен действовать разумно.

Я пыталсяваш тестовый запрос и получил x-cache: hit, server. Возможно, в первый раз я пропустил кеш, но это произошло в моем браузере, и сетевой журнал был очищен (впоследствии загружен favicon.ico).

Я не верю, что есть способ заставить x-cache: miss, если серверы настроены для кэширования определенных ресурсов в течение определенного периода времени.

Вот страница Информация управления кешированием CloudFlare . Обратите внимание, что он написан с точки зрения разработчиков, работающих на исходном сервере и настраивающих CloudFlare, а не пользователей / клиентов, делающих запросы.

Редактировать: я только что понял, что домен kith.com может быть сайтом с очень высоким трафиком,Я хотел бы рассмотреть любой способ обхода кэша от клиента как ошибку на стороне сервера, которая будет работать против них для повышения производительности.