En Internet buscamos páginas web por su dominio, que en nuestro caso es adslzone.net. Pero en realidad, lo que se esconde detrás de esto es la dirección IP del servidor en que están alojados los archivos correspondientes a la página web. La ‘transformación’ del dominio –que introducimos y vemos- a esa dirección IP, que es casi como una ‘traducción’, se hace gracias a los servidores DNS que almacenan el emparejamiento entre IPs y dominios. Pero en el caso de localhost, contenido almacenado de forma local, es diferente.
En este caso, localhost está asociado a la IP 127.0.0.1. Que no es una dirección IP al uso, sino que es una dirección que genera un bucle invertido. Es decir, es una auto referencia que provoca que se sirva el contenido almacenado de forma local en caso de que haya un servidor en funcionamiento, o sencillamente un error. Si ponemos ‘localhost’ en el navegador web nos devolverá un error, y exactamente lo mismo ocurre si escribimos esta dirección IP. El problema, como apuntan desde Google, está en que localhost pueda apuntar a una dirección IP externa.
Google quiere ‘cerrar’ localhost a una única IP: 127.0.0.1
Hay APIs que sí hacen diferencia entre localhost y la dirección IP 127.0.0.1 que antes comentábamos. Aquí es donde entra en juego la protesta de Google y la solicitud de modificación de los estándares actuales. Y es que la norma actual permite que localhost haga referencias externas y se envíe a servidores DNS que ‘pueden devolver resultados inesperados sin un bucle inverso’ como el de esta dirección IP especial. Supone un problema de seguridad, en tanto que el desarrollo web con localhost, sin dependencias de servidores web remotos, se considera un entorno seguro y podría no llegar a serlo dado este problema en los antiguos estándares.
Google quiere que se modifiquen los estándares para garantizar la seguridad del desarrollo web en un servidor local, en el uso de localhost como nombre de servidor, o de la dirección IP 127.0.0.1 que devuelve un ‘loopback’. Es decir, que pretenden eliminar la diferenciación entre ambos por parte de determinadas APIs, porque la norma actual permite que servidores externos puedan dar respuesta a solicitudes de localhost, que debería ser local siempre.