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

54

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.

Kyle
fonte
11
Você obviamente não executa o IIS no Windows
John Conde
53
Imagino que itscrap.com, expertsexchange e whorepresents.com prefiram que mais pessoas usem nomes com distinção entre maiúsculas e minúsculas. Para mais informações, consulte boredpanda.com/worst-domain-names .
Eric Towers
22
Os URLs foram projetados quando dinossauros renderizados em sistemas Unix vagavam pela Terra, e o Unix diferencia maiúsculas de minúsculas.
Thorbjørn Ravn Andersen
11
A Wikipedia tenta usar a capitalização correta para o título do assunto e usa redirecionamentos para diferenças comuns. por exemplo. html, htmE Htmltodos redirecionamento para HTML. Mas o mais importante é que, devido ao enorme assunto, é possível ter mais de uma página em que a URL difere apenas por caso. Por exemplo: Látex e Látex
MrWhite 23/02
7
@ edc65 Mas Kobi afirma que partes da URL (principalmente o caminho ) fazem distinção entre maiúsculas e minúsculas - então, isso não torna a URL (como um todo) diferencia maiúsculas de minúsculas?
MrWhite 23/02

Respostas:

8

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.)

TOOGAM
fonte
"Uma das principais razões para um comportamento diferente entre diferentes navegadores da Web provavelmente se resume a uma questão de simplicidade." - Presumo que você queira dizer "servidores da web", em vez de "navegadores da web" aqui e em alguns outros lugares?
MrWhite
2
Atualizada. Analisou todos os casos de "navegadores" e fez várias substituições. Obrigado por apontar isso para que alguma qualidade possa ser melhorada.
TOOGAM 24/02
11
Recebi várias respostas excelentes para minha pergunta, desde o histórico até o técnico. Hesito em ir contra a corrente e aceitar uma resposta de classificação mais baixa, mas a resposta da @ TOOGAM foi a mais útil para mim. Essa resposta é completa e abrangente, mas explica o conceito de uma maneira descomplicada e conversacional que eu possa entender. E acho que essa resposta é uma boa introdução às explicações mais aprofundadas.
Kyle
74

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)

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

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

O componente do caminho contém dados ...

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

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:

Kobi
fonte
11
"URLs não diferenciam maiúsculas de minúsculas." / "O restante do URL faz distinção entre maiúsculas e minúsculas." - Isso parece ser uma contradição?
MrWhite
8
Na verdade, o esquema define o que esperar no restante da URL. http:e esquemas relacionados significam que o URL se refere a um nome de host DNS. O DNS não diferenciava maiúsculas de minúsculas ASCII muito antes da invenção de URLs. Veja a página 55 de ietf.org/rfc/rfc883.txt
O. Jones
3
Bem detalhado! Eu estava indo de um ponto de vista histórico. Originalmente, era o caminho do arquivo que precisava diferenciar maiúsculas de minúsculas 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 tem uma perspectiva atual. Eu tive que recompensar seus esforços !! Você realmente se interessou por este! Quem sabia que isso iria explodir da maneira que aconteceu? Felicidades!!
Closetnoc 23/02/16
2
@ w3dk: é uma peculiaridade não muito interessante da terminologia, mas você pode considerar "sensível a maiúsculas" como "mudar a maiúsculas e minúsculas de um personagem pode mudar o todo", ou você pode entender "mudar a o caso de um personagem sempre muda o todo ". Kobi parece estar afirmando o último, ele prefere que a distinção entre maiúsculas e minúsculas deva significar "qualquer mudança no caso é significativa", o que obviamente não é verdade para URLs. Você prefere o primeiro. É apenas uma questão de quão sensível eles são ao caso.
Steve Jessop
2
@ rybo111: Se um usuário digitar example.com/fOObaR , as especificações exigirão que o servidor em www.example.com receba o caminho "/ fOObaR", conforme indicado; fica em silêncio a questão de saber se o servidor deve tratar isso de maneira diferente de "/ foOBaR".
Supercat 24/02
59

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.

