Como usar [OR] ou substituir em um arquivo .htaccess?

Question

Resumo O sinalizador [OR] não está funcionando de maneira consistente em diferentes servidores. Detalhes e pergunta abaixo.

Eu tenho um site hospedado no Godaddy e escrevi este código para um arquivo .htaccess para redirecionar os usuários para a versão https do meu site. Isso funciona muito bem.

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTPS} off [OR]
    RewriteCond %{HTTP_HOST} !^www\. [NC]   
    RewriteRule ^(.*)$ https://www\.firstsite\.com%{REQUEST_URI} [R=301,L]
</IfModule>

Eu usei o mesmo arquivo .htaccess para um site diferente hospedado em Network Solutions e ele caiu no site. Produziu esse erro.

Esta página não está a funcionar
www.secondsite.com redireccionou-o demasiadas vezes.
ERR_TOO_MANY_REDIRECTS

Eu removi o sinal [OR] do site de soluções de rede e o site foi carregado sem o erro. Este é o código atualizado.

<IfModule mod_rewrite.c>
    RewriteEngine on
    RewriteCond %{HTTPS} off
    RewriteCond %{HTTP_HOST} !^www\. [NC]
    RewriteRule ^(.*)$ https://www\.secondsite\.com%{REQUEST_URI} [R=301,L]
</IfModule>

Infelizmente, sem o [OR] , ele não redireciona com base na primeira condição, RewriteCond %{HTTPS} off . No entanto, ele ainda redireciona com base na segunda condição RewriteCond %{HTTP_HOST} !^www\. [NC]

Não sei como consertar isso. Eu preciso do [OR] , mas não posso usá-lo. Existe uma maneira de usar [OR] de forma diferente ou existe um substituto para situações como esta? Muito obrigado!

    

Answer 1

The [OR] flag isn't working consistently across different servers.

Isso é (quase) impossível. O OR flag é um construtor / operador fundamental no mod_rewrite. Se essa construção não estiver funcionando corretamente, você terá um problema sério com seu servidor, exigindo reinstalação ou localizando um novo host. Este cenário é tão improvável.

No entanto, o mais provável é que um dos operandos na expressão OR não seja o esperado. ie. Neste exemplo, uma das variáveis de servidor HTTPS ou HTTP_HOST não está definida como você espera que seja. E, dentre os dois, é mais provável que a variável HTTPS server não esteja sendo definida (ou não esteja definida como esperado) - como mencionei no meu comentário. Isso é bastante "normal" e depende da configuração do servidor e de como o certificado SSL é gerenciado. por exemplo. Se o seu certificado SSL for gerenciado por um proxy de front-end (como CloudFlare), a variável de servidor HTTPS provavelmente não está definida. Isso parece ser consistente com os resultados que você está vendo.

Depuração

As dicas a seguir são apenas para ajudar na depuração inicial, a fim de encontrar uma solução eventual.

NB: Durante o teste, é preferível usar redirecionamentos temporários (302), que não são armazenados em cache pelo navegador. 301 redirecionamentos (permanentes) são armazenados em cache pelo navegador, portanto, você deve garantir que o cache esteja desabilitado, o que torna o teste problemático. Por favor, certifique-se de que o cache está limpo antes de continuar.

1. Tente (temporariamente) alterar isso para um redirecionamento HTTP para HTTPS (somente), isto é. remova a canonização www. Você ainda recebe um loop de redirecionamento? Por exemplo:

   RewriteCond %{HTTPS} off
   RewriteRule ^ https://www.example.com%{REQUEST_URI} [R,L]
   

   ( Além de: Não há necessidade de escapar pontos na substituição RewriteRule - esta é uma string comum, não uma regex.)

2. Se o acima acionar um loop de redirecionamento, verifique o que a variável de servidor HTTPS contém. ie. Remova o HTTP acima para o redirecionamento HTTPS e adicione o seguinte:

   RewriteRule ^foo$ /?HTTPS=%{HTTPS} [R,L]
   

   E acesse o URL https://example.com/foo diretamente. Você deve ser redirecionado para https://example.com/?HTTPS=<value> . Qual é o código%? (O <value> pode estar vazio.)

3. Verifique os cabeçalhos de solicitação HTTP que seu aplicativo está vendo. Se você estiver usando PHP, verifique as matrizes <value> e $_SERVER superglobal e verifique especificamente os índices $_ENV , HTTPS , SERVER_PORT e SCRIPT_URI (que corresponde ao HTTP_X_FORWARDED_PROTO header - se definido em absoluto). No entanto, pode haver outros, específicos para o seu servidor. Por exemplo, alguns hosts configuram uma variável de ambiente chamada X-Forwarded-Proto (em oposição a uma variável de servidor com o mesmo nome). Adicione o que você achou à sua pergunta.

   Se você vir um cabeçalho de solicitação HTTPS , estará atrás de um proxy de front-end, como esta questão no StackOverflow .

Veja também essa pergunta em Webmasters profissionais para uma" discussão "e uma solução eventual.

UPDATE: ... a site hosted on Network Solutions...

Acabei de pesquisar um pouco sobre "Network Solutions" (NS) e parece que isso pode não ser possível !? Isso eu acho totalmente desconcertante se for verdade, no entanto, eu acho que ainda deve depender de como e qual tipo de certificado SSL está instalado?

(Ainda verifique os cabeçalhos de solicitação de HTTP e as variáveis de servidor / script como mencionado acima.)

No entanto, as documento de suporte da Network Solutions sobre redirecionamentos de SSL estados:

Network Solutions® uses a proxy SSL this does not allow the use of server-side variables to detect HTTPS (secure). All server-side coding will always detect HTTP (non-secure), and for programs that attempt to redirect non-secure connections (http://) to a secure connection (https://) will result in an infinite loop and server error after 30 seconds.

You can use a client-side program (like javascript) to detect if it's secure and redirect if it's not. You can use the below coding to create a redirect. Just modify the code so that it redirects to the correct secure domain and add it into the HTML of any sensitive pages you may have.

<script language="javascript">
if (document.location.protocol != "https:")
{
document.location.href = "https://subdomain.yourdomain.com" + 
document.location.pathname;
};
</script>

O "proxy SSL" deve se identificar ou pelo menos identificar o estado HTTPS na solicitação "proxy" para o servidor de aplicativos. No entanto, isso implica que não.

Veja também a seguinte questão relacionada no StackOverflow. No entanto, as "outras" soluções apresentadas lá não parecem IMO viáveis. A conclusão final parece ser uma referência ao documento de suporte acima (e à solução JavaScript) do NS. link