Por que os URLs diferenciam maiúsculas de minúsculas?

Minha pergunta: quando os URLs foram criados pela primeira vez, por que a diferenciação entre maiúsculas e minúsculas se tornou um recurso? Eu pergunto isso porque me parece (ou seja, um leigo) que a distinção entre maiúsculas e minúsculas seria preferida para evitar erros desnecessários e simplificar uma sequência de texto já complicada.

Além disso, existe um verdadeiro objetivo / vantagem em ter um URL com distinção entre maiúsculas e minúsculas (em oposição à grande maioria dos URLs que apontam para a mesma página, independentemente da capitalização)?

A Wikipedia, por exemplo, é um site sensível a letras maiúsculas (exceto o primeiro caractere):

https://en.wikipedia.org/wiki/St Um ck_Exchange é DOA.

Por que o URL não diferencia maiúsculas de minúsculas?

Entendo que isso possa parecer uma pergunta retórica provocativa (e "advogada do diabo"), mas acho útil considerar. O design do HTTP é que um "cliente", que geralmente chamamos de "navegador da web", solicita dados ao "servidor da web".

Existem muitos servidores web diferentes que são lançados. A Microsoft lançou o IIS com sistemas operacionais Windows Server (e outros, incluindo o Windows XP Professional). O Unix tem pesos pesados ​​como nginx e Apache, para não mencionar ofertas menores como o httpd interno do OpenBSD, ou thttpd ou lighttpd. Além disso, muitos dispositivos com capacidade de rede construíram servidores Web que podem ser usados ​​para configurá-lo, incluindo dispositivos com finalidades específicas para redes, como roteadores (incluindo muitos pontos de acesso Wi-Fi e modems DSL) e outros dispositivos, como impressoras ou No-breaks (unidades de fonte de alimentação ininterruptas com bateria) que podem ter conectividade de rede.

Portanto, a pergunta "Por que as URLs diferenciam maiúsculas de minúsculas?" Está perguntando: "Por que os servidores da Web tratam a URL como diferenciando maiúsculas de minúsculas?" E a resposta real é: nem todos fazem isso. Pelo menos um servidor web, bastante popular, normalmente NÃO diferencia maiúsculas de minúsculas. (O servidor web é IIS.)

Uma das principais razões para um comportamento diferente entre diferentes servidores da Web provavelmente se resume a uma questão de simplicidade. A maneira simples de criar um servidor da Web é fazer as coisas da mesma maneira como o sistema operacional do computador / dispositivo localiza arquivos. Muitas vezes, os servidores da web localizam um arquivo para fornecer uma resposta. O Unix foi projetado em computadores de última geração e, portanto, o Unix forneceu a funcionalidade desejável de permitir letras maiúsculas e minúsculas. O Unix decidiu tratar maiúsculas e minúsculas como diferentes porque, bem, elas são diferentes. Essa é a coisa simples e natural a se fazer. O Windows tem um histórico de distinção entre maiúsculas e minúsculas devido ao desejo de oferecer suporte a software já criado, e esse histórico remonta ao DOS, que simplesmente não suportava letras minúsculas, possivelmente em um esforço para simplificar as coisas com computadores menos potentes que usavam menos memória. Como esses sistemas operacionais são diferentes, o resultado é que os servidores da Web com design simples (versões anteriores) refletem as mesmas diferenças.

Agora, com todo esse pano de fundo, aqui estão algumas respostas específicas para as perguntas específicas:

Quando os URLs foram projetados, por que a diferenciação entre maiúsculas e minúsculas se tornou um recurso?

Por que não? Se todos os servidores da Web padrão não fizessem distinção entre maiúsculas e minúsculas, isso indicaria que os servidores da Web estavam seguindo um conjunto de regras especificado pelo padrão. Simplesmente não havia uma regra que afirma que esse caso precisa ser ignorado. A razão de não existir uma regra é simplesmente a inexistência de uma regra. Por que se preocupar em criar regras desnecessárias?

Eu pergunto isso porque me parece (ou seja, um leigo) que a distinção entre maiúsculas e minúsculas seria preferida para evitar erros desnecessários e simplificar uma sequência de texto já complicada.

