Os POSTs desaparecem, chegam como GETs [closed]

2

Estávamos enfrentando problemas em que os usuários terminariam em nosso site com "solicitações GET vazias". Com isto quero dizer que eles se originaram no site externo como pedidos POST com vários parâmetros, mas o navegador só faria um simples GET sem parâmetros para o nosso servidor.

Isso aconteceu mais ou menos, independentemente do navegador, etc. e com vários sites com várias tecnologias.

Por alguma razão, a renovação do nosso certificado (que funcionou por 18 meses) resolveu o problema. O certificado antigo era da Verisign e o novo certificado é da Thawte.

Abaixo da regra horizontal está a pergunta original.

Temos um serviço em que esperamos que várias webstores nos enviem dados POST via HTTPS e carga útil de dados como parâmetros nvp POST. Poucos por cento destes são em algum lugar convertidos em requisições GET e a carga útil é perdida, então eles chegam ao nosso servidor como requisições GET sem nenhum dos parâmetros.

Quando recebemos solicitações GET, não há sinais em nosso balanceador de carga ou firewall de uma solicitação POST que seria conectada de alguma forma ao GET que estamos recebendo. O GET é geralmente o primeiro pedido recebido que podemos ver de um determinado IP.

Não parece haver nenhum outro fator comum, além de quase todos os computadores clientes, serem Windows de várias versões. Os navegadores podem ter pelo menos o Firefox, o IE ou o Chrome.

O outro site enviando os dados por meio do navegador do usuário (formulário com o método POST) pode estar usando qualquer um dos seguintes, mas não se limitando aos seguintes:

  • PHP, Java, Ruby on rails, .NET

  • Linux, Windows

  • Apache, Nginx, IIS, Tomcat, Cowboy

  • Drupal, Magento, Joomla, Prestashop, soluções proprietárias e internas

O problema afeta clientes de vários sites diferentes que não parecem ter nada em comum. Também não parece ser um certo ISP que os usuários estão vindo.

O que parece acontecer é que a solicitação POST desaparece e nunca chega a nenhum de nossos servidores. De alguma forma, o navegador envia uma solicitação GET sem nenhum dos parâmetros. No entanto, o referenciador está intacto, o que, de acordo com nossos testes, significa que o usuário não pode ter selecionado o campo de endereço do navegador e pressionado entrar, pois isso perde o cabeçalho do referenciador. Com uma ou algumas tentativas (voltar ao navegador, reclik o envio no site de referência) o POST vem como deveria

Também de acordo com o que ouvimos sobre os comentários dos usuários finais, eles não recebem nenhuma mensagem de erro do navegador.

As chamadas de servidor para servidor não parecem ser afetadas por esse problema. Parece que o problema começou em 14 de julho, pois após essa data, recebemos essas solicitações de problemas diariamente. Tudo começou com apenas alguns dias e tem aumentado constantemente desde então e agora está resolvido em aproximadamente 5% por dia de todas as solicitações que recebemos em nossa API.

Portanto, isso não parece um problema nos sites de referência, pois afeta sites com uma plataforma tão variada, sem nenhum fator comum. Parece que é um problema do Windows, pois os agentes do usuário problemáticos são praticamente todas as janelas de várias versões, mas isso afeta todos os navegadores, então o que poderia ser?

Todas as sugestões são bem-vindas neste momento.

EDIT: Nós veríamos se fosse um http - > https redirecionam em nossa extremidade à medida que testamos isso e encontramos a solicitação http nos logs do balanceador de carga. O redirecionamento não www para www também aconteceria em nosso balanceador de carga AFAIK e também veríamos isso. Também esquecemos de mencionar que obtemos principalmente dados válidos dos sites afetados, é apenas uma pequena parte dos pedidos que se comportam de forma irregular.

EDITAR: * RESOLVIDO (tipo) * Como um desses "agora há uma maneira que isso vai ajudar, mas vamos tentar de qualquer maneira, como não temos idéia do que está errado", instalamos um novo certificado. Este problema deixou de existir desde a instalação do novo certificado.

Atualmente, não temos nenhuma ideia de como o certificado poderia ter causado o comportamento que estávamos enfrentando. AFAIK se houver problemas com o certificado, o navegador solicitará ao usuário uma ação (pelo que ouvimos, ninguém estava recebendo nenhum aviso) e nem conversará com o servidor ou continuará normalmente. O que eu não esperaria é que o navegador altere POST para GET e descarregue todos os parâmetros. O certificado antigo foi instalado corretamente, ou de que outra forma ele poderia estar funcionando perfeitamente por um ano e meio?

De qualquer forma, não houve casos em cerca de uma semana. A última entrada no log mostrando um desses casos de problemas é cronometrada em aproximadamente alguns minutos antes de instalar o novo cert ...

    
por pkauko 04.09.2015 / 15:49

1 resposta

1

É difícil adivinhar, mas o meu seria um redirecionamento, mais especificamente HTTP - > Redirecionamento de HTTPS. Para ser esse o caso, seria necessário redirecionar de HTTP para HTTPS em seu servidor e, possivelmente, você não vê esses em seus registros, porque você pode tê-los em locais diferentes.

Assim, o cenário seria que o cliente por algum motivo (alguma forma em algum lugar falha no esquema correto) POSTs para HTTP, obtém o código de redirecionamento e navega com GET para HTTPS.

Se esse não for o caso, pode haver um redirecionamento diferente (como não-www para www prefixo ou similar). Você deve ver esses nos logs, mas pode sentir falta deles por algum motivo (filtragem de alguma forma baseada em código HTTP?). Mas isso não é tão provável quanto o redirecionamento HTTP & > HTTPS.

Então, é isso ou você pode provar que esse não é o caso?

    
por 04.09.2015 / 18:09

Tags