Prevención de errores seguros/inseguros mediante el uso de URL relativas de protocolo para fuente de imagen

Question

¿Alguien sabe si es problemático utilizar protocol relative URLs para una fuente de imagen para evitar advertencias de seguridad de contenido mixto?

Por ejemplo la vinculación de una imagen como:

<img src="//domain.com/img.jpg" /> 

en lugar de:

<img src="http://domain.com/img.jpg" /> 
or 
<img src="https//domain.com/img.jpg" /> 

En mis pruebas no he visto nada que sugiera que esto está mal, pero no estoy seguro de si tiene casos de borde donde creará problemas.

EDIT lo he visto arrojar errores al utilizar la función getimagesize de PHP.

Answer 1

Encontró un Gotcha interesante para el uso de protocolos URL relativos:

Usted tiene que tener cuidado de usar sólo esta sintaxis en páginas destinadas a navegadores. Si lo pone en un correo electrónico, , no habrá una URL de página base para usar al resolver la URL relativa. En Outlook al menos, esta URL será interpretada como un archivo de red de Windows, no es lo que pretendía.

de here

En esencia, aunque no hay razones válidas por las que esto no debe trabajar, siempre y cuando la solicitud se realiza mediante un navegador y no un cliente de correo electrónico externo.

más información de here:

Una URL relativa sin un esquema (http: o https :) es válida, por RTF 3986: Sección 4.2. Si un cliente se ahoga en él, , es culpa del cliente porque no están cumpliendo con la sintaxis de URI especificada en el RFC.

Su ejemplo es válido y debería funcionar. He usado ese método relativo de URL en sitios con mucho tráfico y no he tenido ninguna queja. Además, probamos nuestros sitios en en Firefox, Safari, IE6, IE7 y Opera. Estos navegadores todos entienden ese formato URL

Answer 2

IE 7 e IE 8 serán download stylesheets twice si está utilizando una URL relativa al protocolo. Eso no lo afectará si solo lo usa "para una fuente de imagen", pero por las dudas.