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

¿Por qué ¿La URL 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 han lanzado. Microsoft ha lanzado IIS con Windows Sistemas operativos de servidor (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 dispositivos con propósitos 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 suministro de energía 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: «¿Por qué los servidores web tratan la URL como siendo sensible a mayúsculas y minúsculas? » Y la respuesta real es: no todos hacen eso. Al menos un servidor web, que es bastante popular, normalmente NO distingue entre mayúsculas y minúsculas. (El servidor web es IIS).

Una razón clave para El comportamiento diferente entre diferentes servidores web probablemente se reduce a una cuestión de simplicidad. La forma más sencilla de crear 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 fue diseñado 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. Eso es lo sencillo y natural que se puede hacer. Windows tiene un historial de no distinguir entre mayúsculas y minúsculas debido al 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 para 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 (las primeras versiones de) reflejan las mismas diferencias.

Ahora, con todo eso En segundo plano, aquí hay algunas respuestas específicas a las preguntas específicas:

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?

¿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 el estándar. Simplemente no había regla que dice que el caso debe ser ignorado. La razón por la que no existe una regla es simplemente que no había ninguna razón para que haya tal regla. ¿Por qué molestarse en inventar reglas innecesarias?

aña Pregunto esto porque me parece (p. Ej., un profano) que preferiría no distinguir entre mayúsculas y minúsculas para evitar errores innecesarios y simplificar una cadena de texto ya complicada.

Las URL se diseñaron para que las máquinas las procesen . Aunque una persona puede escribir una URL completa en una barra de direcciones, esa no era una parte importante del diseño previsto. El diseño previsto es que la gente siga («haga clic en») los hipervínculos. Si la gente común y corriente está haciendo eso, entonces realmente no importa si la URL invisible es simple o complicada.

Además, ¿existe un propósito / ventaja real en tener una URL que distinga entre mayúsculas y minúsculas (como opuesto a la gran mayoría de 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 una restricción de distinción entre mayúsculas y minúsculas reduciría la cantidad de información que se puede incluir.

Sin embargo, en muchos casos, la distinción entre mayúsculas y minúsculas no ofrece un beneficio muy convincente, que es probado por el hecho de que IIS normalmente no se molesta con él.

En resumen, la razón más convincente es probablemente solo la simplicidad para aquellos que diseñaron el software del servidor web, particularmente en una plataforma que distingue entre 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.)

Comentarios

• » Una razón clave para el comportamiento diferente entre diferentes navegadores web probablemente se reduzca a una cuestión de simplicidad. «: supongo que significa » servidores web «, en lugar de » navegadores web » aquí y en un par de otros lugares?
• Actualizado. Revisó todos los casos de » navegadores » e hice varios reemplazos. Gracias por señalar esto para que se pueda mejorar algo de calidad.
• He recibido varias respuestas excelentes a mi pregunta, que van desde las históricas hasta las no sé si ir contra la corriente y aceptar una respuesta de menor calificación, pero la respuesta de @TOOGAM ‘ fue la más útil para me. Esta respuesta es exhaustiva y extensa, pero explica el concepto de una manera sencilla y conversacional que puedo entender. Y creo que esta respuesta es una buena introducción a las explicaciones más detalladas.
• La razón por la que Windows tiene un sistema de archivos que no distingue entre mayúsculas y minúsculas se debe a ‘ s Herencia de DOS. MS-DOS comenzó su vida en computadoras como la Tandy TRS-80, que usaba un televisor como pantalla y originalmente no admitía letras minúsculas debido a la falta de resolución. Dado que no podía ‘ t mostrar minúsculas, no era ‘ admitido. MS-DOS fue licenciado por IBM para convertirse en el PC-DOS original. Si bien la PC original podía mostrar minúsculas, el sistema de archivos se transfirió tal cual desde MS-DOS.

Las URL no distinguen entre mayúsculas y minúsculas, solo algunas 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 parece a:

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

(«He eliminado el user:password parte porque no es interesante y se usa con poca frecuencia)

• 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

Por tanto, scheme y host no distinguen entre mayúsculas y minúsculas.
El resto de la URL distingue entre mayúsculas y minúsculas.

¿Por qué path distingue entre mayúsculas y minúsculas?

Esta parece ser la pregunta principal.
Es difícil de 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 data .
Veamos nuevamente la URL:

 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 que pueda comprar un nombre de dominio sin tener que comprar miles de variantes.

• Datos: los datos son utilizados por el servidor de destino, y la aplicación puede elegir qué 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 definir la no distinción entre 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 es visible.

¿Es útil?

Case- la sensibilidad tiene sus dificultades cuando se trata de caché y URL canónicas, pero sin duda es útil. Algunos ejemplos:

• Base64 , que se utiliza en URI de datos .
• Los sitios pueden codificar datos Base64 en la URL, por ejemplo: http://tryroslyn.azurewebsites.net/#f:r/A4VwRgNglgxgBDCBDAziuBhOBvGB7AOxQBc4SAnKAgczLgF44AiAUQPwBMBTDuKuYgAsucAKoAlADIBCJgG4AvkA
• Los acortadores de URL utilizan mayúsculas y minúsculas: /a5B podría ser diferente de /a5b
• Como mencionaste, Wikipedia puede diferenciar «SIDA» de «SIDA».

Comentarios

• » Las URL no son cas e-sensible. » / » El resto de la URL distingue entre mayúsculas y minúsculas. » – ¿Esto parecería ser una contradicción?
• En verdad, el esquema define qué esperar en el resto de la URL. http: y los esquemas relacionados significan que la URL se refiere a un nombre de host DNS. DNS fue distinguido entre mayúsculas y minúsculas en ASCII mucho antes de la invención de las URL. Vea la página 55 de ietf.org/rfc/rfc883.txt
• ¡Muy bien detallado! Iba desde un punto de vista histórico. Originalmente, era la ruta del archivo que requería distinguir entre mayúsculas y minúsculas solo si estaba ingresando al sistema de archivos. De lo contrario, no fue así. Pero hoy las cosas han cambiado. Por ejemplo, los parámetros y CGI no existían originalmente. Tu respuesta toma una perspectiva del día actual. Tuve que recompensar tus esfuerzos !! ¡Realmente cavaste en este! ¿Quién sabía que esto explotaría de la forma en que lo hizo? ¡Salud!
• @ w3dk: es ‘ una peculiaridad no muy interesante de la terminología, pero podrías tomar » distingue entre mayúsculas y minúsculas » es decir, » cambiar las mayúsculas y minúsculas de un carácter puede cambiar el «, o podría interpretarlo como que » cambiar el caso de un carácter siempre cambia el «. Kobi parece estar afirmando lo último, prefiere que la distinción entre mayúsculas y minúsculas debería significar » cualquier cambio en caso de que sea significativo «, que por supuesto no es cierto para las URL. Prefieres lo primero. Es ‘ solo una cuestión de cuán sensibles son a las mayúsculas y minúsculas.
• @ rybo111: Si un usuario escribe example.com/fOObaR , la especificación requiere que el servidor en www.example.com reciba una ruta » / fOObaR » como se indica; no dice nada sobre la cuestión de si el servidor debe tratar eso de manera diferente a » / foOBaR «.

Simple. 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 sensibilidad es una parte importante. Es por eso que IIS nunca ha distinguido entre mayúsculas y minúsculas; porque Windows nunca distingue entre mayúsculas y minúsculas.

aña [Actualización] ajo 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 calentado. Es extremadamente miope creer que no existe una relación. ¡Hay absolutamente! Permítanme explicarles 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. Por supuesto, existen raras excepciones.

Cuando los servidores web comenzaron a aparecer, los desarrolladores de aplicaciones no intentaron eludir los servicios del SO. Hubieron varias razones para esto. Una, no era necesario. Dos, los programadores de aplicaciones generalmente no sabían cómo evitar los servicios del SO. 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 DEC VAX / Servidores 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 pasaba 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 de un recurso a través de una solicitud HTTP que exista en un disco duro la realizaba 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 para acceder a un archivo, si ese archivo existe, la solicitud se pasa al subsistema de autorización y, si se otorga, se satisface la solicitud original. Si el recurso no 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 activador 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 Si está satisfecho, 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. Simple.

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 está satisfecho o lanza una excepció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, entonces 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 requiere 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 que está en el disco duro, el sistema de archivos genera una excepción y el servidor web devuelve un error 404 No encontrado.

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

Comentarios

• Creo que su argumento es defectuoso. Aunque Berners-Lee no ‘ no tenía ninguna opción sobre la distinción entre mayúsculas y minúsculas de las URL de ftp. Llegó a diseñar URLs http. Podría haberlos especificado como US-ASCII solamente y no distingue entre mayúsculas y minúsculas. Si alguna vez hubo servidores web que simplemente pasaron la ruta de la URL al sistema de archivos, entonces no eran seguros y la introducción de la codificación de URL rompía la compatibilidad con ellos. Dado que la ruta se está procesando antes de entregar el caso de aplastamiento del sistema operativo, habría sido fácil de implementar. Por lo tanto, creo que debemos considerar esto como una decisión de diseño, no como una peculiaridad de implementación.
• @WilliamHay Esto no tiene nada que ver con Berners-Lee o el diseño de la web. Se trata de limitaciones y requisitos del sistema operativo. Soy un ingeniero de sistemas internos jubilado. Trabajé en estos sistemas en ese momento. Te estoy diciendo exactamente por qué las URLs distinguen entre mayúsculas y minúsculas. No es una conjetura. No es una opinión. Es un hecho. Mi respuesta se simplificó intencionalmente. Por supuesto, hay comprobaciones de archivos y otros procesos que se pueden realizar antes de emitir una declaración abierta. Y sí (!) Los servidores web siguen siendo parcialmente inseguros hasta el día de hoy como resultado.
• Si las URL distinguen entre mayúsculas y minúsculas no tiene nada que ver con el diseño de la web ¿En serio? Argumento de autoridad seguido de argumento por afirmación.El hecho de que los servidores web pasen el componente de ruta de una URL más o menos directamente a una llamada abierta es una consecuencia del diseño de las URL, no una causa. Los servidores (o clientes inteligentes en el caso de FTP) podrían haber ocultado al usuario la distinción entre mayúsculas y minúsculas de los sistemas de archivos. Que no ‘ t es una decisión de diseño.
• @WilliamHay Necesita reducir la velocidad de la tolva de césped y volver a leer lo que he escrito. Soy un ingeniero de sistemas internos retirado que escribe componentes de SO, pilas de protocolos y código de enrutador para ARPA-Net, etc. Trabajé con Apache, O ‘ Reilly y componentes internos de IIS. Su argumento FTP no se sostiene, ya que al menos los principales servidores FTP distinguen entre mayúsculas y minúsculas por la misma razón. En ningún momento dije nada sobre el diseño de URL / URI. En ningún momento dije que los servidores web pasaban valores sin procesarlos. Dije que los servicios de OS se usan comúnmente y que el sistema de archivos requiere una coincidencia exacta para tener éxito.
• @WilliamHay Por favor, comprenda que usted y yo estamos pensando en propósitos contradictorios. Todo lo que dije en mi respuesta es que para algunos sistemas operativos, las llamadas al sistema de archivos distinguen entre mayúsculas y minúsculas por diseño. Las aplicaciones que usan llamadas al sistema, y la mayoría lo hacen, se limitan a la aplicación de las reglas del sistema operativo, en este caso, la distinción entre mayúsculas y minúsculas. No es imposible eludir esta regla. De hecho, esto puede ser algo trivial en algunos casos, aunque no práctico. Solía omitir rutinariamente el sistema de archivos en mi trabajo para descifrar los discos duros que se estropeaban por una razón u otra o para analizar los archivos internos de la base de datos, etc.

1. Las URL afirman ser un localizador de recursos UNIFORME y pueden apuntar a recursos anteriores a la web. Algunos de estos 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 entre mayúsculas y minúsculas requiere más trabajo al buscar una coincidencia (ya sea en el sistema operativo o encima de él).

3. aña Si define las URL como sensibles a mayúsculas y minúsculas, los servidores individuales pueden implementarlas sin distinción entre mayúsculas y minúsculas si así lo desean. Lo contrario no es cierto.

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 . Además, 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 WORLD wide web. Definir URL que no distinguen entre mayúsculas y minúsculas abriría un amplio margen errores.

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

Comentarios

• I ‘ Estoy bastante seguro de que las URL se limitaban históricamente a ASCII. Por lo tanto, es poco probable que la internacionalización sea una razón original. La historia de Unix que distingue entre mayúsculas y minúsculas, OTOH, probablemente jugó un papel muy importante.
• Si bien solo un subconjunto de ASCII se puede usar sin codificar en una URL, RFC1738 establece específicamente que los caracteres fuera del rango ASCII se pueden usar codificados. Sin especificar un juego de caracteres, no es ‘ t posible saber qué octetos representan el mismo carácter acter excepto por el caso. Actualizado.
• Re # 4: Es ‘ en realidad peor que eso. I con puntos y sin puntos es una demostración del principio más general de que, incluso si todo es UTF-8 (o algún otro UTF), no se puede usar mayúsculas o minúsculas correctamente sin conocer la configuración regional a la que pertenece el texto . En la configuración regional predeterminada, una letra latina mayúscula I se convierte en minúscula a una letra latina minúscula i, lo cual es incorrecto en turco porque agrega un punto (no hay » mayúscula turca sin puntos I » punto de código; ‘ debe utilizar el punto de código ASCII). Agregue diferencias de codificación, y esto va de » realmente difícil » a » completamente intratable . »

Robé del blog una Old New Thing 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?»

Supongamos que configuré un servidor web para que me sirviera 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.txt y 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 manera intuitiva, usando http://www.example.com/docs/filename.

Digamos que tengo un script que me permite agregar un contacto a mi libreta de direcciones, que puedo también lo hago a través de la web.¿Cómo debería tomar eso 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? Supongo que desambigar páginas, pero prefiero obtener lo que pedí.

Pero todo eso se siente como si respondiera la pregunta equivocada, de todos modos.

La pregunta que creo que realmente estabas haciendo es «¿Por qué los servidores web te 404 solo por una diferencia de caso, cuando son computadoras, diseñadas para hacer la vida más simple y son perfectamente capaces de encontrar al menos las variaciones de mayúsculas y minúsculas más obvias en la URL que escribí que funcionarían «.

La respuesta es que, si bien algunos sitios lo han hecho (y mejor, compruebe también si hay 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?

Comentarios

• Algunos sitios utilizan algún tipo de mecanismo para convertir un cualquier consulta en minúsculas o algo consistente. En cierto modo, esto es inteligente.
• No, no deberían ‘ t. Esta funcionalidad se puede agregar, y a menudo se agrega cuando es deseable (por ejemplo, mediante módulos en apache). Imponer este tipo de cambio como comportamiento predeterminado, o peor, comportamiento inmutable, sería más perturbador que el relativamente raro ocasión en la que alguien tiene que escribir manualmente una URL más allá del nombre de host. Para ver un buen ejemplo de por qué no hacer esto, recuerde el fiasco cuando Network Solutions » solucionó » errores de dominio inexistentes del DNS público consultas.
• @SirNickity Nadie proponía inmutabilidad en ningún nivel y las páginas de error del servidor web se pueden configurar en todos los servidores web que ‘ he usado; nadie estaba sugiriendo reemplazar 404 con 30 * códigos, sino más bien agregar una lista de enlaces de sugerencias en los que se puede hacer clic por humanos a la página de error; los nombres de dominio son un tema y un problema muy diferente, ya que no distinguen entre mayúsculas y minúsculas y se encuentran en un contexto de seguridad diferente; e IIS ya automáticamente » corrige » (ignorando) las diferencias entre mayúsculas y minúsculas en las partes de ruta o nombre de archivo de los URI.
• Desde 1996, Apache le permite hacer esto con mod_speling . Simplemente no ‘ parece ser algo muy popular. La gente de Unix / Linux ve la insensibilidad a mayúsculas y minúsculas como la regla, la insensibilidad a mayúsculas y minúsculas como la excepción.

Aunque el la respuesta anterior es correcta & buena. Me gustaría añadir algunos puntos más.

aña Para entender mejor, se debe entender la diferencia básica entre el servidor Unix (Linux) Vs Windows. Unix distingue entre mayúsculas y minúsculas & Windows no distingue entre 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 trabajaban en En los institutos del 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 por el sistema de archivos estilo Unix.

aña El servidor de Windows fue lanzado después de 2000. mucho antes de que el servidor de Windows se hiciera popular, el protocolo HTTP estaba bien maduro y la especificación estaba completa. aña Esta podría ser la razón.

Comentarios

• » El servidor Windows se lanzó después del 2000. » El equipo de Windows NT 3.1 no estaría de acuerdo con usted en 1993. NT 3.51 en 1995 fue probablemente cuando NT comenzó a convertirse en lo suficientemente maduro y bien establecido para admitir aplicaciones de servidor críticas para el negocio.
• NT 3.51 tenía la interfaz Win 3.1. Windows no despegó realmente hasta Windows 95 y se necesitó NT 4.0 para obtener la misma interfaz.
• Michael Kj ö rling, estuvo de acuerdo. Déjeme modificarlo.
• @Thorbj ø rnRavnAndersen En el mercado de servidores, NT 3.51 tuvo un éxito razonable. En el mercado de consumidores / prosumidores, tomó hasta Windows 2000 (NT 5.0) antes de que la línea NT comenzara a ganar terreno.
• De hecho, WorldWideWeb se desarrolló inicialmente en sistemas basados en Unix, que distinguen entre mayúsculas y minúsculas sistemas de archivos, y la mayoría de las URL se asignan directamente a los archivos del sistema de archivos.

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

Rara vez es posible obtener un informe históricamente exacto cuenta.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, en este caso probablemente el propio TimBL, tomaban decisiones apresuradamente y la razón es poco probable. haber sido anotado. 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 estaban generalmente en máquinas similares a Unix, y las máquinas similares a Unix tienen nombres de archivo que distinguen entre mayúsculas y minúsculas. Entonces, supongo que sucedió de esa manera por conveniencia de implementación, y la usabilidad (para los usuarios finales) nunca se consideró. Nuevamente, en los primeros días los usuarios eran todos programadores de Unix de todos modos.

Comentarios

• Los usuarios finales también eran usuarios de Unix (no necesariamente programadores, pero físicos de alta energía y similares), por lo que también estaban acostumbrados a la insensibilidad a mayúsculas y minúsculas.

Este no tiene nada que ver con dónde 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 hosts * nix. Solo asegúrate de que todos los enlaces que escribas en tus páginas sean correctos y no tendrás ningún problema. Para hacerlo más fácil, te recomiendo que siempre nombre tus páginas en minúsculas, así nunca tendrás que volver a comprobar el nombre al escribir un enlace.

Closetnoc tiene razón sobre el sistema operativo. Algunos sistemas de archivos tratan el mismo nombre con diferentes mayúsculas y minúsculas como archivos diferentes.

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

Sí. 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 apuntaron a la misma página con el mismo contenido exacto, entonces tendrías contenido duplicado, y estoy seguro de que tienes una consola de búsqueda de Google (herramientas para webmasters), Google se lo indicará.

Lo que quiero Yo sugiero que si se encuentra en esa situación, utilice todas las URL en minúsculas y luego redirija las URL con al menos una letra mayúscula a la versión en minúscula. Entonces, en la lista de URL anterior, redirija todas las URL a la primera URL.

Comentarios

• » Sí. para evitar problemas de contenido duplicado. » – ¿Pero parece ser lo contrario? El hecho de que las URLs distingan mayúsculas y minúsculas (y así es como las tratan los motores de búsqueda) provoca los problemas de contenido duplicado que menciona. Si las URL fueran universalmente insensibles a mayúsculas y minúsculas, no habría problemas de contenido duplicado con mayúsculas y minúsculas diferentes. page-1 sería igual que PAGE-1.
• Creo que una configuración de servidor deficiente es lo que puede causar contenido duplicado cuando se trata de carcasa. Por ejemplo, la instrucción RewriteRule ^request-uri$ /targetscript.php [NC] almacenada en .htaccess coincidiría con http://example.com/request-uri y http://example.com/ReQuEsT-Uri porque el [NC] indica que el uso de mayúsculas y minúsculas no ‘ importa al evaluar esa expresión regular.

La distinción entre mayúsculas y minúsculas tiene valor.

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

4 caracteres tiene la posibilidad de 52 * 52 * 52 * 52 combinaciones, igual a 7311616 combinaciones.

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

Hay más de 14 veces más combinaciones para 52 caracteres que hay para 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 las redes con menos datos transferidos.

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