Em um URL, para que serve //? [fechadas]

39

Normalmente, quando vejo //, geralmente segue algum prefixo de protocolo como http:ou ftp:. Eu nunca o vi colocado em outro lugar. Por exemplo,

http://www.google.com/

é um URL típico.

No entanto, encontrei as duas sintaxes a seguir para gerar versões diferentes do mesmo site,

http://www.weather.com/

http://www.weather.com//

Eu teria pensado que //qualquer outro lugar que não fosse a especificação do protocolo seria inválido. Para minha surpresa, eu estava errado. O que há no final de //uma versão diferente do mesmo site?

EDITAR:

Alguém nesse site deve ter percebido o outro, porque agora os dois links estão na mesma página.

url syntax uri

— Chad Harrison
fonte

9

Se eu tivesse que adivinhar, tudo o que você está fazendo é ver o mesmo site duas vezes, mas aquele com mais / no final está quebrando o CSS ou o que as crianças hoje em dia usam para formatar seus sites. :)

— Mark Allen

webmasters.stackexchange.com pode ser mais adequado para esta pergunta.

— Mehper C. Palavuzlar

1

@ MehperC.Palavuzlar Em retrospecto, sim. Mas, no momento da pergunta, eu achava que o escopo era um pouco mais amplo do que aquilo que é.

— Chad Harrison

@MarkAllen Bem, é interessante notar que a utilização ///ou ////no final da URL resultou no mesmo local que /onde // fez resultar em algo diferente.

— Chad Harrison

Enquanto isso, a barra invertida dupla (\\) é comumente vista na Convenção de Nomenclatura Uniforme do Windows, por exemplo:\\HostName[@Port]\SharedFolder\Resource

— William C

67

O líder //faz parte da sintaxe da URL. O inventor da Internet pediu desculpas por esse erro .

Realmente, se você pensar bem, ele não precisa de barra dupla. Eu poderia ter projetado para não ter a barra dupla. - Sir Tim Berners-Lee, inventor da rede mundial de computadores

Quanto à trilha //, não é realmente uma barra dupla. A primeira barra separa o nome do host do caminho. A última barra é o caminho. Um servidor da Web pode, se quiser, tratar um caminho /diferente de um caminho vazio, e aparentemente o weather.com o faz. Quanto a isso ser acidental ou intencional, você teria que perguntar sobre isso.

— David Schwartz
fonte

Isso fica completo, pois você pode configurar um servidor da web para procurar um índice que não seja apenas a raiz da web! Meu chapéu acabou com você, bom senhor.

— Chad Harrison

Você está dizendo que http://example.compode ser tratado de forma diferente http://example.com/? Não achei que fosse o caso da primeira barra.

— usar o seguinte

1

@DisgruntledGoat Você poderia , sim, usando algumas .htaccessregras. Mas você provavelmente não deveria.

— Mateus

1

Você não pode tratar http://example.comdiferente de http://example.com/um servidor Web, pois os dois têm um caminho vazio. Você pode tratá-los de maneira diferente em um navegador.

— David Schwartz

3

neverminding o cabeçalho do host, zero ou uma barras traduz para o mesmo pedido http: GET / HTTP/1.1: tools.ietf.org/html/rfc2616.html#section-3.2.3

— SingleNegationElimination

19

Mais recentemente, pode-se argumentar que a barra dupla faz ter um papel. O Google recomenda (para evitar chamar acidentalmente conteúdo inseguro de uma página segura, por exemplo) omitir o protocolo de recursos incorporados (folhas de estilo, js etc.), como este

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

Portanto, agora é aparente que esse URL sem protocolo é um URL totalmente qualificado e não um URL relativo (que começaria com uma única barra).

— DaveP
fonte

1

Esse estilo é chamado de URL / URI "relativo ao protocolo". Há perguntas semelhantes sobre o SO.

— Hippietrail

1

Não há mais recomendação. Veja também paulirish.com/2010/the-protocol-relative-url

— lorond 19/10/16

13

Para efectivamente responder à questão, a especificação original deu o protocolo http:(ou possivelmente ftp:, gopher:, mailto:, news:, telnet:, wais:, file:ou prospero:), em seguida, um // para indicar que a sintaxe Uniform Resource Locator (URL) estava a ser utilizado, em seguida, o alojamento (opcionalmente com o prefixo user:password@), em seguida, endereço início adequado com outro /. Isso foi proposto na RFC 1738 .

