pasar pagina migrar hacer convertir como cambiar http url https protocol-relative

pagina - ¿Puedo cambiar todos mis enlaces http:// a solo//?



migrar a https (6)

¿Es esto totalmente compatible con varios navegadores? ¿Hay alguna otra advertencia?

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>

He publicado esta respuesta here también.

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 al protocolo, consulte here .

Dave Ward dice:

No es exactamente una lectura ligera, pero la sección 4.2 de RFC 3986 proporciona URL completamente calificadas que omiten el protocolo (HTTP o HTTPS) en conjunto. Cuando se omite el protocolo de una URL, el navegador usa el protocolo del documento subyacente.

En pocas palabras, estas URL "sin protocolo" permiten que una referencia como esta funcione en todos los navegadores en los que lo intentará:

//ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js

Parece extraño al principio, pero esta URL "sin protocolo" es la mejor manera de hacer referencia al contenido de terceros que está disponible a través de HTTP y HTTPS.

Esto sin duda resolvería un montón de errores de contenido mixto que estamos viendo en las páginas HTTP, asumiendo que nuestros activos están disponibles a través de HTTP y HTTPS.

¿Es esto totalmente compatible con varios navegadores? ¿Hay alguna otra advertencia?

La cuestión de si uno puede cambiar todos sus enlaces para que sean relativos al protocolo puede ser discutible, considerando la cuestión de si uno debe hacerlo. Según Paul Irish :

2014.12.17: 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 activo https: // .

Lo probé a fondo antes de publicarlo. De todos los navegadores disponibles para probar en Browsershots , solo pude encontrar uno que no manejó la URL relativa del protocolo correctamente: un navegador desconocido * nix llamado Dillo .

Hay dos inconvenientes que he recibido comentarios sobre:

  1. Es posible que las URL sin protocolo no funcionen como se esperaba cuando "abre" un archivo local en su navegador, porque el protocolo base de la página será archivo: ///. Especialmente cuando está utilizando la URL sin protocolo para un recurso externo como un activo alojado en CDN. Sin embargo, usar un servidor web local como Apache o IIS para probar contra las direcciones http: // localhost funciona bien.
  2. Aparentemente hay al menos una aplicación de lector de feeds para iPhone que no maneja las URL sin protocolo correctamente. No estoy al tanto de cuál tiene el problema o qué tan popular es. Para alojar un archivo JavaScript, eso no es un gran problema, ya que los lectores de RSS generalmente ignoran el contenido de JavaScript de todos modos. Sin embargo, podría ser un problema si utiliza estas URL para medios como imágenes dentro de contenido que debe ser sindicado a través de RSS (sin embargo, esta aplicación de un solo lector en una sola plataforma probablemente representa un número muy marginal de lectores).

No he tenido estos problemas al usar: //dominio.com, pero es necesario agregar los dos puntos al principio. Yoast tenía un buen escrito sobre esto hace un tiempo. Pero está perdido en su montón de publicaciones de blog.

Sí, las referencias de ruta de red ya estaban especificadas en RFC 1808 y deberían funcionar con todos los navegadores.