closetnoc
fonte
11
Eu acho que seu argumento é falho. Embora Berners-Lee não tenha escolha sobre a distinção entre maiúsculas e minúsculas dos URLs ftp. Ele conseguiu criar URLs http. Ele poderia tê-los especificado apenas como US-ASCII e não faz distinção entre maiúsculas e minúsculas. Se já houve algum servidor da Web que acabou de passar o caminho da URL para o sistema de arquivos, 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 da entrega ao caso de esmagamento do SO, seria fácil de implementar. Portanto, acho que devemos considerar isso como uma decisão de design, não como uma peculiaridade de implementação.
William Hay
@WilliamHay Isso não tem nada a ver com Berners-Lee ou com o design da web. Trata-se de limitações e requisitos do sistema operacional. Sou 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 intencionalmente simplificada. É claro que existem verificações de arquivos e outros processos que podem ser feitos antes da emissão de qualquer declaração aberta. E, como resultado, os servidores da Web Sim (!) São parcialmente inseguros até hoje.
Closetnoc 29/02
Se os URLs diferenciam maiúsculas de minúsculas não tem nada a ver com o design da web? Realmente? Argumento de Autoridade seguido de Argumento por Asserção. O fato de os servidores da Web passarem o componente de caminho de um URL mais ou menos diretamente para uma chamada aberta é uma conseqüência do design dos URLs, não uma causa disso. Servidores (ou clientes inteligentes no caso de FTP) podem ter ocultado a distinção entre maiúsculas e minúsculas dos sistemas de arquivos do usuário. O fato de não fazerem é uma decisão de design.
William Hay
@WilliamHay Você precisa desacelerar a tremonha de grama e reler o que escrevi. Sou engenheiro interno de sistemas aposentado, escrevendo componentes de SO, pilhas de protocolo e código de roteador para o ARPA-Net, etc. Trabalhei com internos de Apache, O'Reilly e IIS. Seu argumento FTP não retém a água, pois pelo menos os principais servidores FTP permanecem sensíveis a maiúsculas e minúsculas pelo mesmo motivo. Em nenhum momento eu disse algo sobre design de URL / URI. Em nenhum momento eu disse que os servidores da 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.
precisa saber é o seguinte
@ WilliamHay Por favor, entenda que você e eu estamos pensando em objetivos diferentes. Tudo o que eu estava dizendo na 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 do sistema, e a maioria deles, estão limitados à imposição das regras do SO - nesse caso, diferenciação de maiúsculas e minúsculas. Não é impossível ignorar esta regra. De fato, isso pode ser um tanto trivial em alguns casos, embora não prático. Eu costumava rotineiramente desvio do sistema de arquivos no meu trabalho para discos rígidos desembaralhar que foram kablooie por uma razão ou outra, ou para analisar internos de arquivo de banco de dados, etc.
closetnoc
21
  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.

William Hay
fonte
11
Tenho certeza de que os URLs eram historicamente limitados ao ASCII. Portanto, é improvável que a internacionalização seja uma razão original. A história do Unix que diferencia maiúsculas de minúsculas, OTOH, provavelmente teve um papel importante.
derobert 23/02
Embora apenas um subconjunto de ASCII possa ser usado não codificado em um URL, o RFC1738 especifica especificamente caracteres fora do intervalo ASCII que podem ser usados ​​codificados. Sem especificar um conjunto de caracteres, não é possível saber quais octetos representam o mesmo caractere, exceto no caso. Atualizada.
William Hay
11
Re # 4: Na verdade, é pior que isso. Pontilhado e sem ponto Eu sou uma demonstração do princípio mais geral de que, mesmo que tudo seja UTF-8 (ou algum outro UTF), você não pode usar maiúsculas ou minúsculas corretamente sem conhecer o local ao qual o texto pertence. No código do idioma padrão, uma letra latina maiúscula I é minúscula para uma letra minúscula latina i, que está incorreta em turco porque adiciona um ponto (não existe um ponto de código "Turco I sem ponto maiúsculo"; você deve usar o código ASCII ponto). Lance diferenças de codificação, e isso vai de "realmente difícil" a "completamente intratável".
Kevin
5

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?

