¿Es válido reemplazar http:// con / / en a?

Se garantiza que funcione en cualquier navegador convencional (no estoy tomando navegadores con menos de 0.05% de cuota de mercado en consideración). Diablos, funciona en Internet Explorer 3.0.

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

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

Al definir URI relativos ( Sección 5.2), puede omitir cualquiera de esas secciones, siempre comenzando 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 sin esquema URI relativa.

¿Hay casos en los que no funciona?

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

Muchas personas llaman a esto una URL Relativa al Protocolo.

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

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

Usando un absoluto independiente del protocolo ruta:

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

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

Esto evita que horrible " Esta página Contiene Tanto Seguro como No Seguro Items " mensaje de error en IE, manteniendo todas sus solicitudes de activos dentro del mismo protocolo.

Advertencia: Cuando se utiliza en un <link> o @ importar para una hoja de estilos, IE7 e IE8 descargue el archivo dos veces. Todos los demás los usos, sin embargo, están bien.

Es perfectamente válido dejar el protocolo. La especificación de URL ha sido muy clara sobre esto durante años, y aún no he encontrado un navegador que no lo entienda. No se por qué esta técnica no es mejor conocida; es la solución perfecta al espinoso problema de cruzar los límites HTTP/HTTPS. Más aquí: Transiciones Http-https y URLs relativas

¿Hay casos en los que no funciona?

Solo para agregar esto a la mezcla, si está desarrollando en un servidor local, puede que no funcione. Es necesario especificar un esquema, de lo contrario el navegador puede asumir que src="//cdn.example.com/js_file.js" es src="file://cdn.example.com/js_file.js", que se romperá ya que no está alojando este recurso localmente.

Microsoft Internet Explorer parece ser particularmente sensible a esto, vea esta pregunta: No es capaz de cargar jQuery en Internet Explorer en localhost (WAMP)

Probablemente siempre intentaría 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 una alternativa cuando el recurso no se carga correctamente, pero eso solo funciona si se incorpora una comprobació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.js después de decidir desaprobar las URL relativas del protocolo, vea [aquí] [3].

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

Si el componente de scheme está definido, indicando que la referencia comienza con un nombre de scheme, luego la referencia se interpreta como un URI absoluta y hemos terminado. De lo contrario, el esquema del URI de referencia se hereda del componente scheme del URI base .

Así que // es correcto: -)

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

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

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

Es posible que desee configurar una regla en su servidor web para capturarlos 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;
}

Tenga en cuenta, sin embargo, que si utiliza períodos en sus URI, tendrá que aumente la especificidad o terminará redirigiendo esas páginas a dominios inexistentes.

También, esta es una expresión regular bastante masiva que se ejecuta para cada consulta in en mi opinión, vale la pena castigar a los navegadores no compatibles con 404s sobre un (leve) golpe de rendimiento en la mayoría de los navegadores compatibles.

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

Las referencias que causan los 404s salen con este aspecto: ref:

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

404 solicitud:

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

Con estos apareciendo 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.

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>

Funciona sin problemas en diferentes esquemas como http, https, file.

Como su ejemplo está enlazando a un dominio externo, si está utilizando HTTPS, 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, versiones anteriores de Plesk store HTTP y HTTPS en carpetas separadas). Para las CDN, no debería ser un problema, pero para cualquier otro sitio web podría serlo.

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.