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

Используйте кеширование прокси с помощью nginx, удалив заголовок Set-Cookie

Следующее является результатом ошибки в инструментах разработчика WebKit, используемых в Google Chrome и Safari от Apple. Я сделал отчет об ошибке с CrBug, который затем идентифицировал регресс в Набор изменений WebKit 116952. Я хотел бы поблагодарить @Grumpy и @Matthieu Cormier за их помощь в отслеживании этого. Не могу дождаться следующей сборки Chrome Canary :).

У меня есть установка nginx на моем сервере вместе с PHP-FPM, и во время создания нового веб-сайта и попыток убедиться, что это происходит как можно быстрее, я воспользовался инструментами аудита Google Chrome. Среди некоторых ошибок он дал мне это.

Leverage proxy caching (10)
The following publicly cacheable resources contain a Set-Cookie
header. This security vulnerability can cause cookies to be shared
by multiple users.

Итак, я хотел бы знать, что мне нужно добавить к следующему оператору, чтобы он не устанавливал заголовок Set-Cookie для этого домена. Затем я бы взял эту информацию и применил ее к поддоменам css, img, ect, чтобы браузер мог правильно кэшировать ее.

server {
    gzip on;
    gzip_static on;

    listen          80;
    server_name     img.domain.tld;
    root            /www/domain/tld;
    index           index.php index.htm index.html;

    location ~* \.(gif|png|jpg|jpeg|svg)$ {
        expires 30d;
    }

    include php_fpm;
}

За дополнительной информацией обращайтесь к Сердитый.

Вот файл конфигурации, который я использую для PHP FPM include, который используется в поддомене img.

PHP-FPM включает

location ~ \.php$ {
    fastcgi_pass    unix:/tmp/php.socket;
    fastcgi_param   SCRIPT_FILENAME
                    $document_root$fastcgi_script_name;
    include         fastcgi_params;
}

Как видите, он должен активироваться, только когда местоположение заканчивается расширением файла php.

Забавно то, что у меня также есть файл css, который, как сообщается, имеет заголовок set-cookie, и который обслуживается субдоменом css, в который не включен php-fpm ... вот эта часть Файл конфигурации.

server {
    gzip_static on;

    listen          80;
    server_name     css.domain.tld;
    root            /www/domain/css;
    index           index.htm index.html;

    location ~* \.(css)$ {
        expires 7d;
    }
}

Файлы ...

Leverage proxy caching (5)
    The following publicly cacheable resources contain a Set-Cookie 
    header. This security vulnerability can cause cookies to be shared
    by multiple users.

style.css (обслуживается css.domain.tld)
2009EMSWeekLogoSmall.jpg (обслуживается domain.tld)
EMS% 20FOUR.jpg (обслуживается domain.tld)
get_adobe_reader.png (обслуживается img.domain.tld)
dhs-ntas-badge-small.jpg (обслуживается dhs.gov)

конфигурация сервера domain.tld выглядит так.

server {
    gzip on;
    gzip_static on;

    listen          80;
    server_name     .domain.tld;
    root            /www/domain/www;
    index           index.php index.htm index.html;

    location ~* \.(htm|html|ico|icns|hqx|gif|png|svg|jpg|jpeg|svg)$ {
        expires 1d;
    }

    include php_fpm;
}

nginx cookies

Хотя в вашем случае кажется, что вы можете столкнуться с какой-то ошибкой в инструменте, который сообщает, что ваши графические файлы содержат Set-Cookie директиве (крайне маловероятно, что у вас будет материал "Set-Cookie" в статических файлах, обслуживаемых непосредственно nginx с описанной вами настройкой), я действительно столкнулся с ситуацией, когда веб-приложение Java устанавливало некоторые файлы cookie, которые я не хотел установить.

Это можно решить с помощью nginx с помощью следующих директив, помещенных в server контекст (изменить proxy_ к fastcgi_ как требуется):

    proxy_hide_header       Set-Cookie;
    proxy_ignore_headers    Set-Cookie;
    # important! Remember the special inheritance rules for proxy_set_header:
    # http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_set_header
    proxy_set_header        Cookie "";

