Quando devo usar uma barra no meu URL?

Quando deve ser usada uma barra final em um URL? Por exemplo, o meu URL deve ser semelhante a /about-us/ or like /about-us ?

Eu estou totalmente ciente das questões relacionadas a SEO – conteúdo duplicado e a coisa canônica; Eu estou tentando descobrir qual deles devo usar no contexto de servir as páginas corretamente sozinho.

Por exemplo, meu colega está pensando que uma barra no final significa que é uma “pasta” – um “diretório”, portanto, esse não é um estilo correto. Mas eu acho que sem uma barra no final – não é muito correto também, porque quase parece uma pasta, mas não é e também não é um arquivo normal, mas um nome de arquivo sem extensão.

Existe uma maneira adequada de saber qual usar?

Na minha opinião pessoal, barras cortantes são mal utilizadas.

Basicamente, o formato da URL veio do mesmo formato UNIX de arquivos e pastas, posteriormente, em sistemas DOS e, finalmente, adaptado para a web.

Um URL típico para este livro em um sistema operacional semelhante ao Unix seria um caminho de arquivo como file: ///home/username/RomeoAndJuliet.pdf, identificando o livro eletrônico salvo em um arquivo em um disco rígido local.

Fonte: Wikipedia: Identificador Uniforme de Recursos

Outra boa fonte para ler: Wikipedia: Esquema de URI

De acordo com a RFC 1738, que definiu URLs em 1994, quando os resources contêm referências a outros resources, eles podem usar links relativos para definir a localização do segundo recurso como se dissessem “no mesmo local que este, exceto com o seguinte relativo caminho”. Ele passou a dizer que tais URLs relativos são dependentes da URL original contendo uma estrutura hierárquica contra a qual o link relativo é baseado, e que os esquemas de FTP, http e file URL são exemplos de alguns que podem ser considerados hierárquicos, com o componentes da hierarquia sendo separados por “/”.

Fonte: Localizador Uniforme de Recursos (URL) da Wikipedia

Além disso:

Essa é a pergunta que ouvimos com frequência. Avante para as respostas! Historicamente, é comum que os URLs com uma barra final indiquem um diretório e aqueles sem barra para indicar um arquivo:

http://example.com/foo/ (com barra final, convencionalmente um diretório)

http://example.com/foo (sem barra final, convencionalmente, um arquivo)

Fonte: Google WebMaster Central Blog – Para cortar ou não cortar

Finalmente:

  1. Uma barra no final do URL faz o endereço parecer “bonito”.

  2. Um URL sem uma barra no final e sem uma extensão parece um pouco “estranho”.

  3. Você nunca irá nomear seu arquivo CSS (por exemplo) http://www.sample.com/stylesheet/ você?

MAS estou sendo um defensor das melhores práticas da Web, independentemente do ambiente. Pode ser incerto e pouco claro, assim como você disse sobre o URL sem ext.

Não é uma questão de preferência. /base e /base/ têm semânticas diferentes. Em muitos casos, a diferença não é importante. Mas é importante quando existem URLs relativos.

  • child relação a /base/ is /base/child .
  • child relação a /base é (talvez surpreendentemente) /child .

Eu sempre me surpreendo com o uso extensivo de barras à direita em URLs que não são de diretório (WordPress, entre outros). Isso realmente não deveria ser um ou outro debate, porque colocar uma barra após um recurso é semanticamente errado. A Web foi projetada para fornecer resources endereçáveis ​​e esses endereços – URLs – foram projetados para emular uma hierarquia de sistema de arquivos no estilo * nix. Nesse contexto:

  • Barras sempre denotam diretórios, nunca arquivos.
  • Os arquivos podem ter qualquer nome (com ou sem extensões), mas não podem conter ou terminar com barras.

Usando essas diretrizes, é errado colocar uma barra após um recurso que não é de diretório.

Isso não é realmente uma questão de estética, mas sim uma diferença técnica. O diretório pensando nisso é totalmente correto e praticamente explicando tudo. Vamos resolver isso:

Você está de volta à idade da pedra agora ou apenas serve páginas estáticas

Você tem uma estrutura de diretórios fixa em seu servidor web e apenas arquivos estáticos como imagens, html e assim por diante – nenhum script do lado do servidor ou qualquer outro.

Um navegador solicita /index.htm , ele existe e é entregue ao cliente. Mais tarde, você terá muitos – digamos – filmes em DVD revisados ​​e uma página em HTML para cada um deles no diretório /dvd/ . Agora alguém solicita /dvd/adams_apples.htm e ele é entregue porque está lá.

Em algum dia, alguém apenas solicita /dvd/que é um diretório e o servidor está tentando descobrir o que entregar. Além das restrições de access e assim por diante, há duas possibilidades: Mostrar ao usuário o conteúdo do diretório (aposto que você já viu isso em algum lugar) ou mostrar um arquivo padrão (no Apache é: DirectoryIndex: sets the file that Apache will serve if a directory is requested. )

