Perché gli URL fanno distinzione tra maiuscole e minuscole?

Perché “t lURL fa distinzione tra maiuscole e minuscole?

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

Ci sono molti, molti server web diversi che vengono rilasciati. Microsoft ha rilasciato IIS con Windows Sistemi operativi server (e altri, incluso Windows XP Professional) Unix ha pesi massimi come nginx e Apache, per non parlare di offerte più piccole come httpd interno di OpenBSD, o thttpd o lighttpd. Inoltre, molti dispositivi con funzionalità di rete hanno server Web incorporati che possono essere utilizzati per configurare il dispositivo, inclusi dispositivi con scopi specifici per le reti, come router (inclusi molti punti di accesso Wi-Fi e modem DSL) e altri dispositivi come stampanti o UPS (unità di alimentazione senza interruzioni supportate da batteria) che possono avere connettività di rete.

Quindi la domanda, “Perché gli URL fanno distinzione tra maiuscole e minuscole?”, È: “Perché i server web trattano lURL come essere case sensitive? ” E la risposta effettiva è: non tutti lo fanno. Almeno un server web, che è abbastanza popolare, in genere NON fa distinzione tra maiuscole e minuscole. (Il server web è IIS.)

Un motivo chiave per il diverso comportamento tra i diversi server web probabilmente si riduce a una questione di semplicità: il modo più semplice per creare un server web è 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 intorno ai computer di fascia più alta, e quindi Unix ha fornito la funzionalità desiderabile di consentire lettere maiuscole e minuscole. Unix ha deciso di trattare le maiuscole e le minuscole come diverse perché, beh, sono diverse. Questa è la cosa più semplice e naturale da fare. Windows ha una storia in cui non fa distinzione tra maiuscole e minuscole a causa del desiderio di supportare software già creato, e questa storia risale al DOS che semplicemente non supportava le lettere minuscole, forse in uno sforzo per semplificare le cose con computer meno potenti che utilizzavano meno memoria. Poiché questi sistemi operativi sono diversi, il risultato è che i server web dal design semplice (le prime versioni di) riflettono le stesse differenze.

Ora, con tutto ciò sfondo, ecco alcune risposte specifiche alle domande specifiche:

Quando gli URL sono stati progettati per la prima volta, perché è stata fatta distinzione tra maiuscole e minuscole?

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 cera regola che dice che il caso deve essere ignorato.Il motivo per cui non esiste una regola è semplicemente che non ce nera motivo ci deve essere una tale regola. Perché preoccuparsi di inventare regole non necessarie?

Lo chiedo perché mi sembra (ad es., un laico) che sarebbe preferibile la mancanza di distinzione tra maiuscole e minuscole per evitare errori inutili e semplificare una stringa di testo già complicata.

Gli URL sono stati progettati per le macchine . Sebbene una persona possa digitare un URL completo in una barra degli indirizzi, questa non era “una parte importante del progetto previsto. Il progetto previsto è che le persone seguissero (” clicchi “) i collegamenti ipertestuali. Se la gente comune lo fa, allora davvero non importa se lURL invisibile è semplice o complicato.

Inoltre, cè un vero scopo / vantaggio nellavere un URL che fa distinzione tra maiuscole e minuscole (come opposto alla stragrande maggioranza degli URL che puntano alla stessa pagina indipendentemente dalle maiuscole)?

Il quinto punto numerato di La 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 più informazioni possono essere incluse se ce ne sono meno , quindi una limitazione della distinzione tra maiuscole e minuscole ridurrebbe la quantità di informazioni che possono essere incluse.

Tuttavia, in molti casi, non cè “un vantaggio super convincente per la distinzione tra maiuscole e minuscole dimostrato dal fatto che IIS in genere non se ne preoccupa.

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

Commenti

