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

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

Eu entendo que pode parecer um tipo provocativo (e “advogado do diabo”) de pergunta retórica, mas acho que é útil considerar. O design do HTTP é que um “cliente”, que normalmente chamamos de “navegador da web”, solicita dados ao “servidor da web”.

Há muitos, muitos servidores da web diferentes que são lançados. A Microsoft lançou o IIS com Windows Sistemas operacionais de servidor (e outros, incluindo Windows XP Professional) .Unix tem pesos pesados como nginx e Apache, sem mencionar ofertas menores como o httpd interno do OpenBSD, ou thttpd ou lighttpd. Além disso, muitos dispositivos com capacidade de rede possuem servidores web integrados que podem ser usados para configurar o dispositivo, incluindo dispositivos com finalidades específicas de redes, como roteadores (incluindo muitos pontos de acesso Wi-Fi e modems DSL) e outros dispositivos como impressoras ou UPSs (unidades de fonte de alimentação ininterrupta com bateria) que podem ter conectividade de rede.

Portanto, a pergunta, “Por que os URLs diferenciam maiúsculas de minúsculas?”, É: “Por que os servidores da web tratam o URL como sendo sensível a maiúsculas e minúsculas? ” E a resposta real é: eles não fazem isso. Pelo menos um servidor da web, que é bastante popular, normalmente NÃO diferencia maiúsculas de minúsculas. (O servidor da web é o IIS.)

Um dos principais motivos para o comportamento diferente entre diferentes servidores web provavelmente se resume a uma questão de simplicidade. A maneira simples de fazer um servidor web é fazer as coisas da mesma maneira como o sistema operacional do computador / dispositivo localiza os arquivos. Muitas vezes, os servidores da web localizam um arquivo para fornecer uma resposta. O Unix foi projetado para computadores de ponta 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, eles são diferentes. Essa é a coisa direta e natural a fazer. O Windows tem um histórico de não fazer distinção entre maiúsculas e minúsculas devido ao desejo de oferecer suporte a software já criado, e essa história 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 usam menos memória. Como esses sistemas operacionais são diferentes, o resultado é que os servidores da web de design simples (versões anteriores) refletem as mesmas diferenças.

Agora, com tudo isso pano de fundo, aqui estão algumas respostas específicas às perguntas específicas:

Quando os URLs foram projetados pela primeira vez, por que a diferenciação de maiúsculas e minúsculas tornou-se um recurso?

Por que não? Se todos os servidores da web padrão não diferenciassem maiúsculas de minúsculas, isso indicaria que os servidores da web estavam seguindo um conjunto de regras especificadas pelo padrão. Simplesmente não havia regra que diz que o caso precisa ser ignorado. A razão de não haver regra é simplesmente que não havia razão para haver tal regra. Por que se preocupar em inventar regras desnecessárias?

Pergunto isso porque me parece (ou seja,, um leigo) que não faz distinção entre maiúsculas e minúsculas seria preferível 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, isso não era uma parte importante do design pretendido. O design pretendido é que as pessoas seguiriam (“clique em”) hiperlinks. Se leigos comuns estão fazendo isso, então eles realmente não se preocupe se o URL invisível é simples ou complicado.

Além disso, há um propósito / vantagem real em ter um URL que diferencia maiúsculas de minúsculas (como oposto à grande maioria dos URLs que apontam para a mesma página, independentemente da capitalização)?

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

No entanto, em muitos casos, não há um benefício super convincente para a diferenciação de maiúsculas comprovado pelo fato de que o IIS normalmente não se preocupa com isso.

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

Comentários

