¿Por qué las URL distinguen entre mayúsculas y minúsculas?

Mi pregunta: cuando se diseñaron las URL por primera vez, ¿por qué la distinción entre mayúsculas y minúsculas se convirtió en una característica? Pregunto esto porque me parece (es decir, un laico) que se preferiría la mayúsculas y minúsculas para evitar errores innecesarios y simplificar una cadena de texto ya complicada.

Además, ¿existe un propósito / ventaja real de tener una URL que distinga entre mayúsculas y minúsculas (a diferencia de la gran mayoría de las URL que apuntan a la misma página sin importar las mayúsculas)?

Wikipedia, por ejemplo, es un sitio web sensible a las mayúsculas y minúsculas (excepto el primer carácter):

https://en.wikipedia.org/wiki/St Un ck_Exchange es DOA.

¿Por qué la URL no distingue entre mayúsculas y minúsculas?

Entiendo que puede parecer un tipo de pregunta retórica provocativa (y "defensora del diablo"), pero creo que es útil considerarla. El diseño de HTTP es que un "cliente", que comúnmente llamamos un "navegador web", solicita datos al "servidor web".

Hay muchos, muchos servidores web diferentes que se lanzan. Microsoft ha lanzado IIS con sistemas operativos Windows Server (y otros, incluido Windows XP Professional). Unix tiene pesos pesados ​​como nginx y Apache, sin mencionar ofertas más pequeñas como httpd, thttpd o lighttpd interno de OpenBSD. Además, muchos dispositivos con capacidad de red tienen servidores web integrados que se pueden usar para configurar el dispositivo, incluidos los dispositivos con fines específicos para redes, como enrutadores (incluidos muchos puntos de acceso Wi-Fi y módems DSL) y otros dispositivos como impresoras o UPS (unidades de fuente de alimentación ininterrumpida con respaldo de batería) que pueden tener conectividad de red.

Entonces, la pregunta, "¿Por qué las URL distinguen entre mayúsculas y minúsculas?", Es preguntar, "¿Por qué los servidores web tratan las URL como mayúsculas y minúsculas?" Y la respuesta real es: no todos hacen eso. Al menos un servidor web, que es bastante popular, generalmente NO distingue entre mayúsculas y minúsculas. (El servidor web es IIS).

Una razón clave para un comportamiento diferente entre diferentes servidores web probablemente se reduce a una cuestión de simplicidad. La manera simple de hacer un servidor web es hacer las cosas de la misma manera que la forma en que el sistema operativo de la computadora / dispositivo ubica los archivos. Muchas veces, los servidores web localizan un archivo para proporcionar una respuesta. Unix se diseñó alrededor de computadoras de gama alta, por lo que Unix proporcionó la funcionalidad deseable de permitir letras mayúsculas y minúsculas. Unix decidió tratar mayúsculas y minúsculas como diferentes porque, bueno, son diferentes. Esa es la cosa directa y natural que hacer. Windows tiene un historial de distinción entre mayúsculas y minúsculas debido a un deseo de admitir software ya creado, y este historial se remonta a DOS que simplemente no admitía letras minúsculas, posiblemente en un esfuerzo por simplificar las cosas con computadoras menos potentes que usan menos memoria. Dado que estos sistemas operativos son diferentes, el resultado es que los servidores web de diseño simple (versiones anteriores de) reflejan las mismas diferencias.

Ahora, con todo ese trasfondo, aquí hay algunas respuestas específicas a las preguntas específicas:

Cuando se diseñaron las URL por primera vez, ¿por qué se hizo distinción entre mayúsculas y minúsculas?

Por qué no? Si todos los servidores web estándar no distinguen entre mayúsculas y minúsculas, eso indicaría que los servidores web estaban siguiendo un conjunto de reglas especificadas por la norma. Simplemente no había una regla que diga que el caso debe ser ignorado. La razón por la que no hay una regla es simplemente que no había razón para que existiera dicha regla. ¿Por qué molestarse en inventar reglas innecesarias?

Pregunto esto porque me parece (es decir, un laico) que se preferiría la mayúsculas y minúsculas para evitar errores innecesarios y simplificar una cadena de texto ya complicada.