• ” Una delle ragioni principali del diverso comportamento tra i diversi browser web probabilmente si riduce a una questione di semplicità. ” – Presumo che tu significa ” server web “, piuttosto che ” browser web ” qui e in un paio di altri posti?
• Aggiornato. Ha esaminato tutti i casi di ” browser ” e ha apportato più sostituzioni. Grazie per averlo segnalato in modo da migliorare un po di qualità.
• Ho ricevuto diverse risposte eccellenti alla mia domanda, da quelle storiche a tecnico. Esito ad andare controcorrente e ad accettare una risposta con un punteggio inferiore, ma la risposta di @TOOGAM ‘ è stata la più utile per me. Questa risposta è esauriente ed ampia, ma spiega il concetto in un modo semplice e colloquiale che posso capire. E penso che questa risposta sia una buona introduzione alle spiegazioni più approfondite.
• Il motivo per cui Windows ha un filesystem senza distinzione tra maiuscole e minuscole è dovuto ad esso ‘ s Patrimonio DOS. MS-DOS è nato su computer come il Tandy TRS-80, che utilizzava un televisore come display e originariamente non supportava le lettere minuscole a causa della mancanza di risoluzione. Dato che ‘ non visualizzava le minuscole, le lettere miste non erano ‘ supportate. MS-DOS è stato concesso in licenza da IBM per diventare il PC-DOS originale. Sebbene il PC originale potesse visualizzare le minuscole, il filesystem è stato trasferito così comè da MS-DOS.

Gli URL non fanno distinzione tra maiuscole e minuscole, solo alcune parti di essi.
Ad esempio, nulla distingue tra maiuscole e minuscole nellURL https://google.com,

Con riferimento a RFC 3986 – Uniform Resource Identifier (URI): Generic Syntax

Innanzitutto, da Wikipedia , un URL ha il seguente aspetto:

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

(Ho “rimosso il user:password parte perché non è interessante e usato raramente)

• scheme :

gli schemi non fanno distinzione tra maiuscole e minuscole

• host :

Il sottocomponente host non fa distinzione tra maiuscole e minuscole.

• path :

Il componente percorso contiene dati …

• query :

Il componente query contiene dati non gerarchici …

• fragment :

I singoli tipi di media possono definire le proprie restrizioni o strutture allinterno della sintassi dellidentificatore di frammento per specificare diversi tipi di sottoinsiemi, viste o riferimenti esterni

Quindi, scheme e host non fa distinzione tra maiuscole e minuscole.
Il resto di lURL fa distinzione tra maiuscole e minuscole.

Perché path fa distinzione tra maiuscole e minuscole?

Questa sembra essere la domanda principale.
È difficile rispondere “perché” qualcosa è stato fatto se non è stato documentato, ma possiamo fare unottima ipotesi.
Ho “scelto citazioni molto specifiche dalle specifiche, con enfasi su data .
Esaminiamo di nuovo lURL:

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

• Posizione: la posizione ha una forma canonica e non fa distinzione tra maiuscole e minuscole. Perché? Probabilmente così potresti acquistare un nome di dominio senza dover acquistare migliaia di varianti.

• Dati: i dati sono utilizzati dal server di destinazione e lapplicazione può scegliere cosa significa . Non avrebbe alcun senso rendere i dati senza distinzione tra maiuscole e minuscole. Lapplicazione dovrebbe avere più opzioni e la definizione di insensibilità tra maiuscole e minuscole nelle specifiche limiterà queste opzioni.
  Questa è anche una distinzione utile per HTTPS: i dati sono crittografati , ma lhost è visibile.

È utile?

Caso- la sensibilità ha le sue insidie quando si tratta di cache e URL canonici, ma è certamente utile. Alcuni esempi:

• Base64 , che viene utilizzato negli URI di dati .
• I siti possono codificare i dati Base64 nellURL, ad esempio: http://tryroslyn.azurewebsites.net/#f:r/A4VwRgNglgxgBDCBDAziuBhOBvGB7AOxQBc4SAnKAgczLgF44AiAUQPwBMBTDuKuYgAsucAKoAlADIBCJgG4AvkA
• Gli accorciatori di URL utilizzano la distinzione tra maiuscole e minuscole: /a5B potrebbe essere diverso da /a5b
• Come hai già detto, Wikipedia può differenziare “AIDS” da “Aids”.

Commenti