URLs foram projetados para máquinas processarem. Embora uma pessoa possa digitar um URL completo em uma barra de endereço, essa não foi uma parte importante do design pretendido. O design pretendido é que as pessoas sigam ("clique em") hiperlinks. Se leigos comuns estão fazendo isso, eles realmente não se importam se o URL invisível é simples ou complicado.

Além disso, existe um verdadeiro objetivo / vantagem em ter um URL com distinção entre maiúsculas e minúsculas (em oposição à grande maioria dos URLs que apontam para a mesma página, independentemente da capitalização)?

O quinto ponto numerado da resposta de William Hay menciona uma vantagem técnica: os URLs podem ser uma maneira eficaz de um navegador da Web enviar um pouco de informações para um servidor da Web, e mais informações podem ser incluídas se houver menos restrições, portanto, a distinção entre maiúsculas e minúsculas restrição reduziria quanta informação pode ser incluída.

No entanto, em muitos casos, não há um benefício super atraente para a distinção entre maiúsculas e minúsculas, o que é comprovado pelo fato de que o IIS normalmente não se incomoda com isso.

Em resumo, o motivo mais convincente é provavelmente a simplicidade para quem projetou o software de servidor da web, particularmente em uma plataforma que diferencia maiúsculas de minúsculas como o Unix. (O HTTP não foi algo que influenciou o design original do Unix, pois o Unix é notavelmente mais antigo que o HTTP.)

Os URLs não diferenciam maiúsculas de minúsculas, apenas partes deles.
Por exemplo, nada diferencia maiúsculas de minúsculas no URL https://google.com,

Com referência ao RFC 3986 - Identificador Uniforme de Recursos (URI): Sintaxe Genérica