• ” Um dos principais motivos para o comportamento diferente entre diferentes navegadores da web provavelmente se resume a uma questão de simplicidade. ” – Presumo que você significa ” servidores da web “, em vez de ” navegadores da web ” aqui e em alguns outros lugares?
• Atualizado. Revisado todos os casos de ” navegadores ” e fez várias substituições. Obrigado por apontar isso para que a qualidade pudesse ser melhorada.
• Recebi várias respostas excelentes à minha pergunta, variando de históricas a o técnico. Estou hesitante em ir contra a corrente e aceitar uma resposta de classificação inferior, mas a resposta de @TOOGAM ‘ foi a mais útil para mim. Essa resposta é completa e extensa, mas explica o conceito de uma forma descomplicada e coloquial que posso entender. E eu acho que esta resposta é uma boa introdução para as explicações mais detalhadas.
• A razão pela qual o Windows tem um sistema de arquivos que não diferencia maiúsculas de minúsculas é devido a ele ‘ s Herança do DOS. O MS-DOS começou a vida em computadores como o Tandy TRS-80, que usava uma TV como monitor e, originalmente, não suportava letras minúsculas devido à falta de resolução. Uma vez que não podia ‘ exibir letras minúsculas, a combinação de letras não era ‘ suportada. O MS-DOS foi licenciado pela IBM para se tornar o PC-DOS original. Embora o PC original pudesse exibir letras minúsculas, o sistema de arquivos foi transferido como está a partir do MS-DOS.

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 a RFC 3986 – Uniform Resource Identifier (URI): Sintaxe genérica

Primeiro, de Wikipedia , um URL se parece com:

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

(Eu removi o user:password parte porque não é interessante e raramente é usado)

• scheme :

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

• host :

O subcomponente 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 dentro da sintaxe do identificador de fragmento para especificar diferentes tipos de subconjuntos, visualizações ou referências externas

Portanto, scheme e host não diferenciam maiúsculas de minúsculas.
O resto de o URL diferencia maiúsculas de minúsculas.

Por que path diferencia maiúsculas de minúsculas?

Esta parece ser a pergunta principal.
É difícil responder “por que” algo foi feito se não estava documentado, mas podemos dar um bom palpite.
Eu escolhi citações muito específicas da especificação, com ênfase em data .
Vejamos o URL novamente:

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

• Local – O local tem uma forma canônica e não faz distinção entre maiúsculas e minúsculas. Porque? Provavelmente para que você pudesse 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 deixar os dados sem distinção entre maiúsculas e minúsculas. O aplicativo deve ter mais opções, e definir a não diferenciação de 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?

Caso- sensibilidade tem suas armadilhas quando se trata de caching 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/A4VwRgNglgxgBDCBDAziuBhOBvGB7AOxQBc4SAnKAgczLgF44AiAUQPwBMBTDuKuYgAsucAKoAlADIBCJgG4AvkA
• Os encurtadores de URL utilizam a diferenciação de maiúsculas e minúsculas: /a5B pode ser diferente de /a5b
• Como você mencionou, a Wikipedia pode diferenciar “AIDS” de “Aids”.

Comentários

• ” URLs não são cas Sensível a e. ” / ” O resto do URL diferencia maiúsculas de minúsculas. ” – Isso parece uma contradição?
• Na verdade, o esquema define o que esperar do resto do URL. http: e esquemas relacionados significam que o URL se refere a um nome de host DNS. O DNS não fazia distinção entre maiúsculas e minúsculas ASCII muito antes da invenção dos URLs. Consulte a página 55 de ietf.org/rfc/rfc883.txt
• Muito bem detalhado! Eu estava indo de um ponto de vista histórico. Originalmente, era o caminho do arquivo que precisava fazer distinção entre maiúsculas e minúsculas apenas se você estivesse acessando o sistema de arquivos. Caso contrário, não foi. Mas hoje, as coisas mudaram. Por exemplo, parâmetros e CGI não existiam originalmente. Sua resposta leva uma perspectiva do dia atual. Tive que recompensar seus esforços !! Você realmente cavou fundo nisso! Quem diria que isso iria explodir do jeito que explodiu ?? Saúde !!
• @ w3dk: it ‘ é uma peculiaridade terminológica não muito interessante, mas você poderia escolher ” diferencia maiúsculas de minúsculas ” para significar, ” alterar a caixa de um caractere pode alterar todo o “, ou pode ser interpretado como ” alterar a caixa de um caractere sempre muda todo o “. Kobi parece estar afirmando o último, ele prefere que a distinção entre maiúsculas e minúsculas signifique ” qualquer mudança no caso é significativa “, o que é claro não é verdade para URLs. Você prefere o primeiro. É ‘ é apenas uma questão de quão eles são sensíveis a maiúsculas e minúsculas.
• @ rybo111: Se um usuário digitar example.com/fOObaR , a especificação exige que o servidor em www.example.com receba um caminho ” / fOObaR ” conforme fornecido; ele não questiona se o servidor deve tratar isso de maneira diferente de ” / foOBaR “.