• ” URL non sono cas e-sensitive. ” / ” Il resto dellURL fa distinzione tra maiuscole e minuscole. ” – Sembrerebbe una contraddizione?
• In verità, lo schema definisce cosa aspettarsi nel resto dellURL. http: e gli schemi correlati indicano che lURL fa riferimento a un nome host DNS. Il DNS non faceva distinzione tra maiuscole e minuscole ASCII molto prima dellinvenzione degli URL. Vedi pagina 55 di ietf.org/rfc/rfc883.txt
• Ben dettagliato! Andavo da un punto di vista storico. In origine era il percorso del file che richiedeva la distinzione tra maiuscole e minuscole solo se si stava toccando il file system. Altrimenti non lo era. Ma oggi le cose sono cambiate. Ad esempio, i parametri e CGI non esistevano originariamente. La tua risposta assume una prospettiva attuale. Ho dovuto premiare i tuoi sforzi !! Ti sei davvero divertito con questo! Chi sapeva che sarebbe esploso in quel modo ?? Salute !!
• @ w3dk: è ‘ una stranezza terminologica non molto interessante, ma potresti prendere ” distingue tra maiuscole e minuscole ” nel senso che ” cambiando le maiuscole / minuscole di un carattere può cambiare lintero “, oppure potresti interpretarlo nel senso che ” cambiando le maiuscole e minuscole di un carattere sempre cambia lintero “. Kobi sembra affermare il secondo, preferisce che la distinzione tra maiuscole e minuscole significhi ” qualsiasi cambiamento nel caso è significativo “, che ovviamente non è vero per gli URL. Preferisci il primo. ‘ è solo una questione di quanto sono sensibili alle maiuscole.
• @ rybo111: se un utente digita example.com/fOObaR , la specifica richiede che il server allindirizzo www.example.com riceva un percorso ” / fOObaR ” come dato; tace sulla questione se il server debba trattarlo in modo diverso da ” / foOBaR “.

Semplice. Il sistema operativo distingue tra maiuscole e minuscole. I server Web generalmente 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 distinzione tra maiuscole e minuscole è una parte importante. Questo è il motivo per cui IIS non ha mai fatto distinzione tra maiuscole e minuscole; perché Windows non faceva mai distinzione tra maiuscole e minuscole.

[Aggiorna]

Ci sono stati alcuni forti argomenti 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! Lasciatemi 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 di sistema, non è possibile bypassare i servizi del sistema operativo.Dico questo perché questi sono due campi separati e raramente si incrociano. Le applicazioni sono scritte per utilizzare i servizi del sistema operativo come regola. Ovviamente ci sono rare eccezioni.

Quando i server web iniziarono a comparire, gli sviluppatori di applicazioni non cercavano di aggirare i servizi del sistema operativo. Cerano molte 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 erano estremamente stabili e robusti oppure estremamente semplici e leggeri e non valevano il costo.

Tieni presente che i primi server web funzionavano su computer costosi come DEC VAX / Server VMS e Unix del giorno (Berkeley e Ultrix e altri) su computer main frame o mid-frame, poi subito dopo su computer leggeri come PC e Windows 3.1. Quando i motori di ricerca più moderni iniziarono a comparire, come Google nel 1997/8, Windows era passato a Windows NT e anche altri sistemi operativi come Novell e Linux avevano iniziato a eseguire server web. Apache era il server web dominante sebbene ce ne fossero altri come IIS e O “Reilly che erano anchessi molto popolari. Nessuno di loro allepoca aggirava i servizi del sistema operativo. È probabile che nessuno dei server web lo faccia ancora oggi.

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

I file system sono meccanismi piuttosto semplici. Quando viene effettuata una richiesta di accesso a un file, se quel file esiste, la richiesta viene passata al sottosistema di autorizzazione e, se concessa, la richiesta originale viene soddisfatta. Se la risorsa lo fa non esiste o non è autorizzato, viene lanciata uneccezione dal sistema. Quando unapplicazione effettua una richiesta, viene impostato un trigger e lapplicazione attende. Quando la richiesta viene risposta, il trigger viene lanciato e lapplicazione elabora la risposta della richiesta. funziona ancora in questo modo oggi. Se lapplicazione vede che la richiesta è stata s Una volta soddisfatto, continua, se fallisce, lapplicazione esegue una condizione di errore allinterno del suo codice o muore se non viene gestita. Semplice.

