La normalización de URI es el proceso mediante el cual los URI se modifican y estandarizan de manera consistente. El objetivo del proceso de normalización es transformar un URI en un URI normalizado para que sea posible determinar si dos URI sintácticamente diferentes pueden ser equivalentes.
Los motores de búsqueda emplean la normalización de URI para clasificar correctamente las páginas que pueden encontrarse con múltiples URI y para reducir la indexación de páginas duplicadas. Los rastreadores web realizan la normalización de URI para evitar rastrear el mismo recurso más de una vez. Los navegadores web pueden realizar una normalización para determinar si se ha visitado un enlace o si una página se ha almacenado en caché . Los servidores web también pueden realizar la normalización por muchas razones (es decir, para poder interceptar más fácilmente los riesgos de seguridad provenientes de las solicitudes de los clientes, usar solo un nombre de archivo absoluto para cada recurso almacenado en sus cachés, nombrado en los archivos de registro, etc.).
Proceso de normalización
Hay varios tipos de normalización que se pueden realizar. Algunos de ellos siempre preservan la semántica y otros pueden no serlo.
Normalizaciones que preservan la semántica.
Las siguientes normalizaciones se describen en RFC 3986 [1] para dar como resultado URI equivalentes:
Conversión de tripletes codificados por porcentaje a mayúsculas. Los dígitos hexadecimales dentro de un triplete de codificación porcentual del URI (por ejemplo, %3aversus %3A) no distinguen entre mayúsculas y minúsculas y, por lo tanto, deben normalizarse para usar letras mayúsculas para los dígitos AF. [2] Ejemplo:
Convirtiendo el esquema y el host a minúsculas. El esquema y los componentes del host del URI no distinguen entre mayúsculas y minúsculas y, por lo tanto, deben normalizarse a minúsculas. [3] Ejemplo:
Decodificación de tripletes codificados por porcentaje de caracteres no reservados. Los tripletes codificados por porcentaje del URI en los rangos ALFA ( %41– %5Ay %61– %7A), DÍGITO ( %30– %39), guión ( %2D), punto ( %2E), guión bajo ( %5F) o tilde ( %7E) no requieren codificación porcentual y deben decodificarse para sus correspondientes caracteres sin reservas. [4] Ejemplo:
http://example.com/%7Efoo→http://example.com/~foo
Eliminación de segmentos de puntos. Los segmentos de puntos .y ..el componente de ruta del URI deben eliminarse aplicando el algoritmo remove_dot_segments [5] a la ruta descrita en RFC 3986. [6] Ejemplo:
Convertir una ruta vacía en una ruta "/". En presencia de un componente de autoridad, un componente de ruta vacío debe normalizarse a un componente de ruta de "/". [7] Ejemplo:
http://example.com→http://example.com/
Eliminando el puerto predeterminado. Se debe eliminar un componente de puerto vacío o predeterminado del URI (puerto 80 para el esquema) con su delimitador ":". [8] Ejemplo:http
http://example.com:80/→http://example.com/
Normalizaciones que normalmente preservan la semántica.
Para los URI http y https, las siguientes normalizaciones enumeradas en RFC 3986 pueden dar como resultado URI equivalentes, pero los estándares no garantizan esto:
Agregar un "/" final a una ruta que no esté vacía. Los directorios (carpetas) se indican con una barra diagonal y deben incluirse en los URI. Ejemplo:
http://example.com/foo→http://example.com/foo/
Sin embargo, no hay forma de saber si un componente de ruta URI representa un directorio o no. RFC 3986 señala que si el URI anterior redirige al último URI, eso es una indicación de que son equivalentes.
Normalizaciones que cambian la semántica
La aplicación de las siguientes normalizaciones da como resultado un URI semánticamente diferente, aunque puede hacer referencia al mismo recurso:
Eliminando el índice del directorio. Los índices de directorio predeterminados generalmente no son necesarios en los URI. Ejemplos:
Quitar o agregar “www” como primera etiqueta de dominio. Algunos sitios web operan de manera idéntica en dos dominios de Internet: uno cuya etiqueta menos significativa es “www” y otro cuyo nombre es el resultado de omitir la etiqueta menos significativa del nombre del primero, conociéndose este último como dominio desnudo . Por ejemplo, http://www.example.com/y http://example.com/podrá acceder al mismo sitio web. Muchos sitios web redirigen al usuario desde www a la dirección que no es www o viceversa. Un normalizador puede determinar si uno de estos URI redirige al otro y normalizar todos los URI de forma adecuada. Ejemplo:
http://www.example.com/→http://example.com/
Ordenar los parámetros de consulta. Algunas páginas web utilizan más de un parámetro de consulta en el URI. Un normalizador puede ordenar los parámetros en orden alfabético (con sus valores) y volver a ensamblar el URI. Ejemplo:
Sin embargo, el orden de los parámetros en un URI puede ser significativo (esto no está definido por el estándar) y un servidor web puede permitir que la misma variable aparezca varias veces. [9]
Eliminación de variables de consulta no utilizadas. Es posible que una página solo espere que aparezcan ciertos parámetros en la consulta; Los parámetros no utilizados se pueden eliminar. Ejemplo:
Tenga en cuenta que un parámetro sin valor no es necesariamente un parámetro no utilizado.
Eliminando parámetros de consulta predeterminados. Un valor predeterminado en la cadena de consulta puede mostrarse de manera idéntica ya sea que esté ahí o no. Ejemplo:
Se pueden desarrollar algunas reglas de normalización para sitios web específicos examinando listas de URI obtenidas de rastreos anteriores o registros del servidor web. Por ejemplo, si el URI
http://example.com/story?id=xyz
aparece en un registro de rastreo varias veces junto con
http://example.com/story_xyz
podemos suponer que los dos URI son equivalentes y pueden normalizarse a una de las formas de URI.
Schönfeld et al. (2006) presentan una heurística llamada DustBuster para detectar reglas DUST (diferentes URI con texto similar) que se pueden aplicar a listas de URI. Demostraron que una vez que se encontraron y aplicaron las reglas DUST correctas con un algoritmo de normalización, pudieron encontrar hasta el 68% de los URI redundantes en una lista de URI.
^ RFC 3986, Sección 6. Normalización y comparación
^ RFC 3986, Sección 6.2.2.1. Normalización de casos
^ RFC 3986, Sección 6.2.2.1. Normalización de casos
^ RFC 3986, Sección 6.2.2.3. Normalización del segmento de ruta
^ RFC 3986, 5.2.4. Eliminar segmentos de puntos
^ RFC 3986, 6.2.2.3. Normalización del segmento de ruta
^ RFC 3986, Sección 6.2.3. Normalización basada en esquemas
^ RFC 3986, Sección 6.2.3. Normalización basada en esquemas
^ "jQuery 1.4 $.param desmitificado". Ben Almamán. 20 de diciembre de 2009 . Consultado el 24 de agosto de 2013 .
RFC 3986 - Identificador uniforme de recursos (URI): sintaxis genérica
Sang Ho Lee; Sung Jin Kim y Seok Hoo Hong (2005). Sobre la normalización de URL (PDF) . Actas de la Conferencia Internacional sobre Ciencias Computacionales y sus Aplicaciones (ICCSA 2005). págs. 1076-1085. Archivado desde el original (PDF) el 18 de septiembre de 2006.
Uri Schönfeld; Ziv Bar-Yossef e Idit Keidar (2006). No te metas en el polvo: diferentes URL con texto similar. Actas de la 15ª conferencia internacional sobre la World Wide Web . págs. 1015-1016.
Uri Schönfeld; Ziv Bar-Yossef e Idit Keidar (2007). No te metas en el polvo: diferentes URL con texto similar. Actas de la 16ª conferencia internacional sobre la World Wide Web. págs. 111-120.