Las URL fueron diseñadas para que las máquinas las procesen. Aunque una persona puede escribir una URL completa en una barra de direcciones, esa no fue una parte importante del diseño previsto. El diseño previsto es que la gente seguiría ("haga clic en") hipervínculos. Si la gente promedio está haciendo eso, entonces realmente no les importa si la URL invisible es simple o complicada.

Además, ¿existe un propósito / ventaja real de tener una URL que distinga entre mayúsculas y minúsculas (a diferencia de la gran mayoría de las URL que apuntan a la misma página sin importar las mayúsculas)?

El quinto punto numerado de la respuesta de William Hay menciona una ventaja técnica: las URL pueden ser una forma efectiva para que un navegador web envíe un poco de información a un servidor web, y se puede incluir más información si hay menos restricciones, por lo que se distingue entre mayúsculas y minúsculas. la restricción reduciría la cantidad de información que se puede incluir.

Sin embargo, en muchos casos, no hay un beneficio súper convincente para la sensibilidad a mayúsculas y minúsculas, lo que se demuestra por el hecho de que IIS generalmente no se molesta con él.

En resumen, la razón más convincente es probablemente la simplicidad para quienes diseñaron el software del servidor web, particularmente en una plataforma sensible a mayúsculas y minúsculas como Unix. (HTTP no fue algo que influyó en el diseño original de Unix, ya que Unix es notablemente más antiguo que HTTP).

Las URL no distinguen entre mayúsculas y minúsculas, solo partes de ellas.
Por ejemplo, nada distingue entre mayúsculas y minúsculas en la URL https://google.com,

Con referencia a RFC 3986 - Identificador uniforme de recursos (URI): sintaxis genérica

Primero, desde Wikipedia , una URL se ve así:

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

(He eliminado la user:passwordparte porque no es interesante y rara vez se usa)

• scheme:

los esquemas no distinguen entre mayúsculas y minúsculas

• host:

El subcomponente del host no distingue entre mayúsculas y minúsculas.

• path:

El componente de ruta contiene datos ...

• query:

El componente de consulta contiene datos no jerárquicos ...

• fragment:

Los tipos de medios individuales pueden definir sus propias restricciones o estructuras dentro de la sintaxis del identificador de fragmento para especificar diferentes tipos de subconjuntos, vistas o referencias externas

Por lo tanto, schemey no hostdistinguen entre mayúsculas y minúsculas.
El resto de la URL distingue entre mayúsculas y minúsculas.

¿Por qué es pathsensible a mayúsculas y minúsculas?

Esta parece ser la pregunta principal.
Es difícil responder "por qué" se hizo algo si no estaba documentado, pero podemos adivinar muy bien.
He elegido citas muy específicas de la especificación, con énfasis en los datos .
Miremos la URL nuevamente:

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

• Ubicación: la ubicación tiene una forma canónica y no distingue entre mayúsculas y minúsculas. ¿Por qué? Probablemente para poder comprar un nombre de dominio sin tener que comprar miles de variantes.

• Datos: el servidor de destino utiliza los datos y la aplicación puede elegir lo que significa . No tendría ningún sentido hacer que los datos no distingan entre mayúsculas y minúsculas. La aplicación debería tener más opciones, y la definición de mayúsculas y minúsculas en la especificación limitará estas opciones.
  Esta es también una distinción útil para HTTPS: los datos están encriptados , pero el host está visible.

¿Es útil?

La distinción entre mayúsculas y minúsculas tiene sus dificultades cuando se trata de almacenamiento en caché y URL canónicas, pero sin duda es útil. Algunos ejemplos:

• Base64 , que se utiliza en URI de datos .
• Los sitios pueden codificar los datos de Base64 en la url, por ejemplo: http://tryroslyn.azurewebsites.net/#f:r/A4VwRgNglgxgBDCBDAziuBhOBvGB7AOxQBc4SAnKAgczLgF44AiAUQPwBMBTDuKuYgAsucAKoA4ADIBCvAAA4AD
• Los acortadores de URL utilizan mayúsculas y minúsculas: /a5Bpuede ser diferente de/a5b
• Como ha mencionado, Wikipedia puede diferenciar "SIDA" de "SIDA".