Nel caso di un server web, supponendo che venga effettuata una richiesta URL per un percorso / file, il server web prende la porzione di percorso / file della richiesta URL (URI) e fa una richiesta al file system ed è soddisfatto o genera uneccezione. Il server Web quindi elabora la risposta. Se, ad esempio, il percorso e il file richiesti vengono trovati e laccesso viene concesso dal sottosistema di autorizzazione, il server Web elabora la richiesta di I / O normalmente. Se il file system genera uneccezione, il server Web restituisce un errore 404 se il file è Non trovato o un errore 403 Proibito se il codice motivo non è autorizzato.

Poiché alcuni sistemi operativi distinguono tra maiuscole e minuscole e i file system questo tipo richiede 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 non appena le ricevono. Se la porzione di percorso / file della richiesta URL trasmessa direttamente al file system non corrisponde a ciò che si trova sul disco rigido, il file system genera uneccezione e il server Web restituisce un errore 404 Non trovato.

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

Commenti

• Penso che il tuo argomento sia errato. Benché Berners-Lee non ‘ abbia alcuna scelta sulla distinzione tra maiuscole e minuscole degli URL ftp. Ha avuto modo di progettare URL http. Avrebbe potuto specificarli solo come US-ASCII e senza distinzione tra maiuscole e minuscole. Se ci sono mai stati server Web che hanno appena passato il percorso dellURL al file system, allora non erano sicuri e lintroduzione della codifica URL ha interrotto la compatibilità con loro. Dato che il percorso è in fase di elaborazione prima di passare al caso eccezionale del sistema operativo, sarebbe stato facile da implementare. Pertanto penso che dobbiamo considerare questa come una decisione di progettazione e non una stranezza di implementazione.
• @WilliamHay Questo non ha nulla a che fare con Berners-Lee o con il design del web. Si tratta di limitazioni e requisiti del sistema operativo. Sono un ingegnere di sistemi interni in pensione. Allepoca lavoravo su questi sistemi. Ti sto dicendo esattamente perché gli URL fanno distinzione tra maiuscole e minuscole. Non è unipotesi. Non è unopinione. È un fatto. La mia risposta è stata volutamente semplificata. Naturalmente ci sono controlli dei file e altri processi che possono essere eseguiti prima di emettere qualsiasi istruzione aperta. Di conseguenza, sì (!) I server web sono ancora parzialmente insicuri fino ad oggi.
• Se gli URL fanno distinzione tra maiuscole e minuscole non ha nulla a che fare con il design del web? Veramente? Argomento dellautorità seguito da Argomento per asserzione.Il fatto che i server web passino il componente del percorso di un URL più o meno direttamente a una chiamata aperta è una conseguenza del design degli URL, non una causa di esso. I server (o gli smart client nel caso dellFTP) potrebbero aver nascosto allutente la distinzione tra maiuscole e minuscole dei filesystem. Che non ‘ t è una decisione progettuale.
• @WilliamHay Devi rallentare la tramoggia e rileggere ciò che ho scritto. Sono un ingegnere di sistemi interni in pensione che scrive componenti del sistema operativo, stack di protocolli e codice router per ARPA-Net, ecc. Ho lavorato con Apache, O ‘ Reilly e IIS interni. Il tuo argomento FTP non tiene lacqua poiché almeno i principali server FTP mantengono la distinzione tra maiuscole e minuscole per lo stesso motivo. In nessun momento ho detto nulla sulla progettazione di URL / URI. In nessun momento ho detto che i server web hanno trasmesso valori senza elaborazione. Ho detto che i servizi del sistema operativo sono comunemente usati e che il file system richiede una corrispondenza esatta per avere successo.
• @WilliamHay Per favore, comprendi che tu ed io stiamo pensando a scopi incrociati. Tutto quello che stavo dicendo nella mia risposta è che per alcuni sistemi operativi, le chiamate al file system fanno distinzione tra maiuscole e minuscole in base alla progettazione. Le applicazioni che utilizzano le chiamate di sistema, e la maggior parte lo fanno, sono limitate allapplicazione delle regole del sistema operativo, in questo caso, distinzione tra maiuscole e minuscole. Non è impossibile aggirare questa regola. In effetti questo può essere un po banale in alcuni casi, sebbene non pratico. Ero abituato a bypassare regolarmente il file system nel mio lavoro per riordinare i dischi rigidi che andavano male per un motivo o per laltro o per analizzare gli interni dei file di database, ecc.

