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

Solución:

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, de Wikipedia, una URL se ve así:

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

(He eliminado el user:password parte porque no es interesante y rara vez se usa)

• scheme:

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

• host:

El subcomponente de 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 fragmentos para especificar diferentes tipos de subconjuntos, vistas o referencias externas.

Entonces el scheme y host no distinguen entre mayúsculas y minúsculas.
El resto de la URL distingue entre mayúsculas y minúsculas.

Porque es el path ¿distingue mayúsculas y minúsculas?

Ésta parece ser la cuestión principal.
Es dificil de contestar “por qué” se hizo algo si no estaba documentado, pero podemos adivinar muy bien.
Elegí citas muy específicas de la especificación, con énfasis en datos.
Veamos 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: los datos son utilizado por el servidor de destino, 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 también es 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 usa en URI de datos.
• Los sitios pueden codificar datos Base64 en la url, por ejemplo: http://tryroslyn.azurewebsites.net/#f:r/A4VwRgNglgxgBDCBDAziuBhOBvGB7AOxQBc4SAnKAgczLgF44AiAUQPwBMBTDuKuYgAsucKAgAlADA
• Los acortadores de URL utilizan la distinción entre mayúsculas y minúsculas: /a5B podría ser diferente a /a5b
• Como ha mencionado, Wikipedia puede diferenciar “SIDA” de “SIDA”.

Sencillo. El sistema operativo distingue entre mayúsculas y minúsculas. Por lo general, a los servidores web no les importa a menos que tengan que atacar el 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 distinción entre mayúsculas y minúsculas es una parte importante. Ésta es la razón por la que IIS nunca ha distinguido entre mayúsculas y minúsculas; porque Windows nunca distingue entre mayúsculas y minúsculas.

[Update]

Ha habido algunos argumentos sólidos 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 vuelto acalorados. Es extremadamente miope creer que no existe una relación. ¡Absolutamente lo hay! Déjame explicarte más.

Los programadores de aplicaciones no son generalmente programadores internos de sistemas. No estoy insultando. Son dos disciplinas separadas y no se requieren conocimientos internos del sistema para escribir aplicaciones cuando las aplicaciones pueden simplemente realizar llamadas al sistema operativo. Dado que los programadores de aplicaciones no son programadores internos de sistemas, no es posible omitir los servicios del SO. Digo esto porque estos son dos campos separados y rara vez cruzan. Las aplicaciones están escritas para utilizar los servicios del sistema operativo como regla. Hay raras excepciones, por supuesto.

Cuando comenzaron a aparecer los servidores web, 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 eludir 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 caras como los servidores DEC VAX / VMS y el Unix del día (Berkeley y Ultrix, así como otros) en computadoras de marco principal o medio, y poco después en 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 había trasladado a Windows NT y otros sistemas operativos como Novell y Linux también habían comenzado 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 ese 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 SO.

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, se satisface la solicitud original. Si el recurso no existe o no está autorizado, el sistema lanza una excepción. Cuando una aplicación realiza una solicitud, se establece un activador y la aplicación espera. Cuando se responde a la solicitud, se activa el disparador y la aplicación procesa la respuesta a 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, asumiendo que se realiza una solicitud de URL para una ruta / archivo, el servidor web toma la parte de ruta / archivo de la solicitud de URL (URI) y realiza una solicitud al sistema de archivos y se satisface o lanza una excepción. A continuación, el servidor web procesa la respuesta. Si, por ejemplo, la ruta y el archivo solicitados se encuentran y el acceso otorgado por el subsistema de autorización, entonces el servidor web procesa esa solicitud de E / S con normalidad. Si el sistema de archivos genera 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 programada para ello. Los servidores web simplemente procesan las solicitudes a medida que las reciben. Si la parte de la ruta / archivo de la solicitud de URL que se pasa directamente al sistema de archivos no coincide con la del disco duro, el sistema de archivos genera una excepción y el servidor web devuelve un error 404 No encontrado.

Es realmente así de gente sencilla. No es ciencia espacial. Existe una relación absoluta entre la parte 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 ellos distinguen entre mayúsculas y minúsculas (por ejemplo, muchos servidores ftp) y las URL deben poder representar estos recursos de una manera razonablemente intuitiva.

2. La insensibilidad a mayúsculas y minúsculas requiere más trabajo al buscar una coincidencia (ya sea en el sistema operativo o por encima de él).

3. Si define las URL como que distinguen entre mayúsculas y minúsculas, los servidores individuales pueden implementarlas como no distinguen entre 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 permitía 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 llama a sí mismo la red mundial. Definir las URL como que no distinguen entre mayúsculas y minúsculas abriría un gran margen para errores.

5. Si está intentando empaquetar una gran cantidad de datos en un URI (por ejemplo, un URI de datos), puede empaquetar más si las mayúsculas y minúsculas son distintas.

---

---

Utiliza Nuestro Buscador