À medida que a internet evoluiu, http:tornou-se o protocolo dominante, e agora os navegadores assumem que um prefixo de http://deve ser adicionado se não estiver lá.

— StarNamer
fonte

3

Sua resposta parece indicar que algo diferente de URL poderia ter sido usado com o protocolo em um ponto e teria usado algo além de //indicar que estava em uso ... É isso?

— precisa saber é o seguinte

3

@ Izkata No final dos anos 80 e 90, quando a internet estava iniciando, havia vários formatos diferentes sugeridos para vários itens. Os URLs eram / são um subconjunto de URNs (consulte a RFC 3305) e podem ter formatos variados, por exemplo isbn:1-23-456789-12-3. Na prática, o http:define que o restante será uma URL. As RFCs são apenas propostas e geralmente permitem extensões que nunca se materializam. Em um ponto, Tim Berners-Lee disse que //era para uma 'sub-rede' (por exemplo http:/govnet/whitehouse.gov). Essa idéia nunca foi usada, mas '//' permanece o tanto de código que agora espera e verifica.

— StarNamer

1

@ Izkata: você provavelmente não veria um URN sem URL usado com um protocolo de comunicação; é para isso que serve o //. Indica que o protocolo está sendo usado para acessar um local de rede (possivelmente remoto) onde um recurso deve ser encontrado. Não são muitas outras de urna que têm outras partes de dados e não usam // (seu navegador provavelmente reconhece "mailto:", por exemplo). Veja: en.wikipedia.org/wiki/URI_scheme

— KutuluMike

@ MichaelEdenfield Bem, é isso que estou pensando agora. Houve um momento em que se pretendia que fosse usado de maneira diferente - algo diferente que pudesse se comunicar através do mesmo protocolo. Como um exemplo grosseiro, poderia a intenção de uma vez ter sido para http://www.google.com/e http:%/74.125.225.97/tanto para ser válido e //indicar um nome de host, enquanto outra coisa como %/indicar um endereço IP?

— Izkata

1

Acho que não. Pelo menos nunca vi nenhum rascunho de documentos / exemplos / etc que possuam esquema de hierarquia alternativa para URLs. Minha impressão sempre foi de que o TBL só queria algo que tornasse óbvio que um URL apontava para um recurso real (e não dados arbitrários), e o uso de // fazia as coisas parecerem suficientemente parecidas com arquivos. Todos os outros estilos de URN que eu já vi não têm prefixo especial em sua parte de dados. Alguns protocolos permitem isso ( acho que telnet e gopher, por exemplo), mas nunca vi nada parecido com http (s).

— precisa saber é o seguinte

1

Gostaria de acrescentar à resposta aceita de David:

Apesar das desculpas do inventor da web, acho que a sintaxe de barra dupla serviu a um propósito importante: destacar-se visualmente. As barras duplas permitiam uma distinção visual fácil de URLs em um texto sem hiperlinks. Quando você viu barras duplas, imediatamente pensou que poderia ser inserido em uma janela do navegador, semelhante à forma como você pensava que um texto contendo@pode ser usado para enviar um email. Foi especialmente crucial durante a fase de transição para a Web, onde os protocolos daquela época (ftp, telnet, gopher) tinham sua própria noção estranha de representar endereços de servidor ou caminhos de recursos, raramente ambos. A maioria dos problemas associados às barras duplas ainda existiria, porque as barras duplas são a parte menos enigmática de uma URL, pense em números de porta, porcentagem de codificação e distinção entre maiúsculas e minúsculas. Mas ter um URL como http: something.com poderia ser facilmente confundido com o meu exemplo aqui: something.com. Veja http: // por outro lado, como brilha como um diamante. Barras duplas têm sido uma parte importante do simbolismo da Web e acredito que acelerou sua taxa de adoção também, mesmo que não fosse intencional.

Eles também podem ter facilitado o trabalho do AmigaOS de diferenciar nomes de arquivos e URLs, já que o AmigaOS usava a sintaxe do caminho do arquivo volume:path/to/destination. :)

— Sedat Kapanoglu
fonte