Perché gli URL fanno distinzione tra maiuscole e minuscole?

La mia domanda: quando gli URL sono stati progettati per la prima volta, perché la distinzione tra maiuscole e minuscole è diventata una funzionalità? Lo chiedo perché mi sembra (cioè un laico) che la distinzione tra maiuscole e minuscole sarebbe preferibile per prevenire errori inutili e semplificare una stringa di testo già complicata.

Inoltre, esiste un reale scopo / vantaggio nell'avere un URL con distinzione tra maiuscole e minuscole (al contrario della stragrande maggioranza degli URL che puntano alla stessa pagina, indipendentemente dalla capitalizzazione)?

Wikipedia, ad esempio, è un sito Web sensibile alle lettere maiuscole (ad eccezione del primo carattere):

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

Perché l'URL non dovrebbe distinguere tra maiuscole e minuscole?

Capisco che possa sembrare una domanda retorica provocatoria (e "avvocato del diavolo"), ma penso che sia utile considerare. Il design di HTTP è che un "client", che comunemente chiamiamo "browser web", richiede dati al "web server".

Esistono molti, molti server Web diversi che vengono rilasciati. Microsoft ha rilasciato IIS con i sistemi operativi Windows Server (e altri, incluso Windows XP Professional). Unix ha pesi massimi come nginx e Apache, per non parlare delle offerte più piccole come l'httpd interno di OpenBSD, o il httpd o lighttpd. Inoltre, molti dispositivi compatibili con la rete hanno server Web integrati che possono essere utilizzati per configurare il dispositivo, inclusi i dispositivi con scopi specifici delle reti, come router (inclusi molti punti di accesso Wi-Fi e modem DSL) e altri dispositivi come stampanti o UPS (gruppi di continuità alimentati a batteria) che possono avere connettività di rete.

Quindi la domanda "Perché gli URL fanno distinzione tra maiuscole e minuscole?", Chiede: "Perché i server Web considerano l'URL come sensibile al maiuscolo / minuscolo?" E la vera risposta è: non lo fanno tutti. Almeno un web server, che è abbastanza popolare, in genere NON è sensibile al maiuscolo / minuscolo. (Il web server è IIS.)

Un motivo chiave per comportamenti diversi tra server Web diversi si riduce probabilmente a una questione di semplicità. Il modo più semplice per creare un server Web è quello di fare le cose nello stesso modo in cui il sistema operativo del computer / dispositivo individua i file. Molte volte, i server Web individuano un file per fornire una risposta. Unix è stato progettato attorno a computer di fascia alta, e quindi Unix ha fornito la desiderabile funzionalità di consentire lettere maiuscole e minuscole. Unix ha deciso di trattare maiuscole e minuscole come diverse perché, beh, sono diverse. Questa è la cosa semplice e naturale da fare. Windows ha una storia senza distinzione tra maiuscole e minuscole a causa del desiderio di supportare software già creato, e questa storia risale al DOS che semplicemente non supportava lettere minuscole, forse nel tentativo di semplificare le cose con computer meno potenti che utilizzavano meno memoria. Poiché questi sistemi operativi sono diversi, il risultato è che i server Web (versioni precedenti di) progettati semplicemente riflettono le stesse differenze.

Ora, con tutto questo background, ecco alcune risposte specifiche alle domande specifiche:

Quando gli URL sono stati progettati per la prima volta, perché la distinzione tra maiuscole e minuscole è diventata una funzionalità?

Perchè no? Se tutti i server Web standard non facessero distinzione tra maiuscole e minuscole, ciò indicherebbe che i server Web stavano seguendo una serie di regole specificate dallo standard. Semplicemente non vi era alcuna regola che affermasse che il caso dovesse essere ignorato. Il motivo per cui non esiste una regola è semplicemente che non c'era motivo per una tale regola. Perché preoccuparsi di inventare regole inutili?

Lo chiedo perché mi sembra (cioè un laico) che la distinzione tra maiuscole e minuscole sarebbe preferibile per prevenire errori inutili e semplificare una stringa di testo già complicata.

