Caracteres cirílicos em regras de reescrita causam erros 404 Not Found

4

Eu tenho uma regra de reescrita que inclui o URI de uma página:

(<page-uri>)/someaction/(\d+)

Se o URI da página incluir caracteres cirílicos, como доска-объявлений , a regra será armazenada como:

(%d0%b4%d0%be%d1%81%d0%ba%d0%b0-%d0%be%d0%b1%d1%8a%d1%8f%d0%b2%d0%bb%d0%b5%d0%bd%d0%b8%d0%b9)/someaction/(\d+)

Se você acessar uma página que inclua um link para um URL que corresponda à regra e se você clicar no link, o navegador carregará a página de destino sem problemas e o WordPress poderá corresponder à regra com o URL solicitado.

No Safari (Mac), no entanto, se você copiar o URL com o botão direito > Copiar Link e, em seguida, tentar carregar a página de destino colando o URL copiado em uma nova guia, você receberá um erro 404 Not Found.

Quando você copia um URL no Safari, o URL é armazenado com uma codificação percentual com os caracteres usados para representar os octetos dos caracteres cirílicos, todos em maiúsculas:

%D0%B4%D0%BE%D1%81%D0%BA%D0%B0-%D0%BE%D0%B1%D1%8A%D1%8F%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B9/someaction/1

Eu não consegui reproduzir o problema no Chrome ou no Firefox (ambos Mac) porque ambos armazenam o URL usando caracteres minúsculos para representar os octetos.

Esse URL com porcentagem de codificação é o que o WordPress recebe por meio da variável $_SERVER['REQUEST_URI'] . O problema é que o código responsável pela correspondência do URI solicitado com as regras de reconfiguração faz uma comparação com distinção entre maiúsculas e minúsculas (ver parse_request method em /wp-includes/class-wp.php ), tornando impossível para o WordPress detectar minha regra, embora

%D0%B4%D0%BE%D1%81%D0%BA%D0%B0-%D0%BE%D0%B1%D1%8A%D1%8F%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B9

e

%d0%b4%d0%be%d1%81%d0%ba%d0%b0-%d0%be%d0%b1%d1%8a%d1%8f%d0%b2%d0%bb%d0%b5%d0%bd%d0%b8%d0%b9

representa a mesma sequência de caracteres.

  • Alguém sabe como evitar erros 404 não encontrados quando os navegadores enviam a solicitação usando octetos com um caso diferente?
  • É algo que o WordPress deve suportar? ou devo tentar remover as URIs de página das minhas regras de regravação para evitar o problema?
por Willington Vega 20.01.2016 / 16:46

1 resposta

1

Acabei seguindo o conselho do @Kolya Korobochkin e adicionei versões maiúsculas e minúsculas das regras de reescrita que incluem octetos com escape.

$regular_page_uri = get_page_uri( $page->ID );

$uppercase_page_uri = preg_replace_callback(
    '/%[0-9a-zA-Z]{2}/',
    create_function( '$x', 'return strtoupper( $x[0] );' ),
    $regular_page_uri
);

O plug-in Porcentagem de Codificação da Letra de Capital usa uma abordagem semelhante para converter os octetos em todas as URLs para a versão em maiúsculas. No entanto, o plugin está desatualizado e pode não estar fazendo a conversão em todos os locais necessários. Além disso, acredito que a maioria dos usuários do plug-in em que estou trabalhando não terá URLs com octetos codificados, portanto, executar preg_replace_callback para todas as URLs é um esforço desnecessário.

O uso de caracteres maiúsculos para representar os octetos é a maneira recomendada de fazer a codificação percentual (consulte RFC3986 , Seção 2.1 ). Portanto, uma solução melhor seria fazer o WordPress atualizar sua função utf8_uri_encode para escapar dos octetos usando-os. A maioria dos navegadores que testei parece manter o caso original, enquanto outros, como o Safari, convertem para maiúsculas, se tiverem uma chance.

    
por Willington Vega 22.01.2016 / 17:56