Назад | Перейти на главную страницу

Кеширование на стороне клиента при использовании CSP с одноразовыми номерами в nginx - как использовать слабые валидаторы кеширования / etags?

я использую nginx's expires директива; его etag директива так же хорошо как Last-Modified заголовок (если я правильно понял) по умолчанию включены.

Чтобы разрешить определенные встроенные сценарии JavaScripts при использовании ограничительных Политика безопасности контента (CSP) заголовки (т.е. нет 'unsafe-inline' политика ресурсов) Я хочу использовать одноразовые номера.

Я в основном следил статья Скотта Хельма по этому поводу, используя nginx $request_id в моем испытании создать nonce как обсуждалось на ServerFault (чтобы быстро попробовать это без необходимости создавать nginx с нуля).

Когда я попробовал это, оказалось, что кеширование больше не работает, как я ожидал:
Nginx ответил файлом и свежим Last-Modified и ETag заголовки каждый раз вместо 304 Not Modified ответ, на который я надеялся.

Если подумать, это имеет смысл: nonce в заголовке CSP, а также в исходном коде изменяется с каждым запросом. Однако больше ничего не меняется. Так что, возможно, это изменение, которое "слабый валидатор" должен игнорировать (и, таким образом, отмечать запрошенный ресурс как не изменено).

Сказав это, я почти ничего не знаю о конфигурации сервера или кешировании заголовков, если на то пошло. Скорее всего, то, что я знаю, не помогает, и что слабые валидаторы, например, в любом случае не должны работать таким образом.

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

В основном мой вопрос: можно ли настроить nginx так, чтобы кеширование работало таким образом, чтобы изменения в nonce только (т.е. изменения, которые происходят на лету путем замены текста) игнорируются, когда nginx создает Last-Modified и ETag заголовки (т.е. где он смотрит только на изменения файла на диске) - эффективно используя то, что, вероятно, является слабым валидатором?

И, если предположить, что ошибка браузера является проблемой, можете ли вы сделать что-то, чтобы остановить это, например, не возвращать заголовок CSP, когда сервер возвращает 304 (чтобы не заменять одноразовый идентификатор «заголовка» в браузере новым, который затем не выполняет t совпадают с "файловым")? (Это скорее академический вопрос; я полагаю, я мог бы как-то попытаться не устанавливать заголовок CSP для 304 ответ, возможно, используя ngx_headers_more модуль.)

Есть ли у меня выбор между использованием одноразовых номеров или кешированием? Или это должно работать из коробки (и все, что я видел, было связано с чем-то другим)?