Como o Nginx pode forçar os navegadores a desabilitar ou liberar o cache de redirecionamento?

3

Temos o seguinte site seguro. Se o usuário abrir http://name.tld , ele deverá ser redirecionado para https://name.tld . Inicialmente, atrapalhou a ordem dos domínios no site seguro, por isso http://name.tld foi redirecionado para https://sub.name.tld em vez de http://name.tld .

Alteramos a ordem dos nomes dos servidores, mas todos os navegadores têm esse redirecionamento em cache. Se eu desabilitar o cache no chrome manualmente, ele funciona. Mas qualquer outro precisaria fazer o mesmo.

Como podemos forçar todos os navegadores a limpar o cache de redirecionamento (preferencial) ou desabilitá-los a não armazenar em cache o redirecionamento? Existe um cabeçalho que podemos enviar?

Este é o nosso site:

server {
       listen         80;
       server_name    name.tld sub.name.tld localhost sub.localhost;
       return         301 https://$server_name$request_uri;
}

server {
    listen              443 ssl;
    server_name         name.tld sub.name.tld localhost sub.localhost;
    ssl_certificate     /etc/ssl/certs/fullchain.pem;
    ssl_certificate_key /etc/ssl/private/privkey.pem;
    ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers         HIGH:!aNULL:!MD5;

    # required for large JSON files
    client_max_body_size 50m;

    #charset koi8-r;
    #access_log  /var/log/nginx/log/host.access.log  main;

    location / {
        root   /usr/share/nginx/html/name.tld;
        index  index.html index.htm;
    }

    location /api {
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_pass http://our-api:5000/api;
    }

    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    }
}

Editar: O problema real conectado com o redirecionamento é o CORS. Solicitações para a API falham porque as solicitações seriam feitas de um domínio diferente.

    
por mitchkman 21.02.2017 / 21:44

1 resposta

0

A solução para nós, específica para o nosso caso, é ativar o CORS (veja a edição acima) para solicitações de https://sub.name.tld . As pessoas afetadas têm pelo menos um site em funcionamento sob https://sub.name.tld

    
por 21.02.2017 / 22:22