Safari inserta "localhost" en las URLs con tres barras inclinadas después del esquema

@AlvarPaalberg's respuesta da una visión anterior

Hay RFCs posteriores que creo que se suman a esto.

El que he encontrado es RFC7230 definir el protocolo http. Esto incluye

Un remitente NO DEBE generar un URI "http" con un identificador de host vacío vacío. Un receptor que procese una referencia URI de este tipo DEBE rechazarla como inválida.

También RFC3986

Si el esquema URI define un valor por defecto para el host, entonces ese valor por defecto se aplica cuando el subcomponente host no está definido o cuando el nombre registrado está vacío (longitud cero). Por ejemplo, el esquema URI "file está definido de forma que ninguna autoridad, un host vacío y "localhost" significan la máquina del usuario final, mientras que el esquema "http considera inválida una autoridad ausente o un host vacío.

A partir de ahí creo que todos los navegadores son incorrectos. Deberían rechazar la URL como inválida. Ahora los navegadores en general nunca han querido reportar errores por html inválido o cualquier otra cosa así que deciden lo que creen que el usuario escribió y usan eso en su lugar.

Safari ha elegido una visión diferente a la de los demás. (Ha utilizado la regla para el esquema file: - lo que supongo se debe a que los desarrolladores de Safari están más integrados con los desarrolladores del sistema operativo que en el caso de otros navegadores. Las APIs del sistema MacOS utilizan URLs de archivos para la mayoría de las operaciones con archivos)

Lo que ocurre cuando se introduce el texto en la barra de direcciones del navegador no está atado por ninguna especificación todavía, así que para esta situación no hay un comportamiento "incorrecto" o "correcto".

Sin embargo, en el caso de las redirecciones enviadas por el servidor en respuesta a una solicitud de obtención, el Buscar normas regla, y estas normas (§8.2 - "seguir") pregunte a que la cabecera `Location` de la respuesta se analice a través de las normas de la URL Parser de URLs algoritmo.

Este algoritmo cuando se encontrará con el tercer / en el la autoridad especial ignora las barras oblicuas del estado emitirá un error de validación pero no dejará este paso hasta que todos los subsiguientes / se encuentran (y por tanto se ignoran).

Así, el resultado de analizar una entrada como https:///////example.com debe ser

protocol: "https:"
host: "example.com"
path: "/"

Es decir, los múltiples / caracteres después de https: se ignoran.

E incluso Safari está de acuerdo en eso en otros lugares, como en el HTML <a href> como se puede ver en los enlaces de la OP.

El hecho de que no sigan esta regla para los redireccionamientos fetch es un error, y como tal, es posible que desee informar a su bug-tracker .

Se puede intentar dar respuesta a la pregunta why? pero no who is correct?

RFC 1738 - Localizadores Uniformes de Recursos (URL) :

El esquema de URL de archivos se utiliza para designar los archivos accesibles en un ordenador anfitrión concreto. Este esquema, a diferencia de la mayoría de los otros esquemas de URL no designa un recurso que sea universalmente accesible a través de Internet.

La URL de un archivo tiene la forma

    file://<host>/<path>

/../ Como caso especial, puede ser la cadena "localhost" o el vacío vacío; esto se interpreta como `la máquina desde la que se hace la URL se está interpretando'.

Así que parece que Safari considera tres barras como un caso especial de esquema de URL de archivo (cadena vacía) y sustituye la cadena vacía entre la segunda y la tercera barra por 'localhost'. Otros navegadores consideran que el usuario ha introducido una barra de más y que en realidad quiere acceder a un recurso de Internet, por lo que lo "autocorrigen".