Simples. O sistema operacional é sensível a 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 ponto. É aqui que o Linux e outros sistemas operacionais baseados em Unix impõem as regras do sistema de arquivos, em que a distinção entre maiúsculas e minúsculas é uma parte importante. É por isso que IIS nunca fez distinção entre maiúsculas e minúsculas; porque o Windows nunca foi sensível a maiúsculas e minúsculas.

[Atualizar]

Houve alguns argumentos fortes nos comentários (desde que foram excluídos) sobre se os URLs têm alguma relação com o sistema de arquivos, conforme afirmei. Esses argumentos ficaram acalorados. É extremamente míope acreditar que não existe um relacionamento. Com certeza existe! Deixe-me explicar melhor.

Os programadores de aplicativos geralmente não são programadores internos de sistemas. Eu não estou sendo insultante. Eles são duas disciplinas separadas e o conhecimento interno do sistema não é necessário para escrever aplicativos quando os aplicativos 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 contornar os serviços do sistema operacional.Digo isso porque esses são dois campos separados e raramente se cruzam. Os aplicativos são escritos para usar os serviços do sistema operacional como regra. Existem raras exceções, é claro.

Quando os servidores web começaram a aparecer, os desenvolvedores de aplicativos não tentavam contornar os serviços do sistema operacional. Houve várias razões para isso. Um, não era necessário. Dois, os programadores de aplicativos geralmente não sabiam como contornar os serviços do sistema operacional. Três, a maioria dos sistemas operacionais eram extremamente estáveis e robustos ou extremamente simples e leves e não valiam o custo.

Lembre-se de que os primeiros servidores da web eram executados em computadores caros, como o DEC VAX / Servidores VMS e o Unix da época (Berkeley e Ultrix, bem como outros) em computadores main-frame ou mid-frame, logo depois em computadores leves como PCs e Windows 3.1. Quando os motores de busca mais modernos começaram a aparecer, como o Google em 1997/8, o Windows mudou 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 da Web dominante, embora existissem outros, como IIS e O “Reilly, que também eram muito populares. Nenhum deles na época contornou os serviços do sistema operacional. É provável que nenhum dos servidores da Web o faça até hoje.

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

Os sistemas de arquivos são mecanismos bastante simples. Como uma solicitação é feita para acessar um arquivo, se esse arquivo existir, a solicitação é passada para o subsistema de autorização e, se concedida, a solicitação original é satisfeita. Se o recurso existir não existe ou não está autorizado, uma exceção é lançada pelo sistema. Quando um aplicativo faz uma solicitação, um gatilho é definido e o aplicativo espera. Quando a solicitação é respondida, o gatilho é lançado e o aplicativo processa a resposta da solicitação. ainda funciona assim hoje. Se o aplicativo perceber que a solicitação foi s atisfied ele continua; se tiver falhado, o aplicativo executa uma condição de erro dentro de seu código ou morre se não for tratado. Simples.

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

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

É realmente simples assim. Não é ciência de foguetes. Existe uma relação absoluta entre a porção do caminho / arquivo de uma URL e o sistema de arquivos.

Comentários