Gli URL sono stati progettati per l'elaborazione da parte delle macchine. Sebbene una persona possa digitare un URL completo in una barra degli indirizzi, questa non era una parte importante del design previsto. Il progetto previsto è che le persone seguano ("clicca") i collegamenti ipertestuali. Se i laici medi lo stanno facendo, a loro non importa se l'URL invisibile sia semplice o complicato.

Inoltre, esiste un reale scopo / vantaggio nell'avere un URL con distinzione tra maiuscole e minuscole (al contrario della stragrande maggioranza degli URL che puntano alla stessa pagina, indipendentemente dalla capitalizzazione)?

Il quinto punto numerato della risposta di William Hay menziona un vantaggio tecnico: gli URL possono essere un modo efficace per un browser Web di inviare un po 'di informazioni a un server Web, e possono essere incluse più informazioni se ci sono meno restrizioni, quindi una distinzione tra maiuscole e minuscole la restrizione ridurrebbe quante informazioni possono essere incluse.

Tuttavia, in molti casi, non esiste un vantaggio super convincente per la sensibilità del caso, il che è dimostrato dal fatto che IIS in genere non si preoccupa di esso.

In sintesi, il motivo più convincente è probabilmente la semplicità per coloro che hanno progettato il software del server Web, in particolare su una piattaforma con distinzione tra maiuscole e minuscole come Unix. (HTTP non è stato qualcosa che ha influenzato il design originale di Unix, poiché Unix è notevolmente più vecchio di HTTP.)

Gli URL non fanno distinzione tra maiuscole e minuscole, ma solo in parte.
Ad esempio, nulla fa distinzione tra maiuscole e minuscole nell'URL https://google.com,

Con riferimento a RFC 3986 - Uniform Resource Identifier (URI): sintassi generica

Innanzitutto, da Wikipedia , un URL appare come:

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

(Ho rimosso la user:passwordparte perché non è interessante e raramente utilizzata)

• scheme:

gli schemi non fanno distinzione tra maiuscole e minuscole

• host:

Il sottocomponente host non distingue tra maiuscole e minuscole.

• path:

Il componente percorso contiene dati ...

• query:

Il componente di query contiene dati non gerarchici ...

• fragment:

I singoli tipi di media possono definire le proprie restrizioni o strutture all'interno della sintassi dell'identificatore di frammento per specificare diversi tipi di sottoinsiemi, viste o riferimenti esterni

Quindi, schemee non hostfanno distinzione tra maiuscole e minuscole.
Il resto dell'URL fa distinzione tra maiuscole e minuscole.

Perché la pathdistinzione tra maiuscole e minuscole?

Questa sembra essere la domanda principale.
È difficile rispondere "perché" qualcosa è stato fatto se non è stato documentato, ma possiamo fare un'ottima ipotesi.
Ho preso citazioni molto specifiche dalle specifiche, con enfasi sui dati .
Diamo un'occhiata all'URL di nuovo:

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

• Posizione: la posizione ha una forma canonica ed è sensibile al maiuscolo / minuscolo. Perché? Probabilmente in modo da poter acquistare un nome di dominio senza dover acquistare migliaia di varianti.

• Dati: i dati vengono utilizzati dal server di destinazione e l'applicazione può scegliere il significato . Non avrebbe alcun senso rendere insensibili i casi di dati. L'applicazione dovrebbe avere più opzioni e la definizione di insensibilità al maiuscolo / minuscolo nelle specifiche limiterà queste opzioni.
  Questa è anche una distinzione utile per HTTPS: i dati sono crittografati , ma l'host è visibile.

È utile?

La distinzione tra maiuscole e minuscole ha le sue insidie ​​quando si tratta di memorizzazione nella cache e URL canonici, ma è sicuramente utile. Qualche esempio:

• Base64 , utilizzato negli URI dei dati .
• I siti possono codificare i dati Base64 nell'URL, ad esempio: http://tryroslyn.azurewebsite.net/#f:r/A4VwRgNglgxgBDCBDAziuBhOBvGB7AOxQBc4SAnKAgczLgF44AiAUQPwBMBTDuKuYgAsGGAD
• Gli accorciatori di URL utilizzano la distinzione tra maiuscole e minuscole: /a5Bpotrebbero essere diversi da/a5b
• Come hai già detto, Wikipedia può differenziare "AIDS" da "AIDS".