Sencillo. El sistema operativo distingue entre mayúsculas y minúsculas. A los servidores web generalmente no les importa a menos que tengan que acceder al sistema de archivos en algún momento. Aquí es donde Linux y otros sistemas operativos basados ​​en Unix hacen cumplir las reglas del sistema de archivos, en cuyo caso la sensibilidad es una parte importante. Es por eso que IIS nunca ha sido sensible a mayúsculas y minúsculas; porque Windows nunca fue sensible a mayúsculas y minúsculas.

[Actualizar]

Ha habido algunos argumentos contundentes en los comentarios (desde que se eliminaron) sobre si las URL tienen alguna relación con el sistema de archivos como he dicho. Estos argumentos se han calentado. Es extremadamente miope creer que no hay una relación. ¡Absolutamente lo hay! Déjame explicarte más.

Los programadores de aplicaciones generalmente no son programadores internos de sistemas. No estoy siendo insultante. Son dos disciplinas separadas y no se requiere conocimiento interno del sistema para escribir aplicaciones cuando las aplicaciones simplemente pueden hacer llamadas al sistema operativo. Dado que los programadores de aplicaciones no son programadores internos del sistema, no es posible omitir los servicios del sistema operativo. Digo esto porque estos son dos campos separados y rara vez se cruzan. Las aplicaciones se escriben para usar los servicios del sistema operativo como regla. Hay raras excepciones, por supuesto.

Cuando los servidores web comenzaron a aparecer, los desarrolladores de aplicaciones no intentaron eludir los servicios del sistema operativo. Hubieron varias razones para esto. Uno, no era necesario. Dos, los programadores de aplicaciones generalmente no sabían cómo evitar los servicios del sistema operativo. Tres, la mayoría de los sistemas operativos eran extremadamente estables y robustos, o extremadamente simples y livianos y no valían la pena el costo.

Tenga en cuenta que los primeros servidores web se ejecutaban en computadoras costosas, como los servidores DEC VAX / VMS y Unix del día (Berkeley y Ultrix, así como otros) en computadoras de marco principal o de marco medio, y luego poco después Computadoras livianas como PC y Windows 3.1. Cuando comenzaron a aparecer motores de búsqueda más modernos, como Google en 1997/8, Windows se mudó a Windows NT y otros sistemas operativos como Novell y Linux también comenzaron a ejecutar servidores web. Apache era el servidor web dominante, aunque había otros como IIS y O'Reilly que también eran muy populares. Ninguno de ellos en el momento pasó por alto los servicios del sistema operativo. Es probable que ninguno de los servidores web lo haga incluso hoy.

Los primeros servidores web eran bastante simples. Todavía lo son hoy. Cualquier solicitud realizada para un recurso a través de una solicitud HTTP que existe en un disco duro fue realizada por el servidor web a través del sistema de archivos del sistema operativo.

Los sistemas de archivos son mecanismos bastante simples. Cuando se realiza una solicitud de acceso a un archivo, si ese archivo existe, la solicitud se pasa al subsistema de autorización y, si se concede, la solicitud original se satisface. Si el recurso no existe o no está autorizado, el sistema genera una excepción. Cuando una aplicación realiza una solicitud, se establece un activador y la aplicación espera. Cuando se responde la solicitud, se lanza el desencadenador y la aplicación procesa la respuesta de la solicitud. Todavía funciona de esa manera hoy. Si la aplicación ve que la solicitud ha sido satisfecha, continúa, si ha fallado, la aplicación ejecuta una condición de error dentro de su código o muere si no se maneja. Sencillo.

En el caso de un servidor web, suponiendo que se realiza una solicitud de URL para una ruta / archivo, el servidor web toma la porción de ruta / archivo de la solicitud de URL (URI) y realiza una solicitud al sistema de archivos y está satisfecho o lanza una excepción. El servidor web luego procesa la respuesta. Si, por ejemplo, la ruta y el archivo solicitados se encuentran y el subsistema de autorización otorga el acceso, el servidor web procesa esa solicitud de E / S de manera normal. Si el sistema de archivos arroja una excepción, el servidor web devuelve un error 404 si el archivo no se encuentra o un 403 prohibido si el código de motivo no está autorizado.

