En una URL, ¿para qué sirve //? [cerrado]

39

Por lo general, cuando veo //, generalmente sigue un prefijo de protocolo como http:o ftp:. Nunca lo he visto en otro lugar. Por ejemplo,

http://www.google.com/

es una URL típica

Sin embargo, descubrí que las siguientes dos sintaxis producen diferentes versiones del mismo sitio,

http://www.weather.com/

http://www.weather.com//

Pensé que //cualquier otra parte que no sea la especificación del protocolo sería inválida. Para mi sorpresa, estaba equivocado. ¿Qué tiene el final //que ofrece una versión diferente del mismo sitio?

EDITAR:

Alguien en ese sitio debe haberse enterado del otro porque ambos enlaces ahora aterrizan en la misma página.

url syntax uri

— Chad Harrison
fuente

9

Si tuviera que adivinar, todo lo que está haciendo es ver el mismo sitio dos veces, pero el que tiene el extra / al final está rompiendo el CSS o lo que los niños usan actualmente para formatear sus sitios web. :)

— Mark Allen

webmasters.stackexchange.com podría ser mejor para esta pregunta.

— Mehper C. Palavuzlar

1

@ MehperC.Palavuzlar En retrospectiva, sí. Pero en el momento de la pregunta, pensé que el alcance era algo más amplio de lo que es.

— Chad Harrison el

@MarkAllen Bueno es interesante tener en cuenta que el uso ///o ////al final de la URL dio como resultado el mismo sitio que /cuando // lo hicieron resultado en algo diferente.

— Chad Harrison el

Mientras tanto, la doble barra invertida (\\) se ve comúnmente en la Convención de nomenclatura uniforme de Windows, por ejemplo,\\HostName[@Port]\SharedFolder\Resource

— William C

67

El inicio //es parte de la sintaxis de URL. El inventor de la red mundial se disculpó por ese error .

Realmente, si lo piensas, no necesita la doble barra. Podría haberlo diseñado para que no tuviera doble barra. - Sir Tim Berners-Lee, inventor de la red mundial

En cuanto al seguimiento //, en realidad no es un doble corte. La primera barra inclinada separa el nombre del host de la ruta. El último corte es el camino. Un servidor web puede, si lo desea, tratar una ruta /diferente de una ruta vacía, y aparentemente lo hace weather.com. En cuanto a si esto es accidental o intencional, tendrías que preguntarles al respecto.

— David Schwartz
fuente

¡Eso se completa desde entonces, porque puede configurar un servidor web para buscar un índice que no sea solo la raíz web! Me quito el sombrero ante usted, buen señor.

— Chad Harrison el

¿Estás diciendo que http://example.comse puede tratar de manera diferente http://example.com/? No pensé que ese fuera el caso con el primer corte.

— DisgruntledGoat

1

@DisgruntledGoat Podría , sí, usar algunas .htaccessreglas. Pero probablemente no deberías.

— Mateo

1

No se puede tratar de manera http://example.comdiferente http://example.com/en un servidor web, ya que ambos tienen una ruta vacía. Podrías tratarlos de manera diferente en un navegador.

— David Schwartz

3

sin importar el encabezado del host, cero o una barraGET / HTTP/1.1

— oblicua se

19

Más recientemente, se podría argumentar que la doble barra hace tener un papel. Google recomienda (para evitar llamar accidentalmente contenido inseguro desde una página segura, por ejemplo) omitiendo el protocolo de los recursos integrados (hojas de estilo, js, etc.), como este

<script src="//www.google.com/js/gweb/analytics/autotrack.js"></script>

Por lo tanto, ahora es evidente que dicha URL sin protocolo es una URL totalmente calificada y no una URL relativa (que comenzaría con una barra oblicua).

— DaveP
fuente

1

Este estilo se denomina URL / URI "relativo al protocolo". Hay preguntas similares sobre SO.

— hippietrail

1

No más lo recomiendo. Ver también paulirish.com/2010/the-protocol-relative-url

— lorond

13

Para realmente responder a la pregunta, la especificación original dio el protocolo http:(o posiblemente ftp:, gopher:, mailto:, news:, telnet:, wais:, file:o prospero:) a continuación, una // para indicar que se estaba utilizando la sintaxis Localizador Uniforme de Recursos (URL), entonces el host (opcionalmente con el prefijo user:password@) y después dirección adecuado a partir de otro /. Esto fue propuesto en RFC 1738 .

