Aproveite o cache de proxy com nginx removendo o cabeçalho Set-Cookie

Question

O seguinte é resultado de um bug no Dev Tools do WebKit usado pelo Google Chrome e pelo Safari da Apple. Fiz um relatório de erros com o CrBug , que identificou a regressão em WebKit Changeset 116952 . Eu gostaria de agradecer a @Grumpy e @Matthieu Cormier por sua ajuda estar rastreando isso. Mal posso esperar pela próxima versão do Chrome Canary:).

Eu tenho a configuração nginx no meu servidor junto com o PHP-FPM e, durante a criação de um novo website, e para ter certeza de que ele é o mais rápido possível, passei pelas ferramentas de auditoria do Google Chrome. Entre alguns dos erros, isso me deu isso.

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.

Então, o que eu gostaria de saber é, o que devo adicionar à seguinte declaração para não definir um cabeçalho Set-Cookie para esse domínio. Eu então pegaria essa informação e a aplicaria aos subdomínios css, img, ect, para que ela pudesse ser armazenada corretamente pelo navegador.

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;
}

Faça o acompanhamento para solicitar mais informações por Grumpy .

Aqui está o arquivo de configuração que eu sou para o PHP FPM, usado no subdomínio img.

O PHP-FPM inclui

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

Como você pode ver, ele deve ser ativado somente quando a localização terminar com uma extensão de arquivo php.

O engraçado é que eu também tenho um arquivo css que está sendo reportado como tendo um cabeçalho set-cookie, e que está sendo servido pelo subdomínio css que não tem um php-fpm incluído nele ... aqui está isso parte do arquivo de configuração.

server {
    gzip_static on;

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

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

Os arquivos são ...

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 (veiculado por css .domain.tld)
• 2009EMSWeekLogoSmall.jpg (veiculado por domain.tld)
• EMS% 20FOUR.jpg (servido por domain.tld)
• get_adobe_reader.png (veiculado por img .domain.tld)
• dhs-ntas-badge-small.jpg (veiculado por dhs.gov)

a configuração do servidor domain.tld se parece com isso.

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;
}

    

Answer 1

Identificar um recurso a ser armazenado em cache é um comportamento não padrão. Então, o que quer que esteja causando essa notificação pelo Chrome é um objeto que você especificou para ser armazenado em cache.

A diretiva para cache (pública, neste caso) pode ser definida de duas maneiras.

1. Seu nginx diz para o cache.
2. O PHP diz para o cache, que é então encaminhado pelo nginx.

Por sua configuração nginx acima, e ignorando todo o include php_fpm; , não há nada que sugira # 1 a menos que suas imagens (gif, jpg, png) estejam de alguma forma sendo executadas.

Também é possível que o PHP tenha essa diretiva de cache. Nesse caso, é algo que você realmente deveria estar corrigindo do núcleo, em vez de tentar fazer um trabalho de correção.

Mas com esses dois casos, você também pode inserir um cenário estranho. Se a sua imagem não for encontrada, ela tentará encontrar uma página 404. E se 404 é um executável (php) direta ou indiretamente, ele pode então carregar um comando set cookie. Isso seria um mau comportamento se a diretiva 404 também dissesse para ele ser armazenada em cache. Então, não esqueça de verificar isso também. O mesmo também se aplica obviamente a qualquer outro código de erro.

Isso é tudo o que posso imaginar, dadas as informações atuais. É possível que você queira acompanhar informações adicionais sobre o item exato que está causando a mensagem do Chrome, se houver algum erro encontrado, além de configuração completa de nginx e / ou php-fpm.

Eu tentei ver os cabeçalhos HTTP completos para ver se há alguma indicação de cookies ou informações personalizadas sendo passadas.

Exemplo de cabeçalho de resposta do site do OP que está causando avisos.

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

Exemplo de cabeçalho de resposta do meu site que não causa avisos.

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

Você consegue identificar a diferença? Eu não posso!

Eu classificaria isso como um bug com o Chrome Audit.

    

Answer 2

Embora no seu caso pareça que você esteja acertando algum bug na ferramenta que relata que seus arquivos gráficos contêm uma diretiva Set-Cookie (é extremamente improvável que você esteja tendo coisas "Set-Cookie" em arquivos estáticos) servido diretamente pelo nginx com a configuração que você descreve), eu realmente encontrei uma situação em que um webapp Java estava definindo alguns cookies que eu não queria ter definido.

Isso pode ser resolvido através do nginx com as seguintes diretivas colocadas no contexto server (altere proxy_ para fastcgi_ conforme necessário):

    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 "";

Todas as três diretivas acima são muito importantes: proxy_hide_header garante que o cabeçalho não será passado de volta ao cliente, proxy_ignore_headers garante que o cabeçalho não desabilitará automaticamente o cache no nginx e, finalmente, proxy_set_header garante que um O cliente não pode passar nenhum cookie anterior para o aplicativo da Web e estragar seu cache. Note meu comentário sobre proxy_set_header herança - você não pode aninhar esta diretiva (tem que definir tudo ou nenhum em um dado nível).

Obviamente, você também terá que garantir que todas as suas aplicações web ainda funcionem após eliminar os cookies de maneira semelhante à acima. Mas eu sei em primeira mão que o acima funciona muito bem em se livrar dos cookies passados por HTTP!

    

Answer 3

Recentemente notei isso e estou experimentando a mesma coisa.

Estou certo de que este é um bug no Chrome.

1. Eu olhei os cabeçalhos de resposta no Safari Web Inspector e ele também não mostra um Set-Cookie.
2. Eu fiz telnet diretamente para o meu servidor web e executei uma solicitação GET e examinei os cabeçalhos brutos, não há linha Set-Cookie.

O Chrome pode estar detectando algo e exibindo uma descrição inválida ou pode ser apenas um bug simples.

Usando o Chrome 24.0.1312.52 no OS X

Usando o Safari versão 6.0.2 (8536.26.17) no OS X