@AlvarPaalberg's réponse donne une vue antérieure
Il y a des RFCs ultérieurs qui, je pense, s'ajoutent à cela.
Celui que j'ai trouvé est RFC7230 définissant le protocole http. Cela comprend
Un expéditeur ne doit pas générer un URI "http" avec un identifiant d'hôte vide. vide. Un destinataire qui traite une telle référence URI DOIT la rejeter comme étant invalide.
Aussi RFC3986
Si le schéma URI définit une valeur par défaut pour l'hôte, cette valeur par défaut est la suivante s'applique lorsque le sous-composant host n'est pas défini ou lorsque le paramètre nom enregistré est vide (longueur zéro). Par exemple, le schéma URI "file "file" est défini de manière à ce qu'aucune autorité, un hôte vide, et et "localhost" signifient tous la machine de l'utilisateur final, alors que le schéma "http" considère considère qu'une autorité manquante ou un hôte vide ne sont pas valides.
A partir de là, je pense que tous les navigateurs sont incorrects. Ils devraient rejeter l'URL comme étant invalide. Les navigateurs en général n'ont jamais aimé rapporter des erreurs pour le html invalide ou autre chose, donc ils décident ce qu'ils pensent que l'utilisateur a tapé et l'utilisent à la place.
Safari a choisi un point de vue différent de celui des autres. (Il a utilisé la règle pour le schéma file : - ce qui, je suppose, est dû au fait que les développeurs de Safari sont plus intégrés avec les développeurs du système d'exploitation que ce n'est le cas pour les autres navigateurs. Les API du système MacOS utilisent les URL des fichiers pour la plupart des opérations sur les fichiers).