Semplice. Il sistema operativo è sensibile al maiuscolo / minuscolo. In genere i server Web non si preoccupano a meno che non debbano colpire il file system a un certo punto. È qui che Linux e altri sistemi operativi basati su Unix applicano le regole del file system, nel qual caso la sensibilità è una parte importante. Questo è il motivo per cui IIS non è mai stato sensibile al maiuscolo / minuscolo; perché Windows non ha mai distinto tra maiuscole e minuscole.

[Aggiornare]

Ci sono stati alcuni argomenti forti nei commenti (da quando sono stati eliminati) sul fatto che gli URL abbiano qualche relazione con il file system, come ho affermato. Questi argomenti sono diventati accesi. È estremamente miope credere che non ci sia una relazione. C'è assolutamente! Lasciami spiegare ulteriormente.

I programmatori di applicazioni non sono generalmente programmatori interni di sistemi. Non sto insultando. Sono due discipline separate e non è richiesta la conoscenza interna del sistema per scrivere applicazioni quando le applicazioni possono semplicemente effettuare chiamate al sistema operativo. Poiché i programmatori di applicazioni non sono programmatori interni ai sistemi, non è possibile bypassare i servizi del sistema operativo. Lo dico perché si tratta di due campi separati e raramente si incrociano. Le applicazioni sono scritte per utilizzare i servizi OS come regola. Ci sono alcune rare eccezioni ovviamente.

Quando i server web iniziarono ad apparire, gli sviluppatori di applicazioni non tentarono di bypassare i servizi del sistema operativo. Ci sono state diverse ragioni per questo. Uno, non era necessario. Due, i programmatori di applicazioni generalmente non sapevano come bypassare i servizi del sistema operativo. Tre, la maggior parte dei sistemi operativi era estremamente stabile e robusta, oppure estremamente semplice e leggera e non valeva il costo.

Tieni presente che i primi server Web funzionavano su computer costosi come i server DEC VAX / VMS e Unix del giorno (Berkeley e Ultrix e altri) su computer con frame principale o medio, quindi subito dopo computer leggeri come PC e Windows 3.1. Quando iniziarono ad apparire motori di ricerca più moderni, come Google nel 1997/8, Windows si era spostato su Windows NT e anche altri sistemi operativi come Novell e Linux avevano iniziato a eseguire server Web. Apache era il web server dominante sebbene ce ne fossero altri come IIS e O'Reilly che erano anche molto popolari. Nessuno di questi al momento ignorava i servizi del sistema operativo. È probabile che nessuno dei server web lo faccia nemmeno oggi.

I primi web server erano abbastanza semplici. Lo sono ancora oggi. Qualsiasi richiesta fatta per una risorsa tramite una richiesta HTTP esistente su un disco rigido è stata / è effettuata dal server Web tramite il file system del sistema operativo.

I file system sono meccanismi piuttosto semplici. Quando viene effettuata una richiesta di accesso a un file, se tale file esiste, la richiesta viene passata al sottosistema di autorizzazione e, se concessa, la richiesta originale viene soddisfatta. Se la risorsa non esiste o non è autorizzata, viene generata un'eccezione dal sistema. Quando un'applicazione effettua una richiesta, viene impostato un trigger e l'applicazione attende. Quando si risponde alla richiesta, viene attivato il trigger e l'applicazione elabora la risposta della richiesta. Funziona ancora così oggi. Se l'applicazione rileva che la richiesta è stata soddisfatta, continua, se non è riuscita, l'applicazione esegue una condizione di errore nel suo codice o muore se non gestita. Semplice.

Nel caso di un server Web, supponendo che venga effettuata una richiesta URL per un percorso / file, il server Web accetta la parte percorso / file della richiesta URL (URI) e fa una richiesta al file system ed è soddisfatto o genera un'eccezione. Il server Web quindi elabora la risposta. Se, ad esempio, il percorso e il file richiesti vengono rilevati e l'accesso concesso dal sottosistema di autorizzazione, il server Web elabora normalmente la richiesta di I / O. Se il file system genera un'eccezione, il server Web restituisce un errore 404 se il file non è stato trovato o un 403 proibito se il codice motivo non è autorizzato.

