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

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); }

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 "//".

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.

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.

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.

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.

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.