url com múltiplas barras, quebra alguma coisa?

http://example.com/something/somewhere//somehow/script.js 

A barra dupla quebra alguma coisa no lado do servidor? Eu tenho um script que analisa URLs e eu queria saber se ele iria quebrar alguma coisa (ou mudar o caminho) se eu substituímos várias barras por uma única barra. Especialmente no lado do servidor, algumas estruturas como o CodeIgniter e o Joomla usam esquemas e roteamento de URL segmentados. Eu gostaria apenas de saber se isso quebra alguma coisa.

HTTP RFC 2396 define o separador de caminho como uma barra simples .

No entanto, a menos que você esteja usando algum tipo de reescrita de URL (nesse caso, as regras de reescrita podem ser afetadas pelo número de barras), o uri mapeia para um caminho no disco, mas em (mais?) Sistemas operacionais modernos (Linux / Unix, Windows), vários separadores de caminho em uma linha não têm nenhum significado especial, portanto, / path / to / foo e / path // para //// foo eventualmente mapeariam para o mesmo arquivo.

Uma coisa adicional que pode ser afetada é o cache. Como o navegador e o servidor armazenam em cache páginas individuais (de acordo com as configurações de armazenamento em cache), solicitar o mesmo arquivo várias vezes por meio de URIs ligeiramente diferentes pode afetar o armazenamento em cache (dependendo da implementação do cliente e do servidor).

As URLs não precisam mapear para os caminhos do sistema de arquivos. Portanto, mesmo que // em um caminho do sistema de arquivos seja equivalente a /, você não pode garantir que o mesmo seja verdadeiro para todos os URLs.

A resposta correta para essa pergunta é que depende da implementação do servidor !

Prefácio: O Double-slash é sintaticamente válido de acordo com o RFC 2396, que define a syntax do caminho do URL. Como a amn explica, implica, portanto, um segmento URI vazio. No entanto, observe que a RFC 2396 define apenas a syntax , e não a semântica de caminhos, incluindo segmentos de caminho vazio, portanto, cabe ao seu servidor decidir a semântica do caminho vazio.

Você não mencionou a pilha de softwares de servidor que está usando, talvez você esteja usando seus próprios resources? Então, por favor, use sua imaginação sobre o que a semântica poderia ser!

Praticamente, eu gostaria de apontar algumas razões diárias relacionadas à semântica, o que significa que você deve evitar barras duplas, mesmo que elas sejam sintaticamente válidas:

  1. Como o vazio válido não é esperado por todos, pode causar bugs. E mesmo que sua tecnologia de servidor de hoje possa ser compatível com ela, a sua tecnologia de servidor de amanhã ou a próxima versão de sua tecnologia de servidor de hoje pode decidir não suportá-la mais. Exemplo: A biblioteca da API da Web ASP.NET MVC gera um erro quando você tenta especificar um modelo de rota com uma barra dupla.

  2. Alguns servidores podem interpretar // como indicando o caminho da raiz. Isso pode ser de propósito ou um bug – e então provavelmente é um bug de segurança, isto é, uma vulnerabilidade de travessia de diretório.

  3. Como às vezes é um bug e um bug de segurança, algumas pilhas de servidores e firewalls inteligentes verão a subcadeia ‘//’, deduz que você está possivelmente tentando explorar esse bug e, portanto, eles retornarão 403 Forbidden ou 400 Bad Request etc, e se recusar a realmente fazer qualquer processamento adicional do URI.

Considere a declaração do path-absolute não path-absolute relevante do path-absolute em “RFC3986: Identificador Uniforme de Recursos (URI): Sintaxe Genérica” (especificado, como é típico, na syntax ABNF ):

 path-absolute = "/" [ segment-nz *( "/" segment ) ] 

Em seguida, considere a declaração do segment algumas linhas mais abaixo no mesmo documento:

 segment = *pchar 

Se você pode ler ABNF, o asterisco ( * ) especifica que o seguinte elemento pchar pode ser repetido várias vezes para compor um segment , incluindo zero vezes . Aprendendo isso e relendo a declaração path-absolute acima, você pode ver que um segment potencialmente vazio implica que o segundo "/" pode se repetir indefinidamente , permitindo assim combinações válidas como ////// (comprimento arbitrário de pelo menos um / ) como parte do path-absolute (que é usado para especificar a regra que descreve um URI).

Como todas as URLs são URIs, podemos concluir que sim, as URLs são permitidas várias barras consecutivas, por RFC.

Mas não é como se todos seguissem ou implementassem analisadores de URI por especificação, por isso tenho quase certeza de que existem analisadores de URL / URI não compatíveis e todos os tipos de software que se acumulam sobre eles, onde esses casos quebram sistemas maiores.

Uma coisa que você pode querer considerar é que isso pode afetar sua indexação de página em um mecanismo de pesquisa. De acordo com esta página web,

Um URL com o mesmo caminho repetido 3 vezes não será indexado no Google

O exemplo que eles usam é:

 example.com/path/path/path/ 

Eu não confirmei isso também seria verdade se você usou example.com/// , mas eu certamente gostaria de descobrir se a otimização de SEO foi fundamental para o meu site.

Eles mencionam que “isso acontece porque o Google acha que atingiu uma armadilha de URL”. Se alguém souber a resposta com certeza, por favor, adicione um comentário a esta resposta; caso contrário, considero relevante include este caso para consideração.

Sua pergunta é “quebra tudo”. Em termos de especificação de URL, não funciona. Não leia o RFC, aqui está uma experiência rápida que você pode experimentar:

 cat > tmp.php < <'EOF'  

Agora abra seu navegador para http: // localhost: 4000 / hello // world

Você pode se surpreender, por exemplo, ao criar links para resources no seu aplicativo.

  

não vai resolver para mysite.com/resources/angular/script.js mas para mysite.com/resources/jquery/angular/script.js que você provavelmente não queria

As barras duplas são más, tente evitá-las.