http - links - ¿Hay algún inconveniente para usar una barra doble inicial para heredar el protocolo en una URL? es decir, src="// dominio.com"

uri web

Question

Tengo una hoja de estilo que carga imágenes de un dominio externo y necesito cargar desde https: // desde páginas de orden segura y desde otras páginas, basadas en la URL actual. Descubrí que al iniciar 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); }

Answer 1

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

Actualización desde 2014:

Ahora que se alienta 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, utilice siempre el recurso https:// .

Answer 2

El motivo podría ser proporcionar páginas web portátiles. Si la página externa no se transporta encriptada (http), ¿por qué deberían cifrarse los scripts? Esto parece ser una pérdida de rendimiento innecesaria. En el caso, la página externa se transporta de forma segura encriptada (https), luego 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 las secuencias de comandos en el camino. Consulte 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 estos días para servir páginas web siempre encriptadas.

Answer 3

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.

Answer 4

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 la URL de la página para referencias que comiencen con "//".

Answer 5

Solo por completitud. Esto fue mencionado en otro hilo:

''Las dos barras diagonales son una abreviatura común para cualquier protocolo que se use correctamente''

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.

Answer 6

Una desventaja se produce 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) 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í mismo es independiente del protocolo utilizado para buscarlo, ya sea POP3, IMAP, Exchange, uucp o lo que sea) para que la URL no tenga ningún protocolo relativo. No he investigado la compatibilidad con clientes de correo electrónico para ver qué hacen cuando se presentan con un controlador de protocolo faltante. Supongo que la mayoría adivinará http. Apple Mail se niega a permitirte 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 que no sean HTTP, como en tweets, mensajes SMS, documentos de Word, etc.

La explicación más general es que las URL de protocolo anónimas no pueden funcionar de forma aislada; debe haber un contexto relevante. En una página web típica, es bueno extraer una biblioteca de scripts de esa manera, pero cualquier enlace externo siempre debe especificar un protocolo. //.com una prueba simple: //.com asigna al file:///.com en todos los navegadores en los que intenté, por lo que realmente no funcionan por sí mismos.