El señor Tim Berners-Lee, considerado el padre de la web, comentaba hace unos años que si se hubiera tenido que pensar en ese momento rehacer internet hubiera eliminado las (//) de las URL’s que ahora conocemos. Probablemente en algún universo paralelo haya civilizaciones más avanzadas debido al tiempo ahorrado en ponerla 😀
Hemos de reconocer que están ahí y que aunque actualmente los navegadores actuales las incluyen automáticamente, las URL’s no serían lo mismo aunque probablemente nuestros trabajos como desarrolladores web serían más sencillos 😀
Si has tenido que trabajar con URL’s seguras y no seguras en aplicaciones que las compartan sabrás, ahora mismo, de que problema te quiero hablar. Exacto, del problema de gestión del protocolo de las URL’s en nuestro código.
Protocolo HTTP y HTTPS
El protocolo HTTP, el que todos conocemos nos permite conectarnos a URL’s de internet desde un cliente remoto, y las peticiones HTTPS, funcionan exactamente igual pero usando un certificado SSL para validar que la conexión entre el cliente y el servidor está encriptada.
Para más info, Wikipedia 😀
Los que hemos desarrollado aplicaciones en la que ha de haber partes seguras y parte que pueden no serlo, sabrán que cuando estás en HTTPS, todas las peticiones que lanza el cliente deben ser HTTPS. Sino lo son, el navegador nos suele avisar con un mensaje de que en un entorno seguro se está accediendo a contenido no seguro.
(Ver Imagen)
Esto ha provocado, durante mucho tiempo, tener que usar variables con el protocolo para detectarlo en todo momento y así adaptar el HTML resultante al protocolo seguro o no seguro de toda la página.
<?php
$protocolo = strpos(strtolower($_SERVER['SERVER_PROTOCOL']),'https') === FALSE ? 'http' : 'https'
?>
<html>
<head>
<link rel="stylesheet" href="<?=$protocolo?>://midominio/micss.css" />
</head>
<body>
<a href="<?=$protocolo?>://midominio/minuevoenlace">Me voy</a>
</body>
</html>
Aunque hay técnicas más depuradas, para ilustrar el ejemplo nos vale, y ya podemos ver el trabajo que tenemos que hacer para controlar los protocolos de nuestras rutas. A simple vista ya podemos hacernos una idea de lo problemático que resulta atajar este problema en una aplicación medianamente compleja.
El protocolo relativo
Pues si ya has llegado por aquí, y no sabes que es el protocolo relativo, se te va a quedar una cara de tonto como la que se me quedó a mi hace unos días.
El protocolo relativo, es la capacidad que tienen los navegador web de definir automáticamente el protocolo de los elementos de una página en función del protocolo de entrada, osea que él navegador solo se encargaría automáticamente de gestionar esto por nosotros O.O!. Pero, ¿como!!?
Ya en 2010, Paul Irish publicaba ya alguna cosilla sobre el tema, aunque por aquel entonces, a mi por lo menos, se me pasó. Y el sistema es bastante lógico, ya que simplemente tendremos que usar una doble barra (//) y ya está O.O!
Veamos un ejemplo:
<html>
<head>
<link rel="stylesheet" href="//midominio/micss.css" />
</head>
<body>
<a href="//midominio/minuevoenlace">Me voy</a>
</body>
</html>
Sencillo, límpio y lo más importante funciona!
¿Pero esto de donde viene?
Pues, aquí viene lo realmente sorprendente. Esto está definido el estándar RFC-1808 Sección 2.1, publicado en Junio del 1995 y en la RFC-3986 Sección 4.2 de Enero de ese mismo año. Osea, que hace casi 17 años que está definido! O.O!
¿Que navegadores lo interpretan?
Pues, teniendo en cuenta que hace 17 años que está vigente todos los navegadores actuales permiten usar esta nomenclatura, aunque aún debe de quedar algún IE4 o 5 que parecen no haber llegado a tiempo de implementarlo.
Actualización:Nacho Plaza me recuerda que esto mismo ya lo estuvimos hablando hace 2 años… me estoy haciendo mayor. Gracias Nacho!