• Acho que seu argumento é falho. Embora Berners-Lee não ‘ tenha qualquer escolha sobre a distinção entre maiúsculas e minúsculas de URLs de ftp. Ele conseguiu criar URLs http. Ele poderia ter especificado apenas US-ASCII e não diferencia maiúsculas de minúsculas. Se alguma vez existiu algum servidor da web que acabou de passar o caminho da URL para o sistema de arquivos, então eles eram inseguros e a introdução da codificação de URL quebrou a compatibilidade com eles. Dado que o caminho está sendo processado antes de passar para o caso de esmagamento do SO, teria sido fácil de implementar. Portanto, acho que devemos considerar isso uma decisão de design, não uma peculiaridade de implementação.
• @WilliamHay Isso não tem nada a ver com Berners-Lee ou o design da web. Trata-se de limitações e requisitos do sistema operacional. Eu sou um engenheiro interno de sistemas aposentado. Eu trabalhei nesses sistemas na época. Estou dizendo exatamente por que os URLs diferenciam maiúsculas de minúsculas. Não é um palpite. Não é uma opinião. É um fato. Minha resposta foi simplificada intencionalmente. É claro que há verificações de arquivos e outros processos que podem ser feitos antes de emitir qualquer declaração aberta. E sim (!) Os servidores da web ainda são parcialmente inseguros até hoje.
• Se os URLs diferenciam maiúsculas de minúsculas não tem nada a ver com o design da web? Sério? Argumento da Autoridade seguido de Argumento por Asserção.O fato de os servidores da web passarem o componente do caminho de uma URL mais ou menos diretamente para uma chamada aberta é uma consequência do design das URLs, não uma causa disso. Os servidores (ou smart clients no caso de FTP) podem ter ocultado do usuário a distinção entre maiúsculas e minúsculas dos sistemas de arquivos. Que não ‘ é uma decisão de design.
• @WilliamHay Você precisa diminuir a velocidade do funil de grama e reler o que escrevi. Sou um engenheiro interno de sistemas aposentado, escrevendo componentes do sistema operacional, pilhas de protocolo e código de roteador para ARPA-Net, etc. Trabalhei com Apache, O ‘ Reilly e internos IIS. Seu argumento FTP não se sustenta, pois pelo menos os principais servidores FTP diferenciam maiúsculas de minúsculas pelo mesmo motivo. Em nenhum momento eu disse nada sobre design de URL / URI. Em nenhum momento eu disse que servidores web passavam valores sem processamento. Eu disse que os serviços do SO são comumente usados e que o sistema de arquivos requer uma correspondência exata para ter sucesso.
• @WilliamHay Por favor, entenda que você e eu estamos pensando em objetivos opostos. Tudo o que eu disse em minha resposta é que, para alguns sistemas operacionais, as chamadas do sistema de arquivos diferenciam maiúsculas de minúsculas por design. Os aplicativos que usam chamadas de sistema, e a maioria o faz, são limitados à aplicação das regras do sistema operacional – neste caso, distinção entre maiúsculas e minúsculas. Não é impossível contornar esta regra. Na verdade, isso pode ser um tanto trivial em alguns casos, embora não seja prático. Eu costumava ignorar rotineiramente o sistema de arquivos em meu trabalho para decodificar discos rígidos que ficaram danificados por um motivo ou outro ou para analisar dados internos de arquivos de banco de dados, etc.

1. URLs afirmam ser um localizador de recursos UNIFORME 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 não diferenciação de maiúsculas e minúsculas requer mais trabalho ao procurar por uma correspondência (no sistema operacional ou acima dele).

3. Se você definir URLs como diferenciando maiúsculas de minúsculas, os servidores individuais podem implementá-los como não diferenciando maiúsculas de minúsculas, se quiserem. O inverso não é verdadeiro.

4. A insensibilidade a maiúsculas e minúsculas pode não ser trivial em contextos internacionais: https://en.wikipedia.org/wiki/Dotted_and_dotless_I . Além disso, o RFC1738 permitia o uso de caracteres fora do intervalo ASCII, desde que fossem codificados, mas não especificassem um conjunto de caracteres. Isso é bastante importante para algo que se autodenomina WORLD wide web. Definir URLs como indiferentes a maiúsculas abriria muito espaço para bugs.

5. Se você está tentando empacotar muitos dados em um URI (por exemplo, um URI de dados ) você pode compactar mais se maiúsculas e minúsculas forem diferentes.

Comentários

• I ‘ tenho certeza de que os URLs eram historicamente limitados a ASCII. Portanto, a internacionalização não deve ser o motivo original. A história do Unix diferenciando maiúsculas de minúsculas, OTOH, provavelmente desempenhou um papel importante.
• Embora apenas um subconjunto de ASCII possa ser usado não codificado em um URL, RFC1738 afirma especificamente que caracteres fora do intervalo ASCII podem ser usados codificados. Sem especificar um conjunto de caracteres, não é ‘ possível saber quais octetos representam o mesmo char acter, exceto para o caso. Atualizado.
• Referente ao nº 4: ‘ é realmente pior do que isso. Pontilhado e sem ponto I são uma demonstração do princípio mais geral de que, mesmo se tudo for UTF-8 (ou algum outro UTF), você não pode capitalizar ou minúsculas corretamente sem saber a localidade a que o texto pertence . No local padrão, uma letra I maiúscula latina minúscula para uma letra latina minúscula i, o que está errado em turco porque adiciona um ponto (não há ” I maiúsculo turco sem ponto ” ponto de código; você ‘ pretende usar o ponto de código ASCII). Acrescente diferenças de codificação, e isso vai de ” muito difícil ” a ” completamente intratável . ”