1. Gli URL affermano di essere un localizzatore di risorse UNIFORME e possono puntare a risorse precedenti al Web. Alcuni di questi fanno distinzione tra maiuscole e minuscole (ad esempio molti server ftp) e gli URL devono essere in grado di rappresentare queste risorse in modo ragionevolmente intuitivo.

2. La mancanza di distinzione tra maiuscole e minuscole richiede più lavoro quando si cerca una corrispondenza (nel sistema operativo o sopra di esso).

3. Se si definiscono gli URL come case sensitive, i singoli server possono implementarli come case insensitive, se lo desiderano. Non è vero il contrario.

4. La mancanza di sensibilità tra maiuscole e minuscole può non essere banale in contesti internazionali: https://en.wikipedia.org/wiki/Dotted_and_dotless_I . Inoltre RFC1738 consentiva luso di caratteri al di fuori dellintervallo ASCII a condizione che fossero codificati ma non specificassero un set di caratteri. Questo è abbastanza importante per qualcosa che si definisce WORLD wide Web. Definire gli URL come senza distinzione tra maiuscole e minuscole aprirà molte possibilità per bug.

5. Se stai cercando di impacchettare molti dati in un URI (ad esempio un URI dati ) puoi comprimerne di più se maiuscolo e minuscolo sono distinti.

Commenti

• I ‘ Sono abbastanza sicuro che gli URL fossero storicamente limitati ad ASCII. Quindi è improbabile che linternazionalizzazione sia una ragione originale. La storia di Unix che fa distinzione tra maiuscole e minuscole, OTOH, probabilmente ha giocato un ruolo enorme.
• Sebbene solo un sottoinsieme di ASCII possa essere utilizzato non codificato in un URL, RFC1738 afferma specificamente che i caratteri al di fuori dellintervallo ASCII possono essere usati codificati. Senza specificare un set di caratteri, non è ‘ possibile conoscerlo quali ottetti rappresentano lo stesso carattere acter tranne case. Aggiornato.
• Rif. 4: ‘ in realtà è peggio di così. Punteggiato e senza punti I sono una dimostrazione del principio più generale che, anche se tutto è UTF-8 (o qualche altro UTF), non puoi scrivere correttamente in maiuscolo o minuscolo senza conoscere la lingua a cui appartiene il testo . Nella lingua predefinita, una lettera latina maiuscola I minuscola con una lettera latina i minuscola, che è sbagliata in turco perché aggiunge un punto (non cè ” I maiuscola turca senza punti ” punto di codice; ‘ intendevi utilizzare il punto di codice ASCII). Aggiungi differenze di codifica e questo va da ” davvero difficile ” a ” completamente intrattabile . ”

Ho rubato dal blog una Old New Thing labitudine di affrontare le domande della forma “perché è che qualcosa è il caso?” con la contro-domanda “come sarebbe il mondo, se non fosse così?”

Supponiamo che io abbia configurato un server web per fornire i miei documenti da una cartella in modo da poterli leggere il telefono quando ero fuori ufficio. Ora, nella mia cartella dei documenti, ho tre file, todo.txt, ToDo.txt e TODO.TXT (Lo so, ma per me aveva senso quando ho creato i file).

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

