Normalização URI - URI normalization

Não deve ser confundido com canonização de URL .
Tipos de normalização de URI.

A normalização de URI é o processo pelo qual os URIs são modificados e padronizados de maneira consistente. O objetivo do processo de normalização é transformar um URI em um URI normalizado para que seja possível determinar se dois URIs sintaticamente diferentes podem ser equivalentes.

Os mecanismos de pesquisa empregam a normalização de URI para atribuir importância às páginas da web e reduzir a indexação de páginas duplicadas. Os rastreadores da Web realizam a normalização de URI para evitar o rastreamento do mesmo recurso mais de uma vez. Os navegadores da Web podem realizar a normalização para determinar se um link foi visitado ou para determinar se uma página foi armazenada em cache .

Processo de normalização

Existem vários tipos de normalização que podem ser executados. Alguns deles sempre preservam a semântica e outros podem não ser.

Normalizações que preservam a semântica

As seguintes normalizações são descritas no RFC 3986 para resultar em URIs equivalentes:

  • Conversão de trigêmeos com codificação percentual em maiúsculas. Os dígitos hexadecimais em um tripleto de codificação percentual do URI (por exemplo, %3a versus %3A ) não fazem distinção entre maiúsculas e minúsculas e, portanto, devem ser normalizados para usar letras maiúsculas para os dígitos AF. Exemplo:
http://example.com/foo%2a → http://example.com/foo%2A
  • Converter o esquema e o host em letras minúsculas. O esquema e os componentes do host do URI não diferenciam maiúsculas de minúsculas e, portanto, devem ser normalizados para minúsculas. Exemplo:
HTTP://User@Example.COM/Foo → http://User@example.com/Foo
  • Decodificando trigêmeos com codificação percentual de caracteres não reservados. Os tripletos codificados por porcentagem do URI nos intervalos de ALPHA ( %41 - %5A e %61 - %7A ), DÍGITO ( %30 - %39 ), hífen ( %2D ), ponto ( %2E ), sublinhado ( %5F ) ou til ( %7E ) não requerem codificação de porcentagem e devem ser decodificados para seus caracteres não reservados correspondentes. Exemplo:
http://example.com/%7Efoo → http://example.com/~foo
  • Removendo segmentos de pontos. Os segmentos de ponto . e .. no componente do caminho do URI devem ser removidos aplicando o algoritmo remove_dot_segments ao caminho descrito no RFC 3986 . Exemplo:
http://example.com/foo/./bar/baz/../qux → http://example.com/foo/bar/qux
  • Converter um caminho vazio em um caminho "/". Na presença de um componente de autoridade, um componente de caminho vazio deve ser normalizado para um componente de caminho de "/". Exemplo:
http://example.com → http://example.com/
  • Removendo a porta padrão. Um componente de porta vazio ou padrão do URI (porta 80 para o http esquema) com seu delimitador ":" deve ser removido. Exemplo:
http://example.com:80/ → http://example.com/

Normalizações que geralmente preservam a semântica

Para URIs http e https, as seguintes normalizações listadas no RFC 3986 podem resultar em URIs equivalentes, mas não são garantidos pelos padrões:

  • Adicionando um "/" final a um caminho não vazio. Os diretórios (pastas) são indicados com uma barra final e devem ser incluídos nos URIs. Exemplo:
http://example.com/foo → http://example.com/foo/
No entanto, não há como saber se um componente do caminho URI representa um diretório ou não. A RFC 3986 observa que, se o URI anterior redirecionar para o URI posterior, isso é uma indicação de que eles são equivalentes.

Normalizações que mudam a semântica

Aplicar as seguintes normalizações resulta em um URI semanticamente diferente, embora possa se referir ao mesmo recurso:

  • Removendo índice de diretório. Os índices de diretório padrão geralmente não são necessários em URIs. Exemplos:
http://example.com/default.asp → http://example.com/
http://example.com/a/index.html → http://example.com/a/
  • Removendo o fragmento. O componente de fragmento de um URI nunca é visto pelo servidor e às vezes pode ser removido. Exemplo:
http://example.com/bar.html#section1 → http://example.com/bar.html
No entanto, os aplicativos AJAX freqüentemente usam o valor no fragmento.
  • Substituindo IP por nome de domínio. Verifique se o endereço IP mapeia para um nome de domínio. Exemplo:
http://208.77.188.166/ → http://example.com/
A substituição reversa raramente é segura devido aos servidores virtuais da web .
  • Limitando protocolos. Limitando protocolos de camada de aplicativo diferentes . Por exemplo, o esquema “https” pode ser substituído por “http”. Exemplo:
https://example.com/ → http://example.com/
  • Removendo barras duplicadas Os caminhos que incluem duas barras adjacentes podem ser convertidos em uma. Exemplo:
http://example.com/foo//bar.html → http://example.com/foo/bar.html
  • Removendo ou adicionando “www” como o primeiro rótulo de domínio. Alguns sites operam de forma idêntica em dois domínios da Internet: um cujo rótulo menos significativo é “www” e outro cujo nome é o resultado da omissão do rótulo menos significativo do nome do primeiro, sendo o último conhecido como domínio simples . Por exemplo, http://www.example.com/ e http://example.com/ pode acessar o mesmo site. Muitos sites redirecionar o usuário da www para o endereço não-www ou vice-versa. Um normalizador pode determinar se um desses URIs redireciona para o outro e normalizar todos os URIs apropriadamente. Exemplo:
http://www.example.com/ → http://example.com/
  • Classificando os parâmetros de consulta. Algumas páginas da web usam mais de um parâmetro de consulta no URI. Um normalizador pode classificar os parâmetros em ordem alfabética (com seus valores) e remontar o URI. Exemplo:
http://example.com/display?lang=en&article=fred → http://example.com/display?article=fred&lang=en
No entanto, a ordem dos parâmetros em um URI pode ser significativa (isso não é definido pelo padrão) e um servidor da web pode permitir que a mesma variável apareça várias vezes.
  • Removendo variáveis ​​de consulta não utilizadas. Uma página pode esperar apenas que determinados parâmetros apareçam na consulta; parâmetros não utilizados podem ser removidos. Exemplo:
http://example.com/display?id=123&fakefoo=fakebar → http://example.com/display?id=123
Observe que um parâmetro sem um valor não é necessariamente um parâmetro não utilizado.
  • Removendo parâmetros de consulta padrão. Um valor padrão na string de consulta pode ser processado de forma idêntica, esteja lá ou não. Exemplo:
http://example.com/display?id=&sort=ascending → http://example.com/display
  • Removendo o "?" quando a consulta está vazia. Quando a consulta está vazia, pode não haver necessidade de "?". Exemplo:
http://example.com/display? → http://example.com/display

Normalização baseada em listas de URI

Algumas regras de normalização podem ser desenvolvidas para sites específicos examinando listas de URI obtidas de rastreamentos anteriores ou logs de servidor da web. Por exemplo, se o URI

http://example.com/story?id=xyz

aparece em um log de rastreamento várias vezes junto com

http://example.com/story_xyz

podemos assumir que os dois URIs são equivalentes e podem ser normalizados para um dos formulários de URI.

Schonfeld et al. (2006) apresentam uma heurística chamada DustBuster para detecção de regras DUST (URIs diferentes com texto semelhante) que podem ser aplicadas a listas de URIs. Eles mostraram que, uma vez que as regras DUST corretas foram encontradas e aplicadas com um algoritmo de normalização, eles foram capazes de encontrar até 68% dos URIs redundantes em uma lista de URIs.

Veja também

Referências