Poiché alcuni sistemi operativi fanno distinzione tra maiuscole e minuscole e i file system di questo tipo richiedono corrispondenze esatte, il percorso / file richiesto al server Web deve corrispondere esattamente a ciò che esiste sul disco rigido. Il motivo è semplice. I server Web non indovinano cosa intendi. Nessun computer lo fa senza essere programmato. I server Web elaborano semplicemente le richieste quando le ricevono. Se la parte percorso / file della richiesta URL che viene passata direttamente al file system non corrisponde a ciò che si trova sul disco rigido, il file system genera un'eccezione e il server Web restituisce un errore 404 Not Found.

È davvero gente così semplice. Non è scienza missilistica. Esiste una relazione assoluta tra la parte percorso / file di un URL e il file system.

1. Gli URL dichiarano di essere un localizzatore di risorse UNIFORM e possono puntare a risorse precedenti al Web. Alcuni di questi sono case sensitive (ad esempio molti server ftp) e gli URL devono essere in grado di rappresentare queste risorse in modo ragionevolmente intuitivo.

2. L'insensibilità alle maiuscole richiede più lavoro quando si cerca una corrispondenza (nel sistema operativo o sopra di essa).

3. Se si definiscono gli URL come singoli server con distinzione tra maiuscole e minuscole, è possibile implementarli come insensibili alle maiuscole. Il contrario non è vero.

4. L'insensibilità ai casi può essere non banale in contesti internazionali: https://en.wikipedia.org/wiki/Dotted_and_dotless_I . Inoltre RFC1738 consentiva l'uso di caratteri al di fuori dell'intervallo ASCII purché fossero codificati ma non specificasse un set di caratteri. Questo è abbastanza importante per qualcosa che si autodefinisce WORLD wide web. Definire gli URL come maiuscole e minuscole aprirebbe molto spazio ai bug.

5. Se si sta tentando di raggruppare molti dati in un URI (ad es. Un URI dati ), è possibile comprimere di più se le lettere maiuscole e minuscole sono distinte.

Ho rubato dal blog una Vecchia Cosa Nuova l'abitudine di affrontare le domande del modulo "perché succede che qualcosa sia così?" con la contro-domanda "come sarebbe il mondo, se non fosse così?"

Supponiamo di aver impostato un server Web per servire da solo i miei file di documenti da una cartella in modo da poterli leggere al telefono quando ero in ufficio. Ora, nella mia cartella documenti, ho tre file, todo.txt, ToDo.txte TODO.TXT(lo so, ma aveva senso per me quando ho fatto i file).

Quale URL mi piacerebbe poter utilizzare per accedere a questi file? Vorrei accedervi in ​​modo intuitivo, utilizzando http://www.example.com/docs/filename.

Supponi di avere uno script che mi consente di aggiungere un contatto alla mia rubrica, cosa che posso fare anche sul Web. Come dovrebbe prendere i suoi parametri? Beh, mi piacerebbe utilizzarlo come: http://www.example.com/addcontact.php?name=Tom McHenry von der O'Reilly. Ma se non avessi modo di specificare il nome per caso, come lo farei?

Come differenzerei le pagine wiki per Cat e CAT, Text e TEXT, latex e LaTeX? Disambig pagine, immagino, ma preferisco solo ottenere la cosa che ho chiesto.

Ma tutto ciò che sembra rispondere a una domanda sbagliata, comunque.

La domanda che penso davvero ti stia ponendo è "Perché i server web ti fanno solo una differenza, quando sono computer, progettati per semplificare la vita e sono perfettamente in grado di trovare almeno le più ovvie variazioni del caso nel URL che ho digitato che funzionerebbe? "

La risposta a ciò è che mentre alcuni siti hanno fatto questo (e meglio, controllano anche altri errori di battitura), nessuno ha pensato che valesse la pena cambiare la pagina di errore 404 predefinita di un server web per farlo ... ma forse dovrebbero?

Sebbene la risposta sopra sia corretta e buona. Vorrei aggiungere altri punti.

Per capire meglio, si dovrebbe capire la differenza di base tra Unix (Linux) e il server Windows. Unix fa distinzione tra maiuscole e minuscole e Windows non è sensibile al maiuscolo / minuscolo.