Dado que algunos sistemas operativos distinguen entre mayúsculas y minúsculas y los sistemas de archivos de este tipo requieren coincidencias exactas, la ruta / archivo que se solicita al servidor web debe coincidir exactamente con lo que existe en el disco duro. La razón de esto es simple. Los servidores web no adivinan a qué te refieres. Ninguna computadora lo hace sin estar programado para hacerlo. Los servidores web simplemente procesan las solicitudes a medida que las reciben. Si la porción de ruta / archivo de la solicitud de URL que se pasa directamente al sistema de archivos no coincide con lo que está en el disco duro, entonces el sistema de archivos genera una excepción y el servidor web devuelve un error 404 No encontrado.

Es realmente esa gente simple. No es ciencia espacial. Existe una relación absoluta entre la porción de ruta / archivo de una URL y el sistema de archivos.

1. Las URL afirman ser un localizador de recursos UNIFORME y pueden apuntar a recursos que son anteriores a la web. Algunos de estos distinguen entre mayúsculas y minúsculas (por ejemplo, muchos servidores ftp) y las URL deben ser capaces de representar estos recursos de una manera razonablemente intuitiva.

2. La insensibilidad a mayúsculas y minúsculas requiere más trabajo cuando se busca una coincidencia (ya sea en el sistema operativo o por encima).

3. Si define URL como mayúsculas y minúsculas, los servidores individuales pueden implementarlas como mayúsculas y minúsculas si así lo desean. Lo opuesto no es verdad.

4. La insensibilidad a mayúsculas y minúsculas puede no ser trivial en contextos internacionales: https://en.wikipedia.org/wiki/Dotted_and_dotless_I . También RFC1738 permitió el uso de caracteres fuera del rango ASCII siempre que estuvieran codificados pero no especificaran un juego de caracteres. Esto es bastante importante para algo que se hace llamar la World Wide Web. La definición de URL como mayúsculas y minúsculas abriría mucho margen para errores.

5. Si está tratando de empacar muchos datos en un URI (por ejemplo, un URI de datos ) puede empacar más si las mayúsculas y minúsculas son distintas.

Robé del blog una Cosa nueva y vieja el hábito de abordar preguntas de la forma "¿por qué es que algo es así?" con la contrapregunta "¿cómo sería el mundo si no fuera el caso?"

Digamos que configuré un servidor web para servir mis archivos de documentos desde una carpeta para poder leerlos en el teléfono cuando estaba fuera de la oficina. Ahora, en mi carpeta de documentos, tengo tres archivos, todo.txt, ToDo.txty TODO.TXT(lo sé, pero tenía sentido para mí cuando hice los archivos).

¿Qué URL me gustaría poder usar para acceder a estos archivos? Me gustaría acceder a ellos de forma intuitiva, utilizando http://www.example.com/docs/filename.

Digamos que tengo un script que me permite agregar un contacto a mi libreta de direcciones, lo que también puedo hacer en la web. ¿Cómo debería eso tomar sus parámetros? Bueno, me gustaría usarlo como: http://www.example.com/addcontact.php?name=Tom McHenry von der O'Reilly. Pero si no hubiera forma de especificar el nombre por caso, ¿cómo lo haría?

¿Cómo diferenciaría las páginas wiki para Cat y CAT, Text y TEXT, latex y LaTeX? Disambig páginas, supongo, pero prefiero simplemente obtener lo que pedí.

Pero todo eso parece que está respondiendo la pregunta incorrecta, de todos modos.

La pregunta que creo que realmente estaba preguntando es "¿Por qué los servidores web 404 solo hacen una diferencia de caso, cuando son computadoras, diseñadas para simplificar la vida, y son perfectamente capaces de encontrar al menos las variaciones de casos más obvias en el ¿URL que escribí que funcionaría? "

La respuesta a esto es que, si bien algunos sitios han hecho esto (y mejor, también buscan otros errores tipográficos), nadie pensó que valiera la pena cambiar la página de error 404 predeterminada de un servidor web para hacer eso ... ¿pero tal vez deberían hacerlo?

Aunque la respuesta anterior es correcta y buena. Me gustaría agregar algunos puntos más.

Para comprender mejor, uno debe entender la diferencia básica entre el servidor Unix (Linux) Vs Windows. Unix distingue entre mayúsculas y minúsculas y Windows es un sistema operativo no sensible a mayúsculas y minúsculas

