Я пишу приложение, которое использует отправленные сервером события для отправки обновлений в браузер. По большей части это работает очень хорошо, за исключением случаев, когда клиент находится за прокси-сервером «веб-ускоритель», который очень агрессивно кэширует вывод веб-сервера, даже если cache-control
заголовок no-cache
. Мне нужно отправить очень большой объем данных, прежде чем прокси решит что-то мне передать, а это означает, что обновления задерживаются на очень долгое время.
Я считаю, что этот прокси не соответствует стандарту HTTP, но я не могу изменить тот факт, что они существуют там. Таким образом, мне нужен способ обойти проблему.
Есть ли какой-нибудь трюк (возможно, какой-то волшебный заголовок?), Который я могу использовать, чтобы гарантировать, что мои события будут доставлены вовремя?
У вас есть больше возможностей, чем просто no-cache
в Кэш-контроль заголовок в отношении инструкций по кешированию как для браузера посетителей, так и для любых промежуточных прокси-серверов кеширования:
private
или public
; частный ответ специфичен для пользователя и не должен кэшироваться, публичный ответ может кэшироваться.no-cache
делает в основном то, что звучит, и представляет собой инструкцию для повторной проверки ресурса для каждого последующего запроса. Хотя после проверки подтверждено, что ресурс все еще действителен, кэшированный ответ все еще может быть обработан. no-store
четкая инструкция о том, что ответ должен рассматриваться как конфиденциальный и не храниться вообще, немного сильнее, чем вариант без кеширования выше.max-age
в секундах переопределяет заголовок Expires и указывает, когда ресурс истек и должен быть удален из кеша. s-maxage
в секундах, как указано выше, но для общих кешей, таких как сети доставки контента.Вы можете попробовать, если их объединение дает лучший результат.
Конечно, простой альтернативой может быть включение TLS, когда веб-ускоритель просто не может больше читать данные между вашими посетителями и веб-сервером.