Supponiamo che io abbia uno script che mi permette di aggiungere un contatto alla mia rubrica, cosa che posso fare anche sul web.Come dovrebbe prendere i suoi parametri? Beh, mi piacerebbe usarlo come: http://www.example.com/addcontact.php?name=Tom McHenry von der O"Reilly. Ma se non potessi specificare il nome per caso, come lo farei?

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

Ma tutto ciò sembra come se stesse rispondendo alla domanda sbagliata, in ogni caso.

La domanda che penso tu stavi davvero chiedendo è “Perché i server web ti 404 solo per una differenza di caso, quando sono computer, progettati per rendere la vita più semplice e sono perfettamente in grado di trovare almeno le variazioni di maiuscole e minuscole più ovvie nellURL che ho digitato che funzionerebbero? “

La risposta è che mentre alcuni siti hanno fatto questo (e meglio controlla 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?

Commenti

• Alcuni siti utilizzano una sorta di meccanismo per convertire un file ny query in minuscolo o qualcosa di coerente. In un certo senso, questo è intelligente.
• No, non dovrebbero ‘ t. Questa funzionalità può essere, e spesso è, aggiunta quando è desiderabile (ad esempio, dai moduli in apache.) Imporre questo tipo di cambiamento come comportamento predefinito – o peggio, comportamento immutabile – sarebbe più distruttivo del relativamente raro occasione in cui qualcuno deve digitare manualmente un URL oltre al nome host. Per un buon esempio del perché non farlo, ricorda il fiasco quando Network Solutions ” risolveva ” errori di dominio inesistenti dal DNS pubblico query.
• @SirNickity Nessuno proponeva limmutabilità a qualsiasi livello e le pagine di errore del server web sono configurabili su ogni server web che ‘ abbia mai usato; nessuno stava suggerendo di sostituire 404 con codici 30 *, ma piuttosto di aggiungere un elenco di link di suggerimenti selezionabili da persone alla pagina di errore; i nomi di dominio sono un argomento molto diverso e il problema non fa distinzione tra maiuscole e minuscole e in un contesto di sicurezza diverso; e IIS già ” risolve ” (ignorando) le differenze tra maiuscole e minuscole nelle parti del percorso o del nome file degli URI.
• Dal 1996, Apache ti ha permesso di farlo con mod_speling . Semplicemente non ‘ sembra essere una cosa molto popolare da fare. Gli utenti di Unix / Linux vedono linsensibilità tra maiuscole e minuscole come regola, mentre linsensibilità tra maiuscole e minuscole come eccezione.

Sebbene il la risposta sopra è corretta & buona. Vorrei aggiungere altri punti.

Per capire meglio, si dovrebbe capire la differenza fondamentale tra il server Unix (Linux) e quello Windows. Unix fa distinzione tra maiuscole e minuscole & Windows non fa distinzione tra maiuscole e minuscole.

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

La maggior parte degli scienziati conosceva Unix, quindi potrebbero essere stati 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.

Commenti

• ” Windows Server è stato rilasciato dopo il 2000. ” Il team di Windows NT 3.1 sarebbe stato in disaccordo con te nel 1993. NT 3.51 nel 1995 era probabilmente quando NT iniziò a diventare abbastanza maturo e ben consolidato per supportare applicazioni server critiche per lazienda.
• NT 3.51 aveva linterfaccia Win 3.1. Windows non è decollato davvero fino a Windows 95 e ci è voluto NT 4.0 per ottenere la stessa interfaccia.
• Michael Kj ö rling, daccordo. Permettimi di modificarlo.
• @Thorbj ø rnRavnAndersen Nel mercato dei server, NT 3.51 ha avuto un discreto successo. Nel mercato consumer / prosumer, ci è voluto fino a Windows 2000 (NT 5.0) prima che la linea NT iniziasse a guadagnare una forte trazione.
• In effetti, WorldWideWeb è stato inizialmente sviluppato su sistemi basati su Unix, che fanno distinzione tra maiuscole e minuscole file system e la maggior parte degli URL mappati direttamente ai file nel file system.

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

È molto raro ottenere un resoconto storicamente accurato account.A volte, quando le decisioni vengono prese nei comitati per gli standard, cè una traccia documentaria di come è stato condotto il dibattito, ma nei primi giorni del web le decisioni venivano prese frettolosamente da pochi 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 degli URL – vedere http://www.dailymail.co.uk/sciencetech/article-1220286/Sir-Tim-Berners-Lee-admits-forward-slashes-web-address-mistake.html

Allinizio gli URL venivano mappati in modo molto diretto ai nomi dei file, ei file erano generalmente su macchine Unix-like, e le macchine Unix-like hanno nomi di file che fanno distinzione tra maiuscole e minuscole. Quindi la mia ipotesi è che sia successo in quel modo per comodità di implementazione e lusabilità (per gli utenti finali) non è mai stata nemmeno presa in considerazione. Di nuovo, nei primi tempi gli utenti erano comunque tutti programmatori Unix.

Commenti

• Anche gli utenti finali erano utenti Unix (non necessariamente programmatori, ma fisici ad alta energia e simili), quindi anche loro erano abituati allinsensibilità al maiuscolo / minuscolo.

Questo non ha nulla a che fare con il luogo in cui hai acquistato il tuo dominio, DNS non fa distinzione tra maiuscole e minuscole. Tuttavia, il file system sul server che stai utilizzando per lhosting è.

Questo non è veramente 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 le cose, ti consiglio di nominare sempre le tue pagine in minuscolo, quindi non devi mai ricontrollare il nome quando scrivi un link.

Closetnoc ha ragione riguardo al sistema operativo. Alcuni file system trattano lo stesso nome con case differenti come file differenti.

Inoltre, esiste un vero scopo / vantaggio nellavere un URL che fa distinzione tra maiuscole e minuscole (al contrario della stragrande maggioranza degli URL che puntano alla stessa pagina, indipendentemente le maiuscole)?

Sì. per evitare problemi di contenuti duplicati.

Se ad esempio avessi 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 puntato esattamente alla stessa pagina con lo stesso identico contenuto, quindi avresti contenuti duplicati e sono sicuro che tu abbia una console di ricerca di Google (strumenti per i webmaster), Google te lo indicherà.

Quello che voglio Suggerirei di fare se ti trovi in quella situazione è di usare tutti gli URL minuscoli, quindi reindirizzare gli URL con almeno una lettera maiuscola alla versione minuscola. Quindi nellelenco di URL sopra, reindirizza tutti gli URL al primo URL.

Commenti

• ” Sì. per evitare problemi con i contenuti duplicati. ” – Ma sembrerebbe vero il contrario? Il fatto che gli URL possano fare distinzione tra maiuscole e minuscole (ed è così che i motori di ricerca li trattano) causa i problemi di contenuto duplicato che hai menzionato. Se gli URL fossero universalmente privi di distinzione tra maiuscole e minuscole, non ci sarebbero problemi di contenuto duplicato con lettere maiuscole e minuscole. page-1 sarebbe lo stesso di PAGE-1.
• Penso che una configurazione server scadente è ciò che può causare contenuti duplicati quando si tratta di case. Ad esempio, listruzione RewriteRule ^request-uri$ /targetscript.php [NC] memorizzata in .htaccess corrisponderebbe a http://example.com/request-uri e http://example.com/ReQuEsT-Uri perché [NC] indica che le maiuscole / minuscole ‘ non hanno importanza quando si valuta quellunica espressione regolare.

La distinzione tra maiuscole e minuscole ha valore.

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

4 caratteri hanno la possibilità di 52 * 52 * 52 * 52 combinazioni, pari a 7311616 combinazioni.

Se non puoi scrivere in maiuscolo i caratteri, la quantità di combinazioni è 26 * 26 * 26 * 26 = 456976

Sono oltre 14 volte più combinazioni per 52 caratteri rispetto a ce ne sono per 26. Quindi, per la memorizzazione dei dati, gli URL possono essere più brevi e più informazioni possono essere trasferite sulle reti con meno dati trasferiti.

Questo è il motivo per cui vedi YouTube che utilizza URL come https://www.youtube.com/watch?v=xXxxXxxX