O que a barra dupla significa em URLs?


32

O que as barras duplas frequentemente encontradas nos URLs significam exatamente?

Por exemplo:

  • http://www.example.com/A/B//C/

Observe que não estou me referindo ao começo logo depois http:.

Respostas:


32

Isso é um erro no código dos programadores / desenvolvedores. Se você comparar esses dois URLs:

  • http://www.example.com/A/B/C/
  • http://www.example.com/A/B//C/

Eles parecem diferentes, mas se você fosse visitá-los, ambos funcionariam nos navegadores mais modernos.

Isso é algo que você deseja corrigir. Se você tiver a barra dupla, isso poderá confundir os rastreadores da Web do Google e fazê-los pensar que existem duas versões da página.


11
Na verdade, o carregamento da página não tem nada a ver com o navegador , mas o servidor ignora a barra extra. Isso demorou muito, então veja a resposta que eu postei.
precisa saber é o seguinte

33

Conforme mencionado por @RandomBen , a barra dupla é provavelmente o resultado de um erro em algum lugar.

O carregamento da página não tem nada a ver com o navegador , mas o servidor ignora a barra extra. O navegador não faz nada de especial com barras extras no URL, apenas as envia na solicitação:

GET /A/B//C/D HTTP/1.1
Host: www.example.com
...

Parece que as versões atuais do Apache e do IIS ignoram as barras extras ao resolver o caminho e retornam o documento que seria retornado se a URL não tivesse barras extras. No entanto , os navegadores (testei o IE 8 e o Chrome 9) ficam confusos com qualquer URL relativo (contendo componentes do caminho pai) de recursos na página, o que produz resultados ruins. Por exemplo, se uma página tiver:

<link rel="stylesheet" href="../../style.css" type="text/css" />

Ao carregar a página /a/b/c/, o navegador solicitará /a/style.css. Mas se, por qualquer motivo, /a/b//c/for solicitado (e o servidor ignorar a barra extra), o navegador acabará solicitando /a/b/style.css, o que não existirá. Ops, a página parece feia.

(Isso obviamente não acontecerá se o URL não tiver um componente de caminho pai ( ..) ou for absoluto.)

É minha opinião que o Apache e IIS (e provavelmente outros) estão agindo incorretamente como /a/b/c/e /a/b//c/tecnicamente representam dois recursos diferentes. De acordo com a RFC 2396 , cada barra é significativa:

  path          = [ abs_path | opaque_part ]

  path_segments = segment *( "/" segment )
  segment       = *pchar *( ";" param )
  param         = *pchar

  pchar         = unreserved | escaped |
                  ":" | "@" | "&" | "=" | "+" | "$" | ","

Portanto, /a/b/c/consiste em três segmentos: "a", "b" e "c"; /a/b//c/na verdade consiste em quatro: "a", "b", "" (a sequência vazia) e "c". Se a cadeia vazia é ou não um diretório de sistema de arquivos válido é um detalhe da plataforma do servidor. (E logicamente, isso significa que os navegadores estão realmente operando corretamente ao analisar URLs relativos com componentes do caminho pai - no meu exemplo, eles passam além do diretório "c" e do diretório "", deixando-nos solicitar style.css"b".)

Se você estiver usando o Apache mod_rewrite, há uma correção bem simples :

# remove multiple slashes anywhere in url 
RewriteCond %{REQUEST_URI} ^(.*)//(.*)$ 
RewriteRule . %1/%2 [R=301,L] 

Isso emitirá um 301 Moved Permanentlyredirecionamento HTTP, para que quaisquer barras duplas sejam removidas da URL.


2
Não seria melhor que sua mod_rewritesolução levasse em conta 3, 4, ... barras também? Algo ao longo das linhas de /{2,}? (Assumindo Apache permite esse tipo de quantificador, eu não estou muito familiarizado com ele)
Ward Muylaert

+1 - Obrigado pela informação extra. Eu não pensei dessa maneira!
Ben Hoffman

3
Não é um comportamento incorreto : a/be, de a//bfato, existem dois caminhos de URL distintos, mas nada proíbe o servidor de retornar o mesmo recurso para os dois, se desejar. No entanto, concordo com você que, na prática, retornar um redirecionamento 301 pareceria mais útil.
Ilmari Karonen

4
@IlmariKaronen: É absolutamente um comportamento incorreto porque (1) esse comportamento cria automaticamente um número infinito de possíveis referências duplicadas a um único recurso (que, se não viola a letra de qualquer especificação, certamente viola o espírito) e mais praticamente (2) "quebra" a manipulação do caminho relativo em navegadores que contam adequadamente a cadeia vazia a//bcomo um diretório (veja o exemplo da folha de estilo acima).
precisa saber é o seguinte

1
... e mesmo assim, eu diria que a RFC 2396 não proíbe um servidor de retornar o mesmo recurso por barras-colapso auto porque a especificação diz que cada barra é significativo. Ignorar automaticamente barras consecutivas viola essa especificação. (É uma coisa se alguém programado o respectivo servidor para fazer isso, mesmo que isso seria tolo No entanto, os servidores que fazem isso por padrão. É incorreto.)
josh3736

4

A barra dupla tem um significado quando é usada nos URLs de recursos. Por exemplo, quando é usuário em CSS para um URL de uma imagem de plano de fundo:

.classname {
    background : url("//example.com/a/b/c/d.png");
}

Aqui, significa que esta imagem de plano de fundo está sendo buscada em um domínio diferente do domínio da página da web atual. Ou, em outras palavras, http://pode ser escrito exatamente //quando usado nos URLs dos recursos.

Mas essa barra dupla entre os URLs (por exemplo /a//b/c/d.htm:) não tem nenhum significado.


bem, isso não é verdade. A barra dupla é usada quando é necessário evitar problemas de conteúdo misto; portanto, quando o site é carregado a partir de http, a barra dupla se expande para http, quando o site é carregado a partir de https:// https://goo.gl/fb/fxfx
Andrej

2

Como mencionado, alguns servidores estão configurados para ignorar uma barra dupla no caminho da URL, mas a hospedagem estática do Amazon S3 não. Se você quiser manipulá-los / ignorá-los nesse caso, poderá usar as Regras de redirecionamento no painel de propriedades.

Se você deseja ignorar uma barra dupla após o nome do domínio, use algo como isto:

<RoutingRules>
  <RoutingRule>
    <Condition>
      <KeyPrefixEquals>/</KeyPrefixEquals>
    </Condition>
    <Redirect>
      <ReplaceKeyPrefixWith/>
    </Redirect>
  </RoutingRule>
</RoutingRules>

Você provavelmente também pode encontrá-los e substituí-los por toda parte, mas isso foi o suficiente para mim.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.