Los caracteres cirílicos en las reglas de reescritura causan errores 404 No encontrados

Question

Los caracteres cirílicos en las reglas de reescritura causan errores 404 No encontrados

#1 de Willington Vega (1 votos)

4

Tengo una regla de reescritura que incluye el URI de una página:

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

Si el URI de la página incluye caracteres cirílicos, como доска-объявлений , la regla se almacena 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+)

Si va a una página que incluye un enlace a una URL que coincide con la regla y hace clic en el enlace, el navegador cargará la página de destino sin problemas y WordPress puede hacer coincidir la regla con la URL solicitada.

En Safari (Mac), sin embargo, si copia la URL con un clic derecho > Copie el enlace y luego intente cargar la página de destino pegando la URL copiada en una nueva pestaña, obtendrá un error 404 No encontrado.

Cuando copia la URL en Safari, la URL se almacena con una codificación porcentual con los caracteres utilizados para representar los octetos de los caracteres cirílicos, todo en mayú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

No he podido reproducir el problema en Chrome o Firefox (ambos Mac) porque ambos almacenan la URL usando caracteres en minúscula para representar los octetos.

Esa URL con porcentaje de codificación es lo que recibe WordPress a través de la variable $_SERVER['REQUEST_URI'] . El problema es que el código responsable de hacer coincidir el URI solicitado con las reglas de reescritura hace una comparación que distingue entre mayúsculas y minúsculas (consulte el método parse_request en /wp-includes/class-wp.php ), lo que hace imposible que WordPress retire mi regla, aunque

%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

y

%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 la misma secuencia de caracteres.

¿Alguien sabe cómo evitar errores 404 No encontrados cuando los navegadores enviaron la solicitud usando octetos con un caso diferente?
¿Es esto algo que WordPress debería soportar? ¿o debería intentar eliminar los URI de la página de mis reglas de reescritura para evitar el problema?

rewrite-rules

pregunta Willington Vega 20.01.2016 - 16:46

1 respuesta

Lea otras preguntas en las etiquetas rewrite-rules

¿Agregar una única publicación destacada a todas las páginas? NGinx + Wordpress Subdomain Multi with core in Subdirectory

score 1 · Answer 1

Terminé siguiendo los consejos de @Kolya Korobochkin y añadí mayúsculas y minúsculas de las reglas de reescritura que incluyen octetos escapados.

$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
);

El complemento Porcentaje en mayúscula de codificación utiliza un enfoque similar para convertir los octetos en cada URL a La versión en mayúsculas. Sin embargo, el complemento está desactualizado y es posible que no esté realizando la conversión en todos los lugares necesarios. Además, creo que la mayoría de los usuarios del complemento en el que estoy trabajando no tendrán una URL con octetos codificados, por lo que ejecutar preg_replace_callback para todas las URL es un esfuerzo innecesario.

El uso de caracteres en mayúsculas para representar octetos es la forma recomendada de realizar el porcentaje de codificación (consulte RFC3986 , Sección 2.1 ). Por lo tanto, una mejor solución sería hacer que WordPress actualice su función utf8_uri_encode para escapar de los octetos usándolos. La mayoría de los navegadores que probé parecen mantener el estuche original, mientras que otros, como Safari, lo convierten en mayúsculas, si tienen la oportunidad.