Eu roubei do blog e Old New Thing o hábito de abordar questões do tipo “por que algo é assim?” com a contra-pergunta “como seria o mundo, se não fosse o caso?”

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

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

Digamos que eu tenha um script que me permite adicionar um contato à minha lista de endereços, que posso também na web.Como isso deve levar seus parâmetros? Bem, eu gostaria de usá-lo assim: http://www.example.com/addcontact.php?name=Tom McHenry von der O"Reilly. Mas se não houvesse nenhuma maneira de especificar o nome por caso, como faria isso?

Como eu diferenciaria as páginas wiki de Cat e CAT, Texto e TEXTO, latex e LaTeX? Desambiguação de páginas, eu acho, mas prefiro apenas obter o que pedi.

Mas parece como se estivesse respondendo à pergunta errada, de qualquer maneira.

A pergunta que eu acho que você estava realmente se perguntando é “Por que os servidores web 404 você só para um caso de diferença, quando eles são computadores, projetados para tornar a vida mais simples , e eles são perfeitamente capazes de encontrar pelo menos as variações de caso mais óbvias no URL que digitei que funcionariam? “

A resposta é que embora alguns sites tenham feito isso (e melhor, eles verifique se há outros erros de digitação também), ninguém achou que valeria a pena alterar a página de erro 404 padrão de um servidor da web para fazer isso … mas talvez devessem?

Comentários

• Alguns sites usam algum tipo de mecanismo para converter um qualquer consulta em letras minúsculas ou algo consistente. De certa forma, isso é inteligente.
• Não, eles não deveriam ‘ t. Essa funcionalidade pode ser, e muitas vezes é, adicionada quando for desejável (por exemplo, por módulos no apache). Impor esse tipo de mudança como comportamento padrão – ou pior, comportamento imutável – seria mais perturbador do que o relativamente raro ocasião em que alguém precisa digitar manualmente um URL além do nome do host. Para obter um bom exemplo de por que não fazer isso, lembre-se do fiasco quando Network Solutions ” corrigiu ” erros de domínio inexistentes de DNS público consultas.
• @SirNickity Ninguém estava propondo imutabilidade em qualquer nível e as páginas de erro do servidor web são configuráveis em cada servidor web que eu ‘ já usei; ninguém estava sugerindo substituir os códigos 404 por 30 *, mas sim adicionar uma lista de links de sugestões clicáveis à página de erro; nomes de domínio são um tópico e problema muito diferente, não diferenciando maiúsculas de minúsculas e em um contexto de segurança diferente; e o IIS já ” corrige ” automaticamente (ignorando) diferenças de maiúsculas e minúsculas no caminho ou nas partes do nome de arquivo dos URIs.
• Desde 1996, o Apache permite que você faça isso com mod_speling . Simplesmente não ‘ não parece ser uma coisa muito popular de se fazer. As pessoas do Unix / Linux veem a insensibilidade a maiúsculas e minúsculas como a regra, a insensibilidade a maiúsculas e minúsculas como exceção.

Embora o a resposta acima está correta & boa. Eu gostaria de acrescentar mais alguns pontos.

Para entender melhor, deve-se entender a diferença básica entre o servidor Unix (Linux) Vs Windows. Unix diferencia maiúsculas de minúsculas & O Windows não diferencia maiúsculas de 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 trabalham na Os institutos do CERN, na maioria dos dias, os cientistas usavam máquinas Unix e não o Windows.

A maioria dos cientistas estava familiarizada com o Unix, então eles podem ter sido influenciados pelo sistema de arquivos do estilo Unix.

O servidor Windows foi lançado após 2000. muito antes do servidor Windows se tornar popular, o protocolo HTTP estava bem amadurecido e as especificações estavam completas.

Esse pode ser o motivo.

Comentários

