2011-06-28 13 views
9

la cuestión es la siguiente:taquigrafía http: // como // para secuencias de comandos y etiquetas de enlace? ¿Alguien ve/usa esto antes?

si se echa un vistazo en cualquier sitio usando addthis (el botón de acción) ...

vez que flotan sobre el botón AddThis, y toda la toma de carga requerida activos una mirada al cuerpo del documento usando firebug o chrome inspector (no la fuente, el documento real que está sentado en su pantalla ... el inspector de objetos). notará que los activos adicionales cargados automáticamente por addthis ser algo como esto:

<script type="text/javascript" src="//s7.addthis.com/static/r07/menu78.js"></script> 
<link rel="stylesheet" type="text/css" href="//s7.addthis.com/static/r07/widget61.css" media="all"> 

lo que es esta breve entrega de http: // en las etiquetas anteriores?

¿Alguien ha usado esto antes? ¿tiene un nombre "oficial"? ¿Cuán compatible es el navegador cruzado con este método de entrega breve del protocolo http?

sí, entiendo que esto romperá las cosas en cuanto a crawlers/seo, pero estoy pensando en comenzar a usar esto en situaciones que son inaccesibles (principalmente, cosas manejadas js) a bots.

¿una buena o mala idea?

+0

Consulte esta pregunta para obtener más información: http://stackoverflow.com/questions/550038/is-it-valid-to-replace -http-con-en-un-script-src-http ya que se refieren a la parte relevante en el RFC 3986 (Sección 4.2 y 5.2.2). También deben ser referidos como sin esquema (o una referencia de ruta de red) no sin protocolo. –

+0

para aquellos que van en cabeza sana cambiando tanto como sea posible a estos enlaces taquigráficos ... hay múltiples errores en (por supuesto) es decir ... uno explicado aquí (es decir, 7/8 + enlaces hash): http: // php5.skauti-pardubice.cz/IE7-missing-scheme-bug.php | otro discutido en http://stackoverflow.com/questions/550038/is-it-valid-to-replace-http-with-in-a-script-src-http –

Respuesta

28

partir de una URL con // significa "Usar un servidor diferente pero mantener el mismo esquema de"

Así que si carga //example.net/script de https://example.com/ obtendrá https://example.net/script, mientras que si se carga desde http://example.com/ obtendrá http://example.net/script.

Si, por otro lado, lo carga de file://c:/Users/You/Documents/test.html, entonces probablemente no se resuelva en nada útil. Asegúrese de hacer el desarrollo con un servidor web local (y acceda al http://localhost/) si usa esta sintaxis.

Ésta es una parte estándar de la URI, que bien soportado, y por lo general se conoce como "esquema URI relativas"

+3

Sé que estoy siendo un poco pedante aquí, pero incluso si especifica https: //example.net y http: //example.net, todavía está utilizando el mismo protocolo: el protocolo http. Solo estás usando un esquema de uri diferente. –

+0

puesta a tierra para este comentario. Gracias –

5

Para construir sobre Quentin's answer, estas URL son comúnmente llamados protocol-less URLs (aunque, como señala Nick en el comentarios, el nombre propio es sin esquema).

Además, tenga cuidado con el caso en el que los utiliza en el desarrollo local (es decir, el enlace a jQuery desde una página HTML que carga desde su disco duro, a través del protocolo file://). En tales escenarios, todos los enlaces salientes serán tratados como locales - //jquery.com/ se referirá a file://jquery.com/

+2

No es el nombre propio. Deben ser referidos como referencias sin esquema o ruta de red.Cite: http://tools.ietf.org/html/rfc3986 –

+0

Pensé que estos se llamaban "Protocol Relative URL" –

+0

gracias por la corrección, Nick. Actualicé la respuesta. –

Cuestiones relacionadas