a rota do robots.txt requer uma barra invertida quando estiver atrás de um Application Load Balancer

Question

Eu tenho um site de trilhos usando um AWS ALB e todas as rotas parecem funcionar, exceto uma, robots.txt.

Estou recebendo o erro "ERR_TOO_MANY_REDIRECTS", link para o exemplo: link

Após algumas pesquisas, encontrei muitos locais que disseram que o Load Balancer está enviando tráfego via HTTP para as instâncias do EC2, e os redirecionamentos podem ser causados quando o tráfego HTTPS está atingindo o balanceador de carga saws docs . Eu configurei o apache conforme descrito no link e não acredito que esse seja o problema. Além disso, todas as outras rotas funcionam no site em HTTP ou HTTPS. Apenas o robots.txt não.

Se eu tirar uma instância do balanceador de carga e acessá-la por IP, a página robots.txt será exibida como esperado.

Estranhamente, se uma barra final for adicionada ao link de url , a página será renderizada. Não há redirecionamentos de curingas no Apache que devem estar adicionando uma barra à direita e, novamente, fora do balanceador de carga, o robots.txt é acessível sem a barra final.

1. Por que essa barra seria necessária quando a instância do EC2 está atrás de um balanceador de carga de aplicativo?
2. Como posso configurá-lo para que a página seja carregada sem a barra final?

Httpd.config:

TraceEnable Off
ServerTokens Prod
ServerRoot "/etc/httpd"
PidFile run/httpd.pid
Timeout 600
KeepAlive On
MaxKeepAliveRequests 200
KeepAliveTimeout 600

User apache
Group apache
ServerAdmin [email protected]
UseCanonicalName Off
DirectoryIndex index.html index.html.var
AccessFileName .htaccess
<Files ~ "^\.ht">
    Order allow,deny
    Deny from all
</Files>
TypesConfig /etc/mime.types

<IfModule mod_mime_magic.c>
    MIMEMagicFile conf/magic
</IfModule>
HostnameLookups Off
LogLevel crit
LogFormat "%a %{X-Forwarded-For}i %t %D %V \"%r\" %>s %b \"%{User-agent}i\"" detailed
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %b" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent
ServerSignature Off
ServerTokens Prod
AddDefaultCharset UTF-8
AddType application/x-compress .Z
AddType application/x-gzip .gz .tgz
AddHandler php5-script .php
AddType text/html .php

Listen 80
#Listen 443

Include conf.modules.d/*.conf
Include conf.d/*.conf

Editar Mais algumas informações: No AWS, o balanceador de carga tem dois ouvintes, um para http (porta: 80) e outro para https (porta: 443). Cada um deles encaminha para um grupo-alvo diferente, o grupo-alvo http está configurado para HTTP e porta 80, enquanto o grupo-alvo https está configurado para HTTPS e a porta 443

Em seguida, no Apache, tenho um Ouvinte na porta 80, visto no arquivo vinculado acima. Também um dos arquivos conf.d / *. Conf para ssl config está escutando na porta 443

Eu disse anteriormente que não achava que isso fosse uma questão do http - > https redirecionando, mas agora estou pensando que isso está mal configurado.

Editar 2 Ao tentar descobrir esse problema, novas rotas foram definidas para apontar para o arquivo robots.txt do rails, por exemplo, o route /robots.img foi usado e renderizaria como esperado. Alguns outros sufixos de arquivo foram usados e todos funcionaram. Não foi apenas .txt que foi o problema, human.txt foi testado como a rota e processou a página conforme o esperado. Isso mostra que o problema é específico do robots.txt

Quando eu pesquiso todo o meu diretório do apache, nada acontece para robots.txt, robôs e apenas um hit para txt em conf.d / autoindex.conf:

AddIcon /icons/text.gif .txt

O hit do txt é apenas definir um ícone para arquivos txt, mas como outros arquivos txt funcionam, por exemplo, o arquivo human.txt, não acho que esse seja o problema.

Como o robots.txt pode estar em um loop de redirecionamento infinito?

    

Answer 1

Uma causa bastante típica desse loop de redirecionamento infinito é quando você faz o descarregamento de SSL ou a terminação SSL em um balanceador de carga ou em um CDN, o que faz com que todo o tráfego para o servidor real seja sempre HTTP simples.

Quando você configura um redirecionamento para HTTPS no servidor da web, você tem uma situação como esta:

1. Client ---> HTTP ----> load balancer ----> HTTP ----> Your server
                                                                 | 
                         <-------  Response: Redirect to HTTPS <- 

2. Client ---> HTTPS ----> load balancer ----> HTTP ----> Your server
                           does SSL off-loading                  |
                           or SSL termination                    |
                                                                 | 
                         <-------  Response: Redirect to HTTPS <-

3. Client ---> HTTPS ----> load balancer ----> HTTP ----> Your server
                                                                 | 
                         <-------  Response: Redirect to HTTPS <-

4. Client ---> HTTPS ----> load balancer ----> HTTP ----> Your server
                                                                 | 
                         <-------  Response: Redirect to HTTPS <-

5. Client ---> HTTPS ----> load balancer ----> HTTP ----> Your server
                                                                 | 
                         <-------  Response: Redirect to HTTPS <-
... ad infinitum 

A solução é:

• não redirecione para HTTPS do seu servidor web! Faça isso no loadbalancer ou no CDN

• se você não puder fazer o redirecionamento para HTTPS no loadbalancer / CDN, envie o tráfego que chega sobre http para um servidor de back-end separado e deixe que o servidor faça nada além de redirecionar para HTTPS e você evita o loop e obtém algo como:

  1. Client ---> HTTP  ----> load balancer ----> HTTP ----> Your redirect server
                                                                   | 
                           <-------  Response: Redirect to HTTPS <- 
  
  2. Client ---> HTTPS ----> load balancer ----> HTTP ----> Your application server
                                                                   | 
                           <-------  Response: Application data  <- 
  

• possivelmente o loadbalancer / CDN define um cabeçalho com o protocolo original, HTTP ou HTTPS, que o cliente usa e usa a presença / ausência desse cabeçalho como condição para gerar um redirecionamento para HTTPS.

Além disso, observe: um Redirecionamento HTTP 301 == "Movido permanentemente" e, portanto, até mesmo um redirecionamento configurado incorreto será armazenado em cache pelos navegadores da Web (e talvez também pelo CDN e servidores proxy) e depois de ter removido a diretiva de uma configuração do servidor você ainda pode observá-lo. Pode ser necessário testar a partir de uma nova janela do navegador anônima e / ou limpar seus caches.