¿Por qué las URL de archivo comienzan con 3 barras inclinadas?

HTTP comienza con dos barras inclinadas. Por ej http://example.com.

Lo mismo vale para FTP. Por ej ftp://example.com.

Sin embargo, las "URL" de archivo comienzan con tres barras inclinadas. Por ejemplo, al leer un archivo pdf usando Chrome, la URL sería file:///D:/Desktop/Book.pdf.

¿Por qué las URL de archivo usan tres barras inclinadas?

Como otros han mencionado, el esquema del archivo tiene la forma "archivo: // <host> / <path>". Aunque la mayoría de los navegadores no tendrán problemas con solo dos barras, y con razón.

En igualdad de condiciones, la barra diagonal triple y la palabra clave "localhost" solo existen para garantizar la conformidad con la sintaxis URI / URL válida. En el contexto del esquema de archivo, el host no tiene sentido ya que se carga directamente desde un sistema de archivos sin ningún protocolo de transferencia explícito o ruta de documentos del servidor. Como no es HTTP, no se puede cargar desde un servidor web estándar donde, en teoría, podría tener múltiples hosts virtuales locales configurados. Y no se puede cargar desde un volumen de red estándar que técnicamente es otro "host", ya que el navegador solo usa el nombre del volumen como "file: /// volume / foo". Finalmente, probar cosas como "file: //example.com/some/file" no funciona. Probablemente haya alguna razón para admitir un host externo, pero no se me ocurre ninguna.

El IETF actualmente está redactando cambios para eliminar el requisito de triple barra, aunque el borrador también agrega algunas posibilidades extrañas como file:c|/pathe incluso file://///host.example.com/path.

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

"3. Esta especificación no define ni prohíbe un mecanismo para acceder a archivos no locales".

La sintaxis completa es file://host/path.

Si el host es localhost, se puede omitir, lo que resulta en file:///path.

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

La URL de un archivo toma la forma:

file://<host>/<path>

[...]

Como caso especial, <host>puede ser la cadena "localhost" o la cadena vacía; esto se interpreta como "la máquina desde la cual se interpreta la URL".

Dennis ha explicado la 3a barra, necesaria para separar la hostde la path, pero las otras dos son mucho más interesantes ...

Resulta que eran una adición inútil y algo arbitraria a la sintaxis de URL. Tim Berners-Lee, inventor de la World Wide Web y autor de muchos de sus estándares (incluido el RFC al que Dennis se vinculó), lamentó su uso del 'doble corte' en una entrevista en 2009.

El doble corte, aunque era una convención de programación en ese momento, resultó no ser realmente necesario, explicó Berners-Lee. Mire todo el papel y los árboles, dijo, que podrían haberse salvado si la gente no hubiera tenido que escribir o escribir esas barras en papel a lo largo de los años, sin mencionar el trabajo humano y el tiempo dedicado a escribir esas dos pulsaciones de teclas innumerables millones de veces en los cuadros de direcciones del navegador.

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

Entonces, salvo por un lapso menor (y poco característico) en previsión hace unos 18 años, la URL de su archivo podría haber sido fácilmente file:/D:/Desktop/Book.pdf, en lugar de hacerlo file:///D:/Desktop/Book.pdf.

Para responder a su pregunta, no hay una buena razón por la cual las URL tienen 3 barras diagonales.

Actualización: como @ComFreek señala en los comentarios, a partir de 2017, ¡el file:/D:/...ejemplo anterior ahora es válido! Esto es gracias a RFC 8089 , que específicamente llama a esta corrección del estándar anterior ...

Según la definición en [RFC1738], la URL de un archivo siempre comenzó con el token "file: //", seguido de un nombre de host (opcionalmente en blanco) y un "/". La sintaxis dada en la Sección 2 hace que todo el componente de autoridad, incluidas las barras diagonales "//", sea opcional.

Qué tiempo para estar vivo.