Temos um site que executa o PHP-FPM e o NGINX. O aplicativo envia convites para membros do site que são codificados com sequências aleatórias de 40 caracteres (apenas alfanuméricos - exemplo abaixo). Hoje, pela primeira vez, encontramos um problema com essa abordagem. O seguinte URL:
http://oursite.com/notices/response/approve/1960/OzH0pedV3rJhefFlMezDuoOQSomlUVdhJUliAhjS
está retornando um erro 404. Este formato de URL está funcionando há 6 meses sem problemas, e outros URLs seguindo este formato exato continuam a ser resolvidos corretamente. Temos uma configuração muito básica, com um simples redirecionamento para um controlador frontal, e tudo o mais está funcionando há algum tempo.
Além disso, se mudarmos o último caractere de um "S" para algo diferente de um minúsculo "s", nenhum erro 404 e o site manipular a solicitação corretamente, estou pensando se há algum módulo de segurança que pode ver algo errado com esta string específica ... Não tenho certeza se isso faz algum sentido.
Não temos certeza de onde procurar para descobrir o que especificamente está causando o problema, portanto, qualquer direção seria muito apreciada.
Obrigado!
Atualização: adicionar uma barra ao final do URL permitiu que ela fosse tratada corretamente ... No entanto, ainda gostaria de chegar ao fim do problema.
Resolvido: O problema foi causado por parte da minha configuração ... Percebi que deveria ter postado, mas estava saindo da cidade e não tive chance.
Qualquer URL que terminasse em "css" ou "js" e não necessariamente precedida por um ponto (por exemplo, link ) foi interpretado como um pedido de um arquivo e o pedido não foi roteado através do front controller. O problema foi o meu regex para desabilitar o log e definir os cabeçalhos de expiração em jpgs, gifs, icos, etc.
Eu substitui isto:
location ~* ^.+(jpg|jpeg|gif|css|png|js|ico)$ {
com isso:
location ~* \.(jpg|jpeg|gif|css|png|js|ico)$ {
E agora os URLs que terminam em css, js, png, etc, são roteados corretamente pelo front controller. Espero que isso ajude alguém a sair.