A medida que Internet evolucionó, se http:convirtió en el protocolo dominante, por lo que los navegadores ahora suponen que se http://debe agregar un prefijo si no está allí.

— StarNamer
fuente

3

Su respuesta parecería indicar que algo diferente a la URL podría haberse usado con el protocolo en un punto, y habría usado algo diferente //a indicar que estaba en uso ... ¿Es así?

— Izkata

3

@Izkata A finales de los años 80 y 90, cuando Internet se estaba iniciando, se sugirieron varios formatos diferentes para varios elementos. Las URL eran / son un subconjunto de URN (consulte RFC 3305) y pueden tener formatos diferentes, por ejemplo isbn:1-23-456789-12-3. En la práctica, el http:define que el resto será una URL. Los RFC son solo propuestas y a menudo permiten extensiones que nunca se materializan. En un momento, Tim Berners-Lee dijo que //era para una 'subred' (por ejemplo http:/govnet/whitehouse.gov). Esta idea nunca se usó, pero '//' permanece ya que ahora tanto código espera y lo comprueba.

— StarNamer

1

@Izkata: probablemente no verá una URN que no sea URL utilizada con un protocolo de comunicaciones; para eso está el //. Indica que el protocolo se está utilizando para acceder a una ubicación de red (posiblemente remota) donde se encuentra un recurso. No hay un montón de otros de URN que tienen otras partes de datos y no utilizan // (su navegador reconoce probablemente "mailto:", por ejemplo). Ver: en.wikipedia.org/wiki/URI_scheme

— KutuluMike

@MichaelEdenfield Bueno, eso es lo que me pregunto ahora. ¿Hubo alguna vez un punto en el que se pretendía que se usara de manera diferente, algo diferente que pudiera comunicarse a través del mismo protocolo? Como un ejemplo crudo, pudiera la intención de una vez han sido por http://www.google.com/y http:%/74.125.225.97/para tanto ser válido, y //indicar un nombre de host, mientras que otra cosa, como %/indica una dirección IP?

— Izkata

1

No lo creo. Al menos nunca he visto ningún borrador de documentos / ejemplos / etc. que tenga un esquema de jerarquía alternativo para las URL. Mi impresión siempre ha sido que TBL solo quería algo que hiciera obvio que una URL apuntaba a un recurso real (y no datos arbitrarios), y el uso de // hacía que las cosas se parecieran lo suficiente a un archivo. Cada otro estilo de URN que he visto tiene ningún prefijo especial en ella es parte de datos. Algunos protocolos lo permiten (creo que telnet y gopher, por ejemplo), pero nunca he visto algo así para http (s).

— KutuluMike

1

Me gustaría agregar a la respuesta aceptada de David:

A pesar de la disculpa del inventor de la web, creo que la sintaxis de doble barra sirvió para un propósito importante: destacar visualmente. Las dos barras inclinadas permiten una fácil distinción visual de las URL en un texto sin hipervínculos. Cuando vio dos barras diagonales, inmediatamente pensó que podría ingresarse en una ventana del navegador, de forma similar a cómo pensaba que un texto contenía@podría usarse para enviar un correo electrónico. Fue especialmente crucial durante la fase de transición a la web donde los protocolos de esa época (ftp, telnet, gopher) tenían su propia noción extraña para representar las direcciones del servidor o las rutas de recursos, rara vez ambas. La mayoría de los problemas asociados con las barras inclinadas dobles seguirían existiendo, porque las barras diagonales dobles son la parte menos críptica de una URL, piense en los números de puerto, la codificación porcentual y la distinción entre mayúsculas y minúsculas. Pero tener una URL como http: something.com podría confundirse fácilmente con mi ejemplo aquí: something.com. Mire http: // por otro lado, cómo brilla como un diamante. Las dobles barras han sido una parte importante del simbolismo web y creo que también aceleraron su tasa de adopción, incluso si no fue intencional.

También podrían haber hecho que el trabajo de AmigaOS sea más fácil de diferenciar entre los nombres de archivo y las URL, ya que AmigaOS utilizó la sintaxis de la ruta del archivo volume:path/to/destination. :)

— Sedat Kapanoglu
fuente