Dewi Morgan
fonte
11
Alguns sites usam algum tipo de mecanismo para converter qualquer consulta em minúscula ou em algo consistente. De certa forma, isso é inteligente.
Closetnoc 24/02
Não, eles não deveriam. Essa funcionalidade pode ser, e geralmente é, adicionada quando é desejável (por exemplo, por módulos no apache.) Impor esse tipo de alteração 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 um bom exemplo de por que não fazer isso, lembre-se do fiasco quando a Network Solutions "corrigiu" erros de domínio inexistentes de consultas DNS públicas.
25416 SirNickity
@SirNickity Ninguém estava propondo imutabilidade em nenhum nível e as páginas de erro do servidor da web são configuráveis ​​em todos os servidores da web que eu já usei; ninguém sugeria substituir 404 por 30 * códigos, mas adicionar uma lista de links de sugestões clicáveis ​​por humanos à página de erro; nomes de domínio são um tópico e um problema muito diferentes que não diferenciam 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 nas partes do caminho ou nome do arquivo dos URIs.
Dewi Morgan
Desde 1996, o Apache permite fazer isso com mod_speling . Simplesmente não parece ser uma coisa muito popular a se fazer. O pessoal do Unix / Linux vê a insensibilidade a maiúsculas e minúsculas como regra, a insensibilidade a maiúsculas e minúsculas como exceção.
Reinierpost
4

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.

Mani
fonte
2
"O servidor Windows foi lançado após 2000." A equipe do Windows NT 3.1 teria discordado de você em 1993. O 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.
um CVn
NT 3.51 tinha a interface do Windows 3.1. O Windows não decolou realmente até o Windows 95 e o NT 4.0 levou a mesma interface.
Thorbjørn Ravn Andersen
Michael Kjörling, concordou. Deixe-me modificá-lo.
Mani
11
@ ThorbjørnRavnAndersen No mercado de servidores, o NT 3.51 foi razoavelmente bem-sucedido. No mercado de consumidor / prosumer, levou até o Windows 2000 (NT 5.0) antes que a linha NT começasse a ganhar força.
a CVn
De fato, o WorldWideWeb foi desenvolvido inicialmente em sistemas baseados em Unix, que possuem sistemas de arquivos com distinção entre maiúsculas e minúsculas, e a maioria das URLs mapeadas diretamente para arquivos no sistema de arquivos.
Reinierpost
4

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.

Michael Kay
fonte
Os usuários finais também eram usuários do Unix (não necessariamente programadores, mas físicos de alta energia e afins); portanto, eles também estavam acostumados à insensibilidade ao caso.
Reinierpost
3

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.

adnan3344
fonte
2

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.

Mike
fonte
"Sim. Para evitar problemas de conteúdo duplicado." - Mas o oposto parece ser verdade? O fato de os URLs diferenciarem maiúsculas de minúsculas (e é assim que os mecanismos de pesquisa os tratam) causa os problemas de conteúdo duplicado mencionados. Se os URLs não diferissem entre maiúsculas e minúsculas, não haveria problemas de conteúdo duplicado com maiúsculas e minúsculas diferentes. page-1seria o mesmo que PAGE-1.
MrWhite
Eu acho que uma configuração de servidor ruim é o que pode causar conteúdo duplicado quando se trata de revestimento. Por exemplo, a instrução RewriteRule ^request-uri$ /targetscript.php [NC]armazenada em .htaccess corresponderia http://example.com/request-urie http://example.com/ReQuEsT-Uriporque [NC]indica que o caso não importa ao avaliar essa expressão regular.
24516 Mike
1

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

Michael d
fonte