Primeiro, da Wikipedia , um URL se parece com:

 scheme:[//host[:port]][/]path[?query][#fragment]

(Removi a user:passwordpeça porque ela não é interessante e raramente é usada)

• scheme:

esquemas não diferenciam maiúsculas de minúsculas

• host:

O subcomponente do host não diferencia maiúsculas de minúsculas.

• path:

O componente do caminho contém dados ...

• query:

O componente de consulta contém dados não hierárquicos ...

• fragment:

Tipos de mídia individuais podem definir suas próprias restrições ou estruturas na sintaxe do identificador de fragmento para especificar diferentes tipos de subconjuntos, visualizações ou referências externas

Portanto, o schemee hostnão diferenciam maiúsculas de minúsculas.
O restante do URL faz distinção entre maiúsculas e minúsculas.

Por que o pathdiferencia maiúsculas de minúsculas?

Esta parece ser a questão principal.
É difícil responder "por que" algo foi feito se não foi documentado, mas podemos fazer um palpite muito bom.
Escolhi citações muito específicas da especificação, com ênfase nos dados .
Vamos olhar para o URL novamente:

 scheme:[//host[:port]][/]path[?query][#fragment]
 \____________________/\________________________/
        Location                 Data

• Localização - a localização tem uma forma canônica e não diferencia maiúsculas de minúsculas. Por quê? Provavelmente, para comprar um nome de domínio sem ter que comprar milhares de variantes.

• Dados - os dados são usados ​​pelo servidor de destino e o aplicativo pode escolher o que significa . Não faria sentido tornar os dados insensíveis. O aplicativo deve ter mais opções e a definição de distinção entre maiúsculas e minúsculas na especificação limitará essas opções.
  Essa também é uma distinção útil para HTTPS: os dados são criptografados , mas o host é visível.

É útil?

A distinção entre maiúsculas e minúsculas tem suas armadilhas quando se trata de cache e URLs canônicos, mas certamente é útil. Alguns exemplos:

• Base64 , que é usado em URIs de Dados .
• Os sites podem codificar dados Base64 no URL, por exemplo: http://tryroslyn.azurewebsites.net/#f:r/A4VwRgNglgxgBDCBDAziuBhOBvGB7AOxQBc4SAnKAgczLgF44AiAUQPwBMBTDuKuAlVIBCJGG
• Os encurtadores de URL utilizam /a5Bdistinção entre maiúsculas e minúsculas: podem ser diferentes de/a5b
• Como você mencionou, a Wikipedia pode diferenciar "AIDS" de "Aids".

Simples. O sistema operacional faz distinção entre maiúsculas e minúsculas. Os servidores da Web geralmente não se importam, a menos que precisem acessar o sistema de arquivos em algum momento. É aqui que o Linux e outros sistemas operacionais baseados em Unix aplicam as regras do sistema de arquivos. Nesse caso, a sensibilidade é uma parte importante. É por isso que o IIS nunca fez distinção entre maiúsculas e minúsculas; porque o Windows nunca fez distinção entre maiúsculas e minúsculas.

[Atualizar]

Houve alguns argumentos fortes nos comentários (desde que excluídos) sobre se os URLs têm algum relacionamento com o sistema de arquivos, como afirmei. Esses argumentos se tornaram acalorados. É extremamente míope acreditar que não existe um relacionamento. Absolutamente existe! Deixe-me explicar mais.

Programadores de aplicativos geralmente não são programadores internos de sistemas. Eu não estou sendo insultuoso. São duas disciplinas separadas e o conhecimento interno do sistema não é necessário para escrever aplicativos quando eles podem simplesmente fazer chamadas para o sistema operacional. Como os programadores de aplicativos não são programadores internos de sistemas, não é possível ignorar os serviços do SO. Digo isso porque esses são dois campos separados e eles raramente se cruzam. Os aplicativos são gravados para usar os serviços do SO como uma regra. Existem raras exceções, é claro.

Quando os servidores da Web começaram a aparecer, os desenvolvedores de aplicativos não tentaram ignorar os serviços do SO. Havia várias razões para isso. Um, não era necessário. Segundo, programadores de aplicativos geralmente não sabiam como ignorar os serviços do SO. Três, a maioria dos sistemas operacionais era extremamente estável e robusta, ou extremamente simples e leve, e não valia o custo.

Lembre-se de que os primeiros servidores da Web rodavam em computadores caros, como os servidores DEC VAX / VMS e o Unix do dia (Berkeley e Ultrix, além de outros) em computadores de quadro principal ou de quadro médio, e logo em seguida computadores leves, como PCs e Windows 3.1. Quando os mecanismos de pesquisa mais modernos começaram a aparecer, como o Google em 1997/8, o Windows havia se mudado para o Windows NT e outros sistemas operacionais, como Novell e Linux, também começaram a rodar servidores web. O Apache era o servidor web dominante, embora houvesse outros, como IIS e O'Reilly, que também eram muito populares. Nenhum deles ignorou os serviços do SO no momento. É provável que nenhum dos servidores da Web o faça até hoje.

Os primeiros servidores da web eram bastante simples. Eles ainda são hoje. Qualquer solicitação feita para um recurso por meio de uma solicitação HTTP existente em um disco rígido foi / é feita pelo servidor da Web através do sistema de arquivos do SO.

Os sistemas de arquivos são mecanismos bastante simples. Quando é feito um pedido de acesso a um arquivo, se esse arquivo existe, o pedido é passado para o subsistema de autorização e, se concedido, o pedido original é atendido. Se o recurso não existir ou não estiver autorizado, uma exceção será lançada pelo sistema. Quando um aplicativo faz uma solicitação, um gatilho é definido e o aplicativo aguarda. Quando a solicitação é respondida, o gatilho é acionado e o aplicativo processa a resposta da solicitação. Ainda funciona assim hoje. Se o aplicativo perceber que a solicitação foi atendida, ele continuará; se falhar, o aplicativo executará uma condição de erro no código ou morrerá se não for tratado. Simples.

No caso de um servidor da Web, supondo que uma solicitação de URL para um caminho / arquivo seja feita, o servidor da Web pega a parte do caminho / arquivo da URI (URL Request) e faz uma solicitação ao sistema de arquivos e é atendida ou lança uma exceção. O servidor da Web processa a resposta. Se, por exemplo, o caminho e o arquivo solicitados forem encontrados e o acesso concedido pelo subsistema de autorização, o servidor da Web processará a solicitação de E / S normalmente. Se o sistema de arquivos gerar uma exceção, o servidor da Web retornará um erro 404 se o arquivo for Não encontrado ou 403 Proibido se o código de razão não for autorizado.

Como alguns sistemas operacionais diferenciam maiúsculas de minúsculas e os sistemas de arquivos desse tipo requerem correspondências exatas, o caminho / arquivo solicitado ao servidor da web deve corresponder exatamente ao que existe no disco rígido. A razão para isso é simples. Servidores da Web não adivinhem o que você quer dizer. Nenhum computador faz isso sem estar programado. Servidores da Web simplesmente processam solicitações à medida que as recebem. Se a parte do caminho / arquivo da solicitação de URL que está sendo passada diretamente para o sistema de arquivos não corresponder ao que está no disco rígido, o sistema de arquivos emitirá uma exceção e o servidor da Web retornará um erro 404 Não encontrado.

É realmente esse pessoal simples. Não é ciência de foguetes. Existe um relacionamento absoluto entre a parte do caminho / arquivo de uma URL e o sistema de arquivos.

1. Os URLs afirmam ser um localizador de recursos UNIFORM e podem apontar para recursos anteriores à Web. Alguns deles diferenciam maiúsculas de minúsculas (por exemplo, muitos servidores ftp) e os URLs precisam ser capazes de representar esses recursos de uma maneira razoavelmente intuitiva.

2. A distinção entre maiúsculas e minúsculas exige mais trabalho ao procurar uma correspondência (no sistema operacional ou acima dela).

3. Se você definir URLs como servidores individuais com distinção entre maiúsculas e minúsculas, poderá implementá-los como sem distinção entre maiúsculas e minúsculas, se desejar. O contrário não é verdade.

4. A distinção entre maiúsculas e minúsculas pode não ser trivial em contextos internacionais: https://en.wikipedia.org/wiki/Dotted_and_dotless_I . O RFC1738 também permitiu o uso de caracteres fora do intervalo ASCII, desde que eles fossem codificados, mas não especificassem um conjunto de caracteres. Isso é bastante importante para algo que se autodenomina World Wide Web. Definir URLs como sem distinção entre maiúsculas e minúsculas abriria muito escopo para erros.

5. Se você estiver tentando empacotar muitos dados em um URI (por exemplo, um URI de dados ), poderá empacotar mais se as letras maiúsculas e minúsculas forem distintas.

Eu roubei do blog uma Velha e Nova Coisa o hábito de abordar questões da forma "por que isso acontece?" com a contra-pergunta "como seria o mundo, se não fosse o caso?"

Digamos que eu configurei um servidor Web para servir meus arquivos de documentos em uma pasta para que eu pudesse lê-los no telefone quando estivesse fora do escritório. Agora, na minha pasta de documentos, eu tenho três arquivos, todo.txt, ToDo.txte TODO.TXT(eu sei, mas fez sentido para mim quando eu fiz os arquivos).

Qual URL eu gostaria de usar para acessar esses arquivos? Eu gostaria de acessá-los de uma maneira intuitiva, usando http://www.example.com/docs/filename.

Digamos que eu tenha um script que permita adicionar um contato à minha agenda, o que também posso fazer pela web. Como isso deve levar seus parâmetros? Bem, eu gostaria de usá-lo como: http://www.example.com/addcontact.php?name=Tom McHenry von der O'Reilly. Mas se não havia como especificar o nome caso a caso, como eu faria isso?

Como eu diferenciaria as páginas wiki de Cat e CAT, Text e TEXT, latex e LaTeX? Desambiguar páginas, eu acho, mas prefiro apenas receber o que pedi.

Mas tudo o que parece estar respondendo à pergunta errada, de qualquer maneira.

A pergunta que eu realmente estava perguntando é: "Por que os servidores da Web 404 o fazem apenas por uma diferença de caso, quando são computadores, projetados para tornar a vida mais simples e são perfeitamente capazes de encontrar pelo menos as variações de caso mais óbvias no URL digitado que funcionaria? "

A resposta é que, embora alguns sites tenham feito isso (e melhor, eles também verifiquem outros erros de digitação), ninguém achou que vale a pena alterar a página de erro 404 padrão de um servidor da Web para fazer isso ... mas talvez eles devam?

Embora a resposta acima esteja correta e boa. Eu gostaria de acrescentar mais alguns pontos.

Para entender melhor, é preciso entender a diferença básica entre o servidor Unix (Linux) e Windows. O Unix faz distinção entre maiúsculas e minúsculas e o Windows não faz distinção entre maiúsculas e minúsculas.

O protocolo HTTP foi desenvolvido ou começou a ser implementado por volta de 1990. O protocolo HTTP foi desenvolvido por engenheiros que trabalhavam nos institutos CERN, na maioria dos dias os cientistas usavam máquinas Unix e não o Windows.

A maioria dos cientistas conhecia o Unix, então eles podem ter sido influenciados pelo sistema de arquivos no estilo Unix.

O servidor Windows foi lançado após o ano 2000. muito antes do servidor Windows se tornar popular, o protocolo HTTP estava bem maduro e a especificação estava completa.

Este poderia ser o motivo.

Como alguém deve ler um "por que foi projetado dessa maneira?" Pergunta, questão? Você está pedindo um relato historicamente preciso do processo de tomada de decisão ou está perguntando "por que alguém o projetaria dessa maneira?"?

É muito raramente possível obter uma conta historicamente precisa. Às vezes, quando as decisões são tomadas nos comitês de normas, há uma trilha documental de como o debate foi conduzido, mas nos primeiros dias da web as decisões eram tomadas às pressas por alguns indivíduos - neste caso provavelmente pelo próprio TimBL - e a lógica é improvável. ter sido escrito. Mas TimBL admitiu que cometeu erros no design de URLs - consulte http://www.dailymail.co.uk/sciencetech/article-1220286/Sir-Tim-Berners-Lee-admits-forward-slashes-web-address -mistake.html

Nos primeiros dias, os URLs eram mapeados diretamente para os nomes de arquivos, e os arquivos geralmente eram em máquinas do tipo Unix, e as máquinas do tipo Unix tinham nomes de arquivos com distinção entre maiúsculas e minúsculas. Então, meu palpite é que isso aconteceu da mesma forma para conveniência de implementação, e usabilidade (para usuários finais) nunca foi considerada. Novamente, nos primeiros dias, os usuários eram todos programadores do Unix de qualquer maneira.

Isso não tem nada a ver com o local onde você comprou seu domínio, o DNS não diferencia maiúsculas de minúsculas. Mas, o sistema de arquivos no servidor que você está usando para hospedagem é.

Isso não é realmente um problema e é bastante comum nos hosts * nix. Apenas verifique se todos os links que você escreve em suas páginas estão corretos e você não terá problemas. Para facilitar, recomendo sempre nomear suas páginas em letras minúsculas, para que você nunca precise verificar o nome ao escrever um link.

O Closetnoc está certo sobre o sistema operacional. Alguns sistemas de arquivos tratam o mesmo nome com maiúsculas e minúsculas diferentes como arquivos diferentes.

Além disso, existe um verdadeiro objetivo / vantagem em ter um URL com distinção entre maiúsculas e minúsculas (em oposição à grande maioria dos URLs que apontam para a mesma página, independentemente da capitalização)?

Sim. para evitar problemas de conteúdo duplicado.

Se você tivesse, por exemplo, os seguintes URLs:

http://example.com/page-1
http://example.com/Page-1
http://example.com/paGe-1
http://example.com/PAGE-1
http://example.com/pAGE-1

e todos apontaram para exatamente a mesma página e exatamente o mesmo conteúdo, então você teria conteúdo duplicado. Tenho certeza de que, se você tiver uma conta do console de pesquisa do Google (ferramentas para webmasters), o Google indicará isso para você.

O que eu sugiro fazer se você estiver nessa situação é usar todos os URLs em letras minúsculas e redirecionar os URLs com pelo menos uma letra maiúscula para a versão em letras minúsculas. Portanto, na lista de URLs acima, redirecione todos os URLs para o primeiro URL.

A distinção entre maiúsculas e minúsculas tem valor.

Se houver 26 letras, cada uma com capacidade de maiúsculas, são 52 caracteres.

4 caracteres tem a possibilidade de 52 * 52 * 52 * 52 combinações, igual a 7311616 combinações.

Se você não puder colocar em maiúscula os caracteres, a quantidade de combinações é 26 * 26 * 26 * 26 = 456976

Há mais de 14 vezes mais combinações para 52 caracteres do que para 26. Portanto, para armazenar dados, os URLs podem ser mais curtos e mais informações podem ser transmitidas por redes com menos dados transferidos.

É por isso que você vê o YouTube usando URLs como https://www.youtube.com/watch?v=xXxxXxxX