El protocolo HTTP se desarrolló o comenzó a implementarse alrededor de 1990. El protocolo HTTP fue diseñado por ingenieros que trabajan en los institutos CERN, la mayoría de esos días los científicos usaban máquinas Unix y no Windows.

La mayoría de los científicos estaban familiarizados con Unix, por lo que podrían haber sido influenciados con el sistema de archivos de estilo Unix.

El servidor de Windows se lanzó después de 2000. mucho antes de que el servidor de Windows se popularizara, el protocolo HTTP estaba bien madurado y la especificación estaba completa.

Esta podría ser la razón.

¿Cómo se debe leer un "por qué fue diseñado de esta manera?" ¿pregunta? ¿Está pidiendo una descripción históricamente precisa del proceso de toma de decisiones, o se pregunta "por qué alguien lo diseñaría de esta manera"?

Rara vez es posible obtener una cuenta históricamente precisa. A veces, cuando las decisiones se toman en los comités de normas, hay un rastro documental de cómo se llevó a cabo el debate, pero en los primeros días de la web, algunas personas tomaron decisiones apresuradamente, en este caso probablemente el propio TimBL, y la justificación es poco probable. haber sido escrito Pero TimBL ha admitido que cometió errores en el diseño de las URL: consulte http://www.dailymail.co.uk/sciencetech/article-1220286/Sir-Tim-Berners-Lee-admits-forward-slashes-web-address -mistake.html

En los primeros días, las URL se asignaban muy directamente a los nombres de archivo, y los archivos generalmente estaban en máquinas similares a Unix, y las máquinas similares a Unix tienen nombres de archivo sensibles a mayúsculas y minúsculas. Entonces, supongo que sucedió de esa manera por conveniencia de implementación, y la usabilidad (para usuarios finales) nunca fue considerada. De nuevo, en los primeros días los usuarios eran todos programadores de Unix de todos modos.

Esto no tiene nada que ver con el lugar donde compró su dominio, DNS no distingue entre mayúsculas y minúsculas. Pero, el sistema de archivos en el servidor que está utilizando para el alojamiento es.

Esto no es realmente un problema y es bastante común en los hosts * nix. Solo asegúrese de que todos los enlaces que escriba en sus páginas sean correctos y de que no tenga ningún problema. Para que sea más fácil, recomiendo nombrar siempre sus páginas en minúsculas y nunca necesitará verificar el nombre al escribir un enlace.

Closetnoc tiene razón sobre el sistema operativo. Algunos sistemas de archivos tratan el mismo nombre con una carcasa diferente como archivos diferentes.

Además, ¿existe un propósito / ventaja real de tener una URL que distinga entre mayúsculas y minúsculas (a diferencia de la gran mayoría de las URL que apuntan a la misma página sin importar las mayúsculas)?

Si. para evitar problemas de contenido duplicado.

Si tuviera, por ejemplo, las siguientes URL:

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

y todos señalaron exactamente la misma página con exactamente el mismo contenido, entonces tendrías contenido duplicado, y estoy seguro de que si tienes una cuenta de la consola de búsqueda de Google (herramientas para webmasters), Google te lo indicará.

Lo que sugeriría hacer si se encuentra en esa situación es usar todas las URL en minúsculas, luego redirigir las URL con al menos una letra mayúscula a la versión en minúsculas. Entonces, en la lista de URL anteriores, redirija todas las URL a la primera URL.

La sensibilidad a mayúsculas y minúsculas tiene valor.

Si hay 26 letras, cada una de ellas con la capacidad de mayúsculas, son 52 caracteres.

4 caracteres tienen la posibilidad de 52 * 52 * 52 * 52 combinaciones, lo que equivale a 7311616 combinaciones.

Si no puede poner en mayúscula los caracteres, la cantidad de combinaciones es 26 * 26 * 26 * 26 = 456976

Son más de 14 veces más combinaciones para 52 caracteres que 26. Por lo tanto, para almacenar datos, las URL pueden ser más cortas y se puede pasar más información a través de redes con menos datos transferidos.

Es por eso que ves YouTube usando URL como https://www.youtube.com/watch?v=xXxxXxxX