¿Puedo cambiar todos mis enlaces http: // a solo //?

240

Dave Ward dice:

No es exactamente una lectura ligera, pero la sección 4.2 del RFC 3986 proporciona URL totalmente calificadas que omiten el protocolo (HTTP o HTTPS) por completo. Cuando se omite el protocolo de una URL, el navegador utiliza en su lugar el protocolo del documento subyacente.

En pocas palabras, estas URL "sin protocolo" permiten que una referencia como esta funcione en cada navegador en el que lo probará:

//ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js

Al principio parece extraño, pero esta URL "sin protocolo" es la mejor manera de hacer referencia al contenido de terceros que está disponible a través de HTTP y HTTPS.

Esto ciertamente resolvería un montón de errores de contenido mixto que estamos viendo en las páginas HTTP, suponiendo que nuestros activos estén disponibles a través de HTTP y HTTPS.

¿Es completamente compatible con todos los navegadores? ¿Hay alguna otra advertencia?

http  url  https  protocol-relative 
— un nerd pagado
fuente
Leí sobre esta técnica en el blog de IE hace un tiempo. Pero cuando lo intenté no funcionó bastante bien. Si mi sitio se sirvió con HTTPS, el navegador (Chrome) todavía usaba HTTP para URL sin protocolo.
— Christopher Ramírez
10
ADVERTENCIA: ¡recuerde NUNCA usar URI sin esquemas de usuario en redirecciones HTTP 3xx! Los encabezados HTTP no son compatibles con este formato de URL. Si necesita redirigir según el esquema, use mod_rewrite o similar.
— user2596282
1
@ user2596282 La experimentación en versiones modernas de Chrome y Firefox no está de acuerdo con usted, al igual que la revisión (aún en borrador) de HTTP 1.1. especificación definida por el grupo de trabajo HTTPbis (ver svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/… ). Sin embargo, quizás lo que dices es cierto para algunos navegadores; ¿conoce alguna en particular que falle en las URL relativas al protocolo en los encabezados de ubicación?
— Mark Amery
— Álvaro González
No los uses, son feos y redundantes.
— IllidanS4 quiere que Monica regrese el

Respuestas:

204

Lo probé a fondo antes de publicar. De todos los navegadores disponibles para probar en Browsershots , solo pude encontrar uno que no manejara la URL relativa del protocolo correctamente: un oscuro navegador * nix llamado Dillo .

Hay dos inconvenientes sobre los que he recibido comentarios:

  1. Las URL sin protocolo pueden no funcionar como se espera cuando "abre" un archivo local en su navegador, ya que el protocolo base de la página será file: ///. Especialmente cuando está utilizando la URL sin protocolo para un recurso externo como un activo alojado en CDN. Sin embargo, el uso de un servidor web local como Apache o IIS para probar contra las direcciones http: // localhost funciona bien.
  2. Aparentemente hay al menos una aplicación de lector de feeds de iPhone que no maneja las URL sin protocolo correctamente. No sé cuál tiene el problema o qué tan popular es. Para alojar un archivo JavaScript, no es un gran problema ya que los lectores RSS generalmente ignoran el contenido de JavaScript de todos modos. Sin embargo, podría ser un problema si está utilizando estas URL para medios como imágenes dentro del contenido que necesita ser sindicado a través de RSS (sin embargo, esta aplicación de lector único en una sola plataforma probablemente representa un número muy marginal de lectores).
— Dave Ward
fuente
33
Si bien IE7 / 8 maneja bien las URL relativas al protocolo (también conocido como URI sin esquema) en la mayoría de los casos, cuando las hojas de estilo se especifican con tales URL, las descargará dos veces . (Eso dice Steve Souders )
— lucasrizoli
3
Estoy descubriendo que IE6 intenta convertir el URI en uno relativo (es decir, eliminar una de las barras inclinadas). Esto está en un linkelemento. Por ejemplo, al especificar //fonts.googleapis.com/css?family=Rokkitt:400,700, IE6 intenta cargar http://mysite.com/fonts.googleapis.com/css/<...>. ¡No tan bien!
— CBono
2
He encontrado en mis registros instancias de lo que parecen ser robots de araña web (fuente desconocida) que intentan usar los enlaces sin protocolo y no los manejan correctamente también.
— Kzqai
3
He visto mucho de eso en mis registros, sin relación con las URL sin protocolo. Muchas de esas arañas están increíblemente mal escritas.
— Dave Ward el
11
Es importante entender que estas URL son no por protocolos de menos , pero por protocolo relativo . Obtienen su protocolo de su contexto y, al carecer de un contexto, actuarán como URL de archivos en la mayoría de los navegadores, lo que significa que interrumpen de manera efectiva que no cargarán el contenido deseado. Si bien funcionarán cuando se entreguen a través de http, descubrirá que si guarda la página y carga exactamente el mismo HTML desde un archivo local, no lo harán, porque el contexto es diferente. Los únicos contextos en los que debe usarlos son http vs https.
— Sincronización
37

