Por que os URLs de arquivo começam com três barras?

O HTTP começa com duas barras. Por exemplo http://example.com.

O mesmo vale para o FTP. Por exemplo ftp://example.com.

No entanto, os "URLs" do arquivo começam com três barras. Por exemplo, lendo um arquivo pdf usando o chrome, o URL seria file:///D:/Desktop/Book.pdf.

Por que os URLs de arquivo usam três barras?

Como outros já mencionaram, o esquema do arquivo está no formato "file: // <host> / <caminho>". Embora a maioria dos navegadores não tenha problemas com apenas duas barras, e com razão.

Se tudo for igual, a barra tripla e a palavra-chave "localhost" existem apenas para garantir a conformidade com a sintaxe URI / URL válida. No contexto do esquema do arquivo, o host não tem sentido, pois é carregado diretamente de um sistema de arquivos sem nenhum protocolo explícito de transferência ou caminho do documento do servidor. Por não ser HTTP, ele não pode ser carregado a partir de um servidor Web padrão, onde, em teoria, você pode ter vários hosts virtuais locais configurados. E ele não pode carregar de um volume de rede padrão que é tecnicamente outro "host", já que o navegador usa apenas o nome do volume como "arquivo: /// volumes / foo". Por fim, tentar coisas como "file: //example.com/some/file" não funciona. Provavelmente há algum motivo para oferecer suporte a um host externo, mas não consigo pensar em nenhum.

Atualmente, a IETF está redigindo alterações para remover o requisito de barra tripla, embora o rascunho também adicione algumas possibilidades ímpares como file:c|/pathe par file://///host.example.com/path.

https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-03

"3. Esta especificação não define nem proíbe um mecanismo para acessar arquivos não locais".

A sintaxe completa é file://host/path.

Se o host for localhost, ele poderá ser omitido, resultando em file:///path.

Consulte RFC 1738 - Localizadores uniformes de recursos (URL) :

Uma URL de arquivo assume o formato:

file://<host>/<path>

[...]

Como um caso especial, <host>pode ser a sequência "localhost" ou a sequência vazia; isso é interpretado como 'a máquina da qual o URL está sendo interpretado'.

Dennis explicou a terceira barra, necessária para separar a hostda path, mas as outras duas são muito mais interessantes ...

Acontece que eles eram uma adição inútil e um tanto arbitrária à sintaxe da URL. Tim Berners-Lee, inventor da World Wide Web e autor de muitos de seus padrões (incluindo o RFC ao qual Dennis se vinculou), lamentou seu uso da 'barra dupla' em uma entrevista em 2009.

A barra dupla, apesar de uma convenção de programação na época, acabou não sendo realmente necessária, explicou Berners-Lee. Olhe para todo o papel e árvores, ele disse, que poderiam ter sido salvos se as pessoas não tivessem que escrever ou digitar essas barras no papel ao longo dos anos - para não mencionar o trabalho humano e o tempo gasto digitando essas duas teclas digitadas incontáveis ​​milhões de vezes nas caixas de endereço do navegador.

http://bits.blogs.nytimes.com/2009/10/12/the-webs-inventor-regrets-one-small-thing/

Portanto, exceto por um lapso menor (e pouco característico) da previsão, há cerca de 18 anos, o URL do arquivo poderia ter sido facilmente file:/D:/Desktop/Book.pdf, e não file:///D:/Desktop/Book.pdf.

Para responder à sua pergunta, não existe uma boa razão para os URLs terem três barras.

Atualização: como o @ComFreek aponta nos comentários, a partir de 2017, o file:/D:/...exemplo acima agora é válido! Isso se deve ao RFC 8089 , que especifica especificamente essa correção do padrão anterior ...

De acordo com a definição em [RFC1738], um URL de arquivo sempre começava com o token "file: //", seguido por um nome de host (opcionalmente em branco) e um "/". A sintaxe fornecida na Seção 2 torna opcional todo o componente de autoridade, incluindo as barras duplas "//".

Que hora de estar vivo.