Il protocollo HTTP è stato evoluto o ha iniziato a essere implementato intorno al 1990. Il protocollo HTTP è stato progettato da ingegneri che lavorano negli istituti del CERN, la maggior parte di quei giorni gli scienziati hanno usato macchine Unix e non Windows.

La maggior parte degli scienziati aveva familiarità con Unix, quindi avrebbero potuto essere influenzati dal file system in stile Unix.

Il server Windows è stato rilasciato dopo il 2000. molto prima che il server Windows diventasse popolare, il protocollo HTTP era ben maturo e le specifiche erano complete.

Questo potrebbe essere il motivo.

Come si dovrebbe leggere un "perché è stato progettato in questo modo?" domanda? Stai chiedendo un resoconto storicamente accurato del processo decisionale o stai chiedendo "perché qualcuno dovrebbe progettarlo in questo modo?"?

Molto raramente è possibile ottenere un account storicamente accurato. A volte, quando le decisioni vengono prese nei comitati standard, c'è una traccia documentale su come il dibattito è stato condotto, ma nei primi giorni del web le decisioni sono state prese in fretta da alcuni individui - in questo caso probabilmente dallo stesso TimBL - e la logica è improbabile essere stato scritto. Ma TimBL ha ammesso di aver commesso errori nella progettazione di URL - vedi http://www.dailymail.co.uk/sciencetech/article-1220286/Sir-Tim-Berners-Lee-admits-forward-slashes-web-address -mistake.html

All'inizio gli URL erano mappati direttamente ai nomi dei file e i file erano generalmente su macchine simili a Unix e le macchine simili a Unix hanno nomi di file sensibili al maiuscolo / minuscolo. Quindi la mia ipotesi è che sia successo in quel modo per comodità di implementazione e l'usabilità (per gli utenti finali) non è mai stata nemmeno presa in considerazione. Ancora una volta, nei primi tempi gli utenti erano comunque tutti programmatori Unix.

Questo non ha nulla a che fare con il luogo in cui hai acquistato il dominio, il DNS non fa distinzione tra maiuscole e minuscole. Ma il file system sul server che si sta utilizzando per l'hosting è.

Questo non è davvero un problema ed è abbastanza comune sugli host * nix. Assicurati solo che tutti i link che scrivi sulle tue pagine siano corretti e non avrai problemi. Per semplificare, ti consiglio di dare sempre un nome alle tue pagine in minuscolo, quindi non devi mai ricontrollare il nome quando scrivi un link.

Closetnoc ha ragione sul sistema operativo. Alcuni file system considerano lo stesso nome con un involucro diverso come file diversi.

Inoltre, esiste un reale scopo / vantaggio nell'avere un URL con distinzione tra maiuscole e minuscole (al contrario della stragrande maggioranza degli URL che puntano alla stessa pagina, indipendentemente dalla capitalizzazione)?

Sì. per evitare duplicati dei contenuti.

Se avessi ad esempio i seguenti 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

e tutti hanno indicato la stessa identica pagina con lo stesso identico contenuto, quindi avresti contenuti duplicati e sono sicuro che se hai un account della console di ricerca di Google (strumenti per i webmaster), Google te lo indicherà.

Quello che suggerirei di fare se ti trovi in ​​quella situazione è usare tutti gli URL minuscoli, quindi reindirizzare gli URL con almeno una lettera maiuscola nella versione minuscola. Quindi nell'elenco degli URL sopra, reindirizza tutti gli URL al primo URL.

La distinzione tra maiuscole e minuscole ha valore.

Se ci sono 26 lettere, ognuna con la possibilità di scrivere in maiuscolo, sono 52 caratteri.

4 caratteri ha la possibilità di 52 * 52 * 52 * 52 combinazioni, equivalenti a 7311616 combinazioni.

Se non riesci a mettere in maiuscolo i caratteri, la quantità di combinazioni è 26 * 26 * 26 * 26 = 456976

Esistono oltre 14 volte più combinazioni per 52 caratteri rispetto a 26. Pertanto, per l'archiviazione dei dati, gli URL possono essere più brevi e più informazioni possono essere trasferite su reti con meno dati trasferiti.

Ecco perché vedi YouTube che utilizza URL come https://www.youtube.com/watch?v=xXxxXxxX