Все три приведенные выше директивы очень важны: proxy_hide_header гарантирует, что заголовок не будет передан обратно клиенту, proxy_ignore_headers гарантирует, что заголовок не будет автоматически отключать кеширование в nginx и, наконец, proxy_set_header гарантирует, что клиент не сможет передать какие-либо предыдущие файлы cookie в веб-приложение и испортить ваш кеш. Обратите внимание на мой комментарий относительно proxy_set_header наследование - вы не можете вложить эту директиву (необходимо определить все или ничего на данном уровне).

Очевидно, вам также нужно будет убедиться, что все ваши веб-приложения по-прежнему работают после удаления файлов cookie таким образом, как указано выше. Но я не понаслышке знаю, что вышеперечисленное отлично помогает избавиться от файлов cookie, передаваемых по HTTP!

Определение ресурса для кэширования не является поведением по умолчанию. Итак, все, что вызывает это уведомление Chrome, - это объект, который вы указали для кеширования.

Директива для кеширования (в данном случае публичная) может быть установлена двумя способами.

Ваш nginx сообщает ему кешировать.
PHP сообщает об этом кешу, который затем пересылается nginx.

В соответствии с указанной выше конфигурацией nginx и игнорируя весь include php_fpm;, нет ничего, что предлагало бы №1, если ваши изображения (gif, jpg, png) каким-то образом не выполняются.

Также возможно, что в PHP есть такая директива кеширования. В таком случае вам действительно следует исправить это из ядра, а не пытаться выполнить работу по исправлению.

Но с этими двумя случаями вы также можете войти в странный сценарий. Если ваше изображение не найдено, оно попытается найти страницу 404. И если 404 является исполняемым файлом (php) прямо или косвенно, он может нести команду set cookie. Это было бы плохим поведением, если бы директива 404 также велела кэшировать его. Так что не забудьте проверить и это. То же самое, очевидно, относится и к любым другим кодам ошибок.

Это почти все, о чем я могу догадаться, учитывая текущую информацию. Возможно, вы захотите получить дополнительную информацию о том, какой именно элемент заставляет Chrome выдавать такое сообщение, если обнаружены какие-либо ошибки, а также полную конфигурацию nginx и / или php-fpm.

Я попытался просмотреть полные заголовки HTTP, чтобы узнать, есть ли какие-либо признаки передачи файлов cookie или какой-либо настраиваемой информации.

Пример заголовка ответа с сайта OP, вызывающего предупреждения.

telnet img.nassauems.net 80
Trying 205.186.162.66...
Connected to img.nassauems.net.
Escape character is '^]'.
GET http://img.nassauems.net/buttons/get_adobe_reader.png HTTP/1.1
Host: img.nassauems.net

HTTP/1.1 200 OK
Server: nginx/1.2.4
Date: Sat, 12 Jan 2013 20:24:19 GMT
Content-Type: image/png
Content-Length: 2597
Last-Modified: Fri, 28 Dec 2012 08:30:57 GMT
Connection: keep-alive
Expires: Mon, 11 Feb 2013 20:24:19 GMT
Cache-Control: max-age=2592000
Accept-Ranges: bytes

Пример заголовка ответа с моего сайта, который не вызывает предупреждений.

telnet www.mysite.com 80
Trying 123.123.123.123...
Connected to www.mysite.com.
Escape character is '^]'.
GET http://www.mysite.com/test.png HTTP/1.1
Host: www.mysite.com

HTTP/1.1 200 OK
Server: nginx/1.0.12
Date: Sat, 12 Jan 2013 20:21:43 GMT
Content-Type: image/png
Content-Length: 207
Last-Modified: Sat, 27 Aug 2011 04:42:30 GMT
Connection: keep-alive
Expires: Sun, 13 Jan 2013 20:21:43 GMT
Cache-Control: max-age=86400
Accept-Ranges: bytes

Вы можете заметить разницу? Я не могу!

Я бы назвал это ошибкой Chrome Audit.

Я недавно заметил это и испытываю то же самое.

Я уверен, что это ошибка в Chrome.

Я посмотрел на заголовки ответов в Safari Web Inspector, и он также не показывает Set-Cookie.
Я подключился напрямую к своему веб-серверу, выполнил запрос GET и проверил необработанные заголовки, строки Set-Cookie нет.

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

Использование Chrome 24.0.1312.52 в OS X

Использование Safari версии 6.0.2 (8536.26.17) в OS X