La cuestión de si uno podría cambiar todos sus enlaces para que sean relativos al protocolo puede ser discutible, considerando la cuestión de si uno debería hacerlo. Según Paul Irish :

2014.12.17: Ahora que se recomienda SSL para todos y no tiene problemas de rendimiento, esta técnica ahora es un antipatrón. Si el activo que necesita está disponible en SSL, use siempre el https: // activo.

— Ohad Schneider
fuente
Estaba pensando exactamente lo mismo. ¿De qué sirve descargar un activo externo a través de http si también está disponible a través de https? Incluso si el sitio principal está utilizando http (que no debería, pero ese es otro tema).
— joonas.fi
1
@ joonas.fi lo único en lo que puedo pensar es evitar las advertencias HTTP / HTTPS mixtas que podrían generar algunos navegadores
— Ohad Schneider
3
Las advertencias de @Ohad_Schneider se activan solo si el documento se carga de forma segura (https) pero los activos no son seguros (http). Lo que sugería es que siempre puede cargar activos de forma segura, incluso si el documento se carga de forma no segura. No hay advertencia ni razón para no usar seguro, lo que hace innecesario todo el "URL relativo al protocolo".
— joonas.fi
1
@Ohad_Schneider oh lo siento, creo que interpreté mal lo que estabas diciendo. La carga de activos a través de https cuando el documento es a través de http no debería generar ninguna advertencia. Pero la carga de activos a través de http cuando su documento ha terminado es https (y probablemente esté bloqueado de forma predeterminada, al menos en Chrome). ¿Se refería al caso en el que sirve su sitio a través de https y los activos externos están disponibles solo bajo http? Sí, eso podría ser un problema, pero no creo que haya un servicio de terceros serio que no sirva su contenido a través de https, o de lo contrario deberían cerrar el negocio de todos modos. :)
— joonas.fi
@ joonas.fi Wut? O_o Si alguien tiene un protocolo HTTPSed (entonces), las URL relativas no ayudarán a resolver la obtención de activos de terceros a través de HTTP, de ninguna manera. Y de todos modos, es mejor no tener ese logotipo SSL verde limpio en su página HTTPS que devolverlo a HTTP nuevamente debido a que terceros aún no admiten HTTPS.
— poige
15

Sí, las referencias de ruta de red ya se especificaron en RFC 1808 y deberían funcionar con todos los navegadores.

— Gumbo
fuente
11
Incluso se recomienda y se usa en el código de referencia
— Felipe Lima
1
con Sí, no responde Sí a "¿Hay otras advertencias?" ? ;)
— Caspar Kleijne
2
@Caspar Kleijne: expliqué el Sí con el resto de la oración.
— Gumbo
1
Casper, Gumbo en realidad estaba respondiendo las dos preguntas: "¿Es completamente compatible con todos los navegadores? ¿Hay alguna otra advertencia?" Sí, es la respuesta a la primera pregunta.
— Darren Griffith
4

¿Es completamente compatible con todos los navegadores? ¿Hay alguna otra advertencia?

Solo para agregar esto a la mezcla, si está desarrollando en un servidor local, podría no funcionar. Debe especificar un esquema, de lo contrario, el navegador puede asumir que src="//cdn.example.com/js_file.js"es así src="file://cdn.example.com/js_file.js", lo que se romperá ya que no está alojando este recurso localmente.

Microsoft Internet Explorer parece ser particularmente sensible a esto, vea esta pregunta: No se puede cargar jQuery en Internet Explorer en localhost (WAMP)

Probablemente siempre intente encontrar una solución que funcione en todos sus entornos con la menor cantidad de modificaciones necesarias.

La solución utilizada por HTML5Boilerplate es tener un respaldo cuando el recurso no se carga correctamente, pero eso solo funciona si incorpora una verificación:

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script>
<!-- If jQuery is not defined, something went wrong and we'll load the local file -->
<script>window.jQuery || document.write('<script src="js/vendor/jquery-1.10.2.min.js"><\/script>')</script>

Publiqué esta respuesta aquí también.

ACTUALIZACIÓN: HTML5Boilerplate ahora utiliza <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js">después de decidir desaprobar las URL relativas del protocolo, consulte aquí .

— bg17aw
fuente
1

No he tenido estos problemas al utilizar: //dominio.com, pero debe agregar los dos puntos al principio. Yoast tuvo un buen artículo sobre esto hace un tiempo. Pero está perdido en su montón de publicaciones de blog.

— usuario1431784
fuente
voto negativo para no indicar dónde es útil el adicional: En todas partes accidentalmente dejé el ":" rompió el enlace
— robar el
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.