¿Hay alguna desventaja para usar una doble barra inclinada para heredar el protocolo en una URL? es decir, src = "// dominio.com"

148

Tengo una hoja de estilo que carga imágenes de un dominio externo y la necesito para cargar desde https: // desde páginas de pedido seguras y http: // desde otras páginas, según la URL actual. Descubrí que comenzar la URL con una doble barra hereda el protocolo actual. ¿Todos los navegadores admiten esta técnica?

html ex:

<img src="//cdn.domain.com/logo.png" />

css ex:

.class { background: url(//cdn.domain.com/logo.png); }

— Rob Volk
fuente

1

¿esto ralentiza el sitio?

— TheBlackBenzKid

2

no hay razón para que esto tenga algún impacto en el rendimiento, excepto en los casos que Meder enumeró a continuación en su respuesta.

— Rob Volk

Parece que estaba haciendo algo. Hace unos meses, los desarrolladores de Google comenzaron a usar esta convención en su página de bibliotecas de Javascript Hosted developers.google.com/speed/libraries/devguide

— Rob Volk

10

¿Qué sucede si dicho archivo HTML se carga localmente (abierto directamente con el navegador)? Parece que Firefox (28 en este caso) no carga el recurso remoto. Tiene sentido, porque entonces HTTP no es el protocolo principal. Pero eso sería una desventaja, en mi opinión.

— Dr. Jan-Philip Gehrcke

86

Si el navegador admite RFC 1808 Sección 4 , RFC 2396 Sección 5.2 , o RFC 3986 Sección 5.2 , entonces utilizará el esquema de URL de la página para referencias que comienzan con "//".

— Remy Lebeau
fuente

8

¿Es compatible con todos los principales navegadores? (IE7, IE8, FF, Chrome, Safari)

— Rob Volk

22

Teniendo en cuenta que el primer RFC que lo describió, RFC 1808, se escribió hace 15 años, y las referencias de URL son clave para la funcionalidad del sitio web, creo que es seguro decir que casi todos los principales navegadores ya lo admiten. Pero la única forma de saberlo con certeza es simplemente probarlo usted mismo y ver qué sucede.

— Remy Lebeau

2

Esta pregunta fue vinculada por alguien que hizo una pregunta similar, y la encontré en RFC 1630 el año anterior (dicho de otra manera, pero aún permitiendo el formato en cuestión). Bien podría haber sido de una forma u otra del documento que solía ser a ftp://info.cern.ch/pub/www/doc/http-spec.txtpartir de 1991, si alguien tuviera una copia de archivo.

— Jon Hanna

44

"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". (Cita de stackoverflow.com/a/27999789 )

— joonas.fi

@ joonas.fi Ese razonamiento es de segundo año. SSL todavía tiene un impacto en el rendimiento y no es necesario en una gran cantidad de aplicaciones. Prefiero usarlo, claro, pero no quisiera que se imponga, por ejemplo, en el código que implemente.

— Oteo

64

Cuando se usa en un linko @import, IE7 / IE8 descargará el archivo dos veces por http://paulirish.com/2010/the-protocol-relative-url/

Actualización de 2014:

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.

— meder omuraliev
fuente

18

Solucionado en IE9, FWIW.

— EricLaw

@EricLaw, ¿se solucionó en IE9 independientemente del modo de representación o solo en el modo de estándares y aún se rompe en el modo Quirks?

— scunliffe

Estoy casi seguro de que esto se solucionó en todos los modos en el escáner anticipado. ¿Has visto lo contrario en alguna parte?

— EricLaw

SSL sin duda lo hace tener un impacto en el rendimiento. El EFF no escribe interfaces servidor-servidor, y ese otro sitio tiene poca experiencia técnica. Además, es un antipatrón suponer que el proveedor de un sitio web impondrá tales restricciones. Por lo tanto, las personas que escriben aplicaciones CSS y JavaScript no deberían confiar en la pregunta del protocolo.

— Oteo

63

Una desventaja ocurre si sus URL se ven fuera del contexto de una página web. Por ejemplo, un mensaje de correo electrónico que se encuentra en un cliente de correo electrónico (por ejemplo, Outlook) efectivamente no tiene URL, y cuando está viendo un mensaje que contiene una URL relativa al protocolo, no hay ningún contexto de protocolo obvio (el mensaje en sí es independiente del protocolo utilizado para obtenerlo, ya sea POP3, IMAP, Exchange, uucp o lo que sea), por lo que la URL no tiene un protocolo con el que estar relacionado. No he investigado la compatibilidad con los clientes de correo electrónico para ver qué hacen cuando se les presenta un controlador de protocolo que falta: supongo que la mayoría adivinará en http. Apple Mail se niega a permitirle ingresar una URL sin un protocolo. Es análogo a la forma en que las URL relativas no funcionan en el correo electrónico debido a un contexto similar que falta.

Problemas similares podrían ocurrir en otros contextos no HTTP, como en tweets, mensajes SMS, documentos de Word, etc.

La explicación más general es que las URL de protocolo anónimo no pueden funcionar de forma aislada; no debe ser un contexto pertinente. Por lo tanto, en una página web típica está bien ingresar una biblioteca de scripts de esa manera, pero cualquier enlace externo siempre debe especificar un protocolo. Intenté una prueba simple: //stackoverflow.comasigna a file:///stackoverflow.comtodos los navegadores en los que lo probé, por lo que realmente no funcionan por sí mismos.

— Synchro
fuente

55

Este es un punto realmente bueno, en realidad estaba pensando en esto cuando me quedé dormido anoche. Otro problema es que la versión httpso httppuede no estar realmente disponible, no siempre se puede suponer que sí.

— Wesley Murch

1

Fuera de un navegador, estás solo, por así decirlo. No se sabe si el correo electrónico u otro cliente sabe acerca de javascript o css, etc. ¿Entonces esto es más o menos un punto discutible sobre las URL relativas?

— Chris

No es un punto discutible. Muchos clientes de correo electrónico admiten JS y los navegadores ciertamente pueden hacerlo al cargar desde file://. Es un caso de uso menor, pero cuando surge es importante.

— Jun-Dai Bates-Kobashigawa

Desearía que hubiera una manera de especificar el uso de http a menos que la url actual sea https, en cuyo caso use https , en lugar de especificar el mismo protocolo con el que se cargaron las páginas actuales , que es efectivamente lo que //es.

— Jun-Dai Bates-Kobashigawa

2

Si especifica un eg <base href="https://www.google.com">, puede ver el contenido fuera del lado de la web. <img src="//www.google.com/images/srpr/logo11w.png">o bien<img src="images/srpr/logo11w.png">

— zig

3

La razón podría ser proporcionar páginas web portátiles. Si la página externa no se transporta encriptada (http), ¿por qué deberían encriptarse los scripts vinculados? Esto parece ser una pérdida de rendimiento innecesaria. En caso de que la página externa se transporte de forma segura encriptada (https), el contenido vinculado también debe estar encriptado. Si la página está encriptada, el contenido vinculado no, IE parece emitir una advertencia de Contenido mixto . La razón es que un atacante puede manipular los scripts en el camino. Ver http://ie.microsoft.com/testdrive/Browser/MixedContent/Default.html?o=1 para una discusión más larga.

La campaña HTTPS Everywhere del EFF sugiere usar https siempre que sea posible. Tenemos la capacidad del servidor en estos días para servir páginas web siempre encriptadas.

— koppor
fuente

0

Solo por completo. Esto fue mencionado en otro hilo:

Las "dos barras diagonales" son una abreviatura común para "cualquier protocolo que se esté utilizando en este momento"

if (plain http environment) {
    use 'http://example.com/my-resource.js'
} else {
    use 'https://example.com/my-resource.js'
}

Por favor revise el hilo completo.

— escapado
fuente

-2

Parece ser una técnica bastante común ahora. No hay inconveniente, solo ayuda a unificar el protocolo para todos los activos en la página, por lo que debe usarse siempre que sea posible.

— Ramashish Baranwal
fuente