attribute - metadatos html ejemplos

¿Es válido reemplazar http:// con// en un<script src=“http://...”>?

Question

Tengo el siguiente elemento:

<script type="text/javascript" src="https://cdn.example.com/js_file.js"></script>

En este caso, el sitio es HTTPS, pero el sitio también puede ser solo HTTP. (El archivo JS está en otro dominio). Me pregunto si es válido hacer lo siguiente por conveniencia:

<script type="text/javascript" src="//cdn.example.com/js_file.js"></script>

Me pregunto si es válido eliminar http: o https: :?

Parece funcionar en todos los lugares que he probado, pero ¿hay casos en los que no funciona?

Answer 1

¿Hay casos en los que no funciona?

Si la página principal se cargó desde el file:// , entonces probablemente no funcione (intentará obtener el file://cdn.example.com/js_file.js , que por supuesto también puede proporcionar localmente).

Answer 2

¿Hay casos en los que no funciona?

Solo para lanzar esto en la mezcla, si está desarrollando en un servidor local, podría no funcionar. src="//cdn.example.com/js_file.js" especificar un esquema, de lo contrario el navegador puede suponer que src="//cdn.example.com/js_file.js" es src="file://cdn.example.com/js_file.js" , que se romperá ya que no estas 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 incorporas un cheque:

<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>

ACTUALIZACIÓN: HTML5Boilerplate ahora usa <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js después de decidir dejar de usar las URL relativas del protocolo, ver [aquí] [3] .

Answer 3

Aquí duplico la respuesta en características ocultas de HTML :

Usando una ruta absoluta independiente del protocolo:

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

Si el navegador está viendo una página en SSL a través de HTTPS, solicitará ese activo con el protocolo https, de lo contrario lo solicitará con HTTP.

Esto evita que el horrible mensaje de error "Esta página contiene elementos seguros y no seguros" en IE, manteniendo todas sus solicitudes de activos dentro del mismo protocolo.

Advertencia: cuando se utiliza en un <link> o @import para una hoja de estilo, IE7 e IE8 descargan el archivo dos veces . Todos los otros usos, sin embargo, están bien.

Answer 4

Como su ejemplo se vincula a un dominio externo, si está usando HTTPS, debe verificar que el dominio externo también esté configurado para SSL. De lo contrario, sus usuarios pueden ver los errores de SSL y / o los errores de 404 (por ejemplo, versiones anteriores de la tienda Plesk HTTP y HTTPS en carpetas separadas). Para los CDN, no debería ser un problema, pero para cualquier otro sitio web podría serlo.

En una nota al margen, se probó mientras se actualizaba un sitio web antiguo y también funciona en la url = parte de un META REFRESH.

Answer 5

De hecho es correcto, como han indicado otras respuestas. Sin embargo, debe tener en cuenta que algunos rastreadores web activarán los 404 para estos solicitándolos en su servidor como si fuera una URL local. (Ignoran la barra doble y la tratan como una barra simple).

Es posible que desee configurar una regla en su servidor web para detectarlos y redirigirlos.

Por ejemplo, con Nginx, agregarías algo como:

location ~* /(?<redirect_domain>((([a-z]|[0-9]|/-)+)/.)+([a-z])+)/(?<redirect_path>.*) {
  return 301 $scheme:/$redirect_domain/$redirect_path;
}

Sin embargo, tenga en cuenta que si utiliza puntos en sus URI, deberá aumentar la especificidad o terminará redirigiendo esas páginas a dominios inexistentes.

Además, esta es una expresión regular bastante masiva para cada consulta; en mi opinión, vale la pena castigar a los navegadores no compatibles con 404s sobre un (leve) impacto de rendimiento en la mayoría de los navegadores compatibles.

Answer 6

El patrón que veo en html5-boilerplate es:

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script>
<script>window.jQuery || document.write(''<script src="js/vendor/jquery-1.10.2.min.js"><//script>'')</script>

Se ejecuta sin problemas en diferentes esquemas como http , https , file .

Answer 7

Es perfectamente válido dejar de lado el protocolo. La especificación de URL ha sido muy clara al respecto durante años, y todavía tengo que encontrar un navegador que no lo entienda. No sé por qué esta técnica no se conoce mejor; Es la solución perfecta para el espinoso problema de cruzar los límites de HTTP / HTTPS. Más aquí: transiciones Http-https y URL relativas

Answer 8

Estamos viendo 404 errores en nuestros registros cuando usamos //somedomain.com como referencias a archivos JS.

Las referencias que causan los 404s se ven así: ref:

<script src="//somedomain.com/somescript.js" />

Solicitud 404:

http://mydomain.com//somedomain.com/somescript.js

Dado que estos aparecen regularmente en los registros de nuestro servidor web, es seguro decir que: Todos los navegadores y Bots NO respetan la sección 4.2 de RFC 3986. La apuesta más segura es incluir el protocolo siempre que sea posible.

Answer 9

Muchas personas llaman a esto una URL relativa de protocolo.

Provoca una doble descarga de archivos CSS en IE 7 y 8 .

Answer 10

Sí, esto está documentado en RFC 3986 , sección 5.2:

(Edición: Ups, mi referencia RFC estaba desactualizada).

Answer 11

Se garantiza que funciona en cualquier navegador convencional (no estoy tomando en cuenta los navegadores con menos del 0.05% de participación de mercado). Heck, funciona en Internet Explorer 3.0.

RFC 3986 define un URI como compuesto de las siguientes partes:

     foo://example.com:8042/over/there?name=ferret#nose
     /_/   /______________//_________/ /_________/ /__/
      |           |            |            |        |
   scheme     authority       path        query   fragment

Al definir los URI relativos ( Sección 5.2 ), puede omitir cualquiera de esas secciones, comenzando siempre por la izquierda. En pseudo-código, se ve así:

 result = ""

  if defined(scheme) then
     append scheme to result;
     append ":" to result;
  endif;

  if defined(authority) then
     append "//" to result;
     append authority to result;
  endif;

  append path to result;

  if defined(query) then
     append "?" to result;
     append query to result;
  endif;

  if defined(fragment) then
     append "#" to result;
     append fragment to result;
  endif;

  return result;

El URI que está describiendo es un URI relativo sin esquema.

Answer 12

Siguiendo la referencia del gnud, la sección 5.2 de RFC 3986 dice:

Si se define el componente del esquema, lo que indica que la referencia comienza con un nombre de esquema, entonces la referencia se interpreta como un URI absoluto y hemos terminado. De lo contrario, el esquema del URI de referencia se hereda del componente esquema del URI base .

Entonces // es correcto :-)

Answer 13

Una URL relativa sin esquema (http: o https :) es válida, según RFC 3986: "Identificador uniforme de recursos (URI): sintaxis genérica", Sección 4.2 . Si un cliente se atraganta con eso, entonces es culpa del cliente porque no cumple con la sintaxis URI especificada en la RFC.

Tu ejemplo es válido y debería funcionar. He utilizado ese método de URL relativa en sitios con mucho tráfico y no he recibido ninguna queja. Además, probamos nuestros sitios en Firefox, Safari, IE6, IE7 y Opera. Todos estos navegadores entienden ese formato de URL.