• ” O servidor Windows foi lançado após 2000. ” A equipe do Windows NT 3.1 teria discordado de você em 1993. NT 3.51 em 1995 foi provavelmente quando o NT começou a se tornar maduro e bem estabelecido o suficiente para suportar aplicativos de servidor críticos para os negócios.
• NT 3.51 tinha a interface Win 3.1. O Windows não decolou realmente até o Windows 95 e demorou o NT 4.0 para obter a mesma interface.
• Michael Kj ö rling, concordou. Deixe-me modificá-lo.
• @Thorbj ø rnRavnAndersen No mercado de servidores, o NT 3.51 foi razoavelmente bem-sucedido. No mercado de consumidor / consumidor, demorou até o Windows 2000 (NT 5.0) antes que a linha NT começasse a ganhar força.
• Na verdade, o WorldWideWeb foi inicialmente desenvolvido em sistemas baseados em Unix, que diferenciam maiúsculas de minúsculas sistemas de arquivos e a maioria dos URLs mapeados diretamente para arquivos no sistema de arquivos.

Como se deve ler a “por que foi projetado dessa forma?” pergunta? Você está pedindo um relato historicamente preciso do processo de tomada de decisão ou “por que alguém iria projetá-lo dessa maneira?”?

É muito raramente possível obter um histórico preciso conta.Às vezes, quando as decisões são tomadas em comitês de padrões, há uma trilha documental de como o debate foi conduzido, mas nos primeiros dias da web as decisões eram feitas às pressas por alguns indivíduos – neste caso provavelmente pelo próprio TimBL – e a justificativa é 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 nomes de arquivos, e os arquivos geralmente estavam em máquinas do tipo Unix, e as máquinas do tipo Unix têm nomes de arquivo com distinção entre maiúsculas e minúsculas. Então, meu palpite é que aconteceu dessa forma para conveniência de implementação, e usabilidade (para usuários finais) nunca foi sequer considerada. Novamente, nos primeiros dias, os usuários eram todos programadores Unix de qualquer maneira.

Comentários

• Os usuários finais também eram usuários Unix (não necessariamente programadores, mas físicos de alta energia e semelhantes), então eles também estavam acostumados a não diferenciar maiúsculas de minúsculas.

Isto não tem nada a ver com onde você comprou o 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 é.

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

O Closetnoc está certo sobre o SO. Alguns sistemas de arquivos tratam o mesmo nome com capitalização diferente como arquivos diferentes.

Além disso, há um propósito / vantagem real em ter um URL que diferencia maiúsculas de minúsculas (ao contrário da grande maioria dos URLs que apontam para a mesma página, independentemente a 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 apontassem exatamente para a mesma página com exatamente o mesmo conteúdo, então você teria conteúdo duplicado e tenho certeza de que tem um console de pesquisa do Google (ferramentas para webmaster), o Google indicará isso para você.

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

Comentários

• ” Sim. para evitar problemas de conteúdo duplicado. ” – Mas o oposto parece ser verdade? O fato de que os URLs podem diferenciar maiúsculas de minúsculas (e é assim que os mecanismos de pesquisa os tratam) causa os problemas de conteúdo duplicado que você menciona. Se os URLs não fizessem distinção entre maiúsculas e minúsculas, não haveria problemas de conteúdo duplicado com letras maiúsculas e minúsculas. page-1 seria o mesmo que PAGE-1.
• Acho que uma configuração de servidor ruim é o que pode causar conteúdo duplicado quando se trata de capitalização. Por exemplo, a instrução RewriteRule ^request-uri$ /targetscript.php [NC] armazenada em .htaccess corresponderia a http://example.com/request-uri e http://example.com/ReQuEsT-Uri porque o [NC] indica que a capitalização não ‘ importa ao avaliar aquela expressão regular.

A diferenciação de maiúsculas e minúsculas tem valor.

Se houver 26 letras, cada uma delas podendo ser maiúscula, são 52 caracteres.

4 caracteres têm a possibilidade de 52 * 52 * 52 * 52 combinações, igualando 7311616 combinações.

Se você não pode capitalizar os caracteres, a quantidade de combinações é 26 * 26 * 26 * 26 = 456976

Existem 14 vezes mais combinações para 52 caracteres do que existem para 26. Portanto, para armazenar dados, os URLs podem ser mais curtos e mais informações podem ser transmitidas pelas redes com menos transferência de dados.

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