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

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 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 el http:o https:.

Parece que funciona en todos los lugares que he probado, pero ¿hay algún caso en el que no funcione?

Una URL relativa sin un 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 ahoga, entonces es culpa del cliente porque no cumple con la sintaxis de URI especificada en el RFC.

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

Se garantiza que funcione en cualquier navegador convencional (no estoy teniendo en cuenta los navegadores con menos del 0.05% de cuota de mercado). Diablos, 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, siempre comenzando desde la izquierda. En pseudocó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.

¿Hay algún caso en el que no funciona?

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

Mucha gente llama a esto una URL relativa al protocolo.

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

Aquí duplico la respuesta en las 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 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 usa en una <link>o @import para una hoja de estilo, IE7 e IE8 descargan el archivo dos veces . Todos los demás usos, sin embargo, están bien.

Es perfectamente válido dejar de lado el protocolo. La especificación de URL ha sido muy clara sobre esto 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 HTTP / HTTPS. Más aquí: transiciones Http-https y URL relativas

¿Hay algún caso en el que no funciona?

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

<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.jsdespués de decidir desaprobar las URL relativas del protocolo, consulte [aquí] [3].

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

Si el componente del esquema está definido, 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 del esquema del URI base .

Entonces //es correcto :-)

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

(editar: Vaya, mi referencia RFC estaba desactualizada).

De hecho, es correcto, como han dicho otras respuestas. Sin embargo, debe tener en cuenta que algunos rastreadores web activarán 404 para estos solicitándolos en su servidor como si fuera una URL local. (No tienen en cuenta el doble corte y lo tratan como un solo corte).

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

Por ejemplo, con Nginx, agregaría 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 usa períodos 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 conformes con 404 por encima de un (leve) éxito de rendimiento en la mayoría de los navegadores conformes.

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

Las referencias que causan los 404 salen así: ref:

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

Solicitud 404:

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

Con esto apareciendo regularmente en los registros de nuestro servidor web, es seguro decir que: Todos los navegadores y Bots NO cumplen con RFC 3986 sección 4.2. La apuesta más segura es incluir el protocolo siempre que sea posible.

1. Resumen

Respuesta para 2019: aún puede usar URL relativas al protocolo, pero esta técnica es un antipatrón .

También:

1. Puede tener problemas para desarrollarse.
2. Algunas herramientas de terceros pueden no ser compatibles.

https://Sería bueno migrar desde URL relativas al protocolo a él.

2. Relevancia

Esta respuesta es relevante para enero de 2019. En el futuro, los datos de esta respuesta pueden quedar obsoletos.

3. Anti-patrón

3.1. Argumentación

Paul Irish, ingeniero front-end y defensor del desarrollador para Google Chrome , escribe en 2014, diciembre :

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.

Permitir que el fragmento solicite a través de HTTP abre la puerta a ataques como el reciente ataque GitHub Man-on-the-side . Siempre es seguro solicitar activos HTTPS incluso si su sitio está en HTTP, sin embargo, lo contrario no es cierto .

3.2. Otros enlaces

• Carga los recursos de la página utilizando URI relativos al protocolo
• Dejar de usar URL relativas al protocolo

3.3. Ejemplos

• En 2017, Stack Overflow cambió de URL relativas al protocolo a https
• En 2018, Chrome marcará todos los sitios web sin cifrar como "no seguros"

4. Proceso de desarrollo

Por ejemplo, trato de usar la consola limpia .

• Archivo de ejemplo KiraCleanConsole__cdn_links_demo.html:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>clean-console without protocol demonstration</title>
    <!-- Really dead link -->
    <script src="https://unpkg.com/bowser@latest/bowser.min.js"></script>
    <!-- Package exists; link without “https:” -->
    <script src="//cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.js"></script>
    <!-- Package exists: link with “https:” -->
    <script src="https://cdn.jsdelivr.net/npm/gemini-scrollbar/index.js"></script>
</head>
<body>
    Kira Goddess!
</body>
</html>

• salida:

D:\SashaDebugging>clean-console -i KiraCleanConsole__cdn_links_demo.html
checking KiraCleanConsole__cdn_links_demo.html
phantomjs: opening page KiraCleanConsole__cdn_links_demo.html

phantomjs: Unable to load resource (#3URL:file://cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.js)


phantomjs:   phantomjs://code/runner.js:30 in onResourceError
Error code: 203. Description: Error opening //cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.js: The network path was not found.

  phantomjs://code/runner.js:31 in onResourceError

phantomjs: Unable to load resource (#5URL:https://unpkg.com/bowser@2.1.0/bowser.min.js)


phantomjs:   phantomjs://code/runner.js:30 in onResourceError
Error code: 203. Description: Error downloading https://unpkg.com/bowser@2.1.0/bowser.min.js - server replied: Not Found

  phantomjs://code/runner.js:31 in onResourceError

phantomjs: Checking errors after sleeping for 1000ms
2 error(s) on KiraCleanConsole__cdn_links_demo.html

phantomjs process exited with code 2

El enlace //cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.jses válido, pero recibo un error.

Presta atención file://cdn.jsdelivr.net/npm/jquery@3.3.1/dist/jquery.min.jsy lee las respuestas de Thilo y bg17awfile:// .

No sabía sobre este comportamiento y no podía entender por qué tengo problemas como este para los pageres .

5. Herramientas de terceros

Utilizo el paquete de texto sublime de URLs clicables. Úselo, simplemente puedo abrir enlaces desde mi editor de texto en el navegador.

Ambos enlaces, por ejemplo, son válidos. Pero el primer enlace que puedo abrir con éxito en el navegador usa URL clicables, segundo enlace - no. Esto puede no ser muy conveniente.

6. Conclusión

Si:

1. Si tiene problemas como en el Developing processelemento, puede configurar su flujo de trabajo de desarrollo.
2. De lo contrario, tiene problemas como en el Third-party toolsartículo, puede contribuir con herramientas.

Pero no necesita estos problemas adicionales. Lea la información por enlaces en el Anti-patternelemento: las URL relativas al protocolo están obsoletas.

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.

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

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