Até aí tudo bem, esse é o caso esperado. Ele já mostra a diferença no manuseio, então vamos entrar nisso:

Às 05:34 você cometeu um erro ao enviar seus arquivos

(Que é completamente compreensível.) Então, você fez algo totalmente errado e ao invés de fazer o upload de /dvd/the_big_lebowski.htm você carregou esse arquivo como dvd (sem extensão) para / .

Alguém marcou sua listview de diretórios /dvd/ (é claro que você não quis criar e sempre atualiza o nifty index.htm ) e está visitando o seu site. O conteúdo do diretório é entregue – tudo bem.

Alguém ouviu falar da sua lista e está digitando /dvd . E agora está ferrado. Em vez de listar o diretório de DVD, o servidor encontra um arquivo com esse nome e está entregando seu arquivo Big Lebowski.

Então, você exclui esse arquivo e diz ao cara para recarregar a página. Seu servidor procura o arquivo /dvd , mas ele desapareceu. A maioria dos servidores notará que existe um diretório com esse nome e informará ao cliente que o que ele estava procurando está realmente em outro lugar. A resposta provavelmente será:

Status Code:301 Moved Permanently com a Location: http://[...]/dvd/

Então, ignorando totalmente o que você pensa sobre diretórios ou arquivos, o servidor só pode lidar com essas coisas e – a menos que seja dito de forma diferente – decide sobre o significado de “barra ou não”.

Finalmente, depois de receber esta resposta, o cliente carrega /dvd/ e está tudo bem.

Está bom? Não.

“Muito bem” não é bom o suficiente para você

Você tem uma página dinâmica em que tudo é passado para /index.php e é processado. Tudo funcionou muito bem até agora, mas a coisa toda começa a parecer mais lenta e você investiga.

Logo, você notará que /dvd/list está fazendo exatamente o mesmo: Redirecionando para /dvd/list/ que é então traduzido internamente para index.php?controller=dvd&action=list . Um pedido adicional – mas ainda pior! customer/login redireciona para o customer/login/ que, por sua vez, redireciona para o URL HTTPS de customer/login/ . Você acaba tendo muitos redirecionamentos HTTP desnecessários (= solicitações adicionais) que tornam a experiência do usuário mais lenta.

O mais provável é que você também tenha um índice de diretório padrão aqui: index.php?controller=dvd sem action simplesmente carrega internamente index.php?controller=dvd&action=list .

Resumo:

  • Se terminar com / , nunca poderá ser um arquivo. Nenhum servidor adivinhando.

  • Slash ou não slash são significados totalmente diferentes. Existe uma diferença técnica / recurso entre “barra ou não barra”, e você deve estar ciente disso e usá-lo de acordo. Só porque o servidor provavelmente carrega /dvd/index.htm – ou carrega o material correto do script – quando você diz /dvd : ele faz isso, mas não porque você fez o pedido correto. Qual teria sido /dvd/ .

  • Omitir a barra mesmo que você realmente queira dizer que a versão barra lhe dá uma penalidade de solicitação HTTP adicional. O que é sempre ruim (pense na latência móvel) e tem mais peso do que uma “URL bonita” – especialmente porque os rastreadores não são tão burros quanto os SEOs acreditam ou querem que você acredite;)

Quando você cria seu URL /about-us/ (com a barra final), é fácil começar com um único arquivo index.html e depois expandi-lo e adicionar mais arquivos (por exemplo, our-CEO-john-doe.jpg ) ou até criar uma hierarquia sob ela (por exemplo, /about-us/company/ , /about-us/products/ , etc.) conforme necessário, sem alterar o URL publicado . Isso lhe dá uma grande flexibilidade.

Quem diz que um nome de arquivo precisa de uma extensão? dê uma olhada em uma máquina * nix em algum momento …
Eu concordo com o seu amigo, sem barra.

Outras respostas aqui parecem favorecer a omissão da barra final. Há um caso em que uma barra à direita ajudará na otimização do mecanismo de busca (SEO). Esse é o caso de seu documento ter o que parece ser uma extensão de arquivo que não é .html . Isso se torna um problema com sites que classificam sites. Eles podem escolher entre esses dois URLs:

  • http://mysite.example.com/rated.example.com
  • http://mysite.example.com/rated.example.com/

Nesse caso, eu escolheria aquele com a barra final . Isso ocorre porque a extensão .com é uma extensão dos arquivos de comando executáveis ​​do Windows. Mecanismos de pesquisa e verificadores de vírus geralmente não gostam de URLs que parecem conter malwares distribuídos por esses mecanismos. A barra à direita parece atenuar quaisquer preocupações, permitindo que a página seja classificada nos mecanismos de pesquisa e obtida pelos verificadores de vírus.

Se seus URLs não tiverem . na parte do arquivo, então eu recomendo omitir a barra final para simplificar.

    Intereting Posts