De ce adresele URL sunt sensibile la majuscule și minuscule?

De ce nu ar fi „t URL-ul este sensibil la majuscule și minuscule?

Înțeleg că poate părea un tip provocator (și „avocat” al avocatului ”) de întrebare retorică, dar cred că este util să se ia în considerare. Proiectarea HTTP este că un „client”, pe care îl numim în mod obișnuit „browser web”, solicită date „serverului web”.

Există multe, multe servere web diferite care sunt lansate. Microsoft a lansat IIS cu Windows Sisteme de operare pentru server (și altele, inclusiv Windows XP Professional). Unix are greutăți mari, cum ar fi nginx și Apache, ca să nu mai vorbim de oferte mai mici, cum ar fi httpd intern OpenBSD sau thttpd sau lighttpd. În plus, multe dispozitive capabile de rețea au încorporat servere web care pot fi utilizate pentru a configura dispozitivul, inclusiv dispozitive cu scopuri specifice rețelelor, cum ar fi routere (inclusiv multe puncte de acces Wi-Fi și modemuri DSL) și alte dispozitive precum imprimante sau UPS-urile (unități de alimentare neîntreruptibile susținute de baterie) care pot avea conectivitate la rețea.

Deci, întrebarea „De ce adresele URL sunt sensibile la majuscule?”, Se întreabă „De ce serverele web tratează adresa URL ca fiind sensibile la majuscule și minuscule? ” Și răspunsul real este: nu fac asta toți. Cel puțin un server web, care este destul de popular, NU este sensibil la majuscule și minuscule. (Serverul web este IIS.)

Un motiv cheie pentru un comportament diferit între diferite servere web se rezumă, probabil, la o chestiune de simplitate. Modul simplu de a crea un server web este de a face lucrurile la fel ca modul în care sistemul de operare al computerului / dispozitivului localizează fișierele. De multe ori, serverele web localizează un fișier pentru a oferi un răspuns. Unix a fost conceput în jurul computerelor de ultimă generație, astfel încât Unix a oferit funcționalitatea dorită de a permite litere mari și mici. Unix a decis să trateze majusculele și minusculele ca fiind diferite, pentru că ei sunt diferiți. Acesta este lucrul simplu și firesc de făcut. Windows are o istorie de lipsă de majuscule și minuscule datorită dorinței de a sprijini software deja creat, iar acest istoric se întoarce la DOS, care pur și simplu nu suporta litere mici, posibil într-un efort pentru a simplifica lucrurile cu computere mai puțin puternice care foloseau mai puțină memorie. Deoarece aceste sisteme de operare sunt diferite, rezultatul este că serverele web concepute simplu (versiunile anterioare ale) reflectă aceleași diferențe.

Acum, cu toate acestea fundal, iată câteva răspunsuri specifice la întrebările specifice:

Când URL-urile au fost proiectate pentru prima dată, de ce a fost făcută caracteristică sensibilitatea la majuscule și minuscule?

De ce nu? Dacă toate serverele web standard nu distingeau majuscule și minuscule, aceasta ar indica faptul că serverele web respectau un set de reguli specificate de standard. Pur și simplu nu existau regula care spune că acest caz trebuie ignorat. Motivul pentru care nu există o regulă este pur și simplu că nu a existat niciun motiv pentru să existe o astfel de regulă. De ce să vă deranjați să stabiliți reguli inutile?

Întreb asta pentru că mi se pare (adică, un laic) că insensibilitatea la majuscule și minuscule ar fi preferată pentru a preveni erorile inutile și pentru a simplifica un șir de text deja complicat.

URL-urile au fost proiectate pentru ca mașinile să le proceseze . Deși o persoană poate introduce o adresă URL completă într-o bară de adrese, aceasta nu a fost „o parte majoră a proiectului intenționat. Proiectarea intenționată este că oamenii ar urma („ faceți clic pe ”) hyperlinkuri. Dacă oamenii laici obișnuiți fac acest lucru, atunci ei într-adevăr nu vă pasă dacă adresa URL invizibilă este simplă sau complicată.

De asemenea, există un scop real / avantajul de a avea o adresă URL sensibilă la majuscule (ca opus marii majorități a adreselor URL care indică aceeași pagină, indiferent de majuscule)?

Al cincilea punct numerotat al Răspunsul lui William Hay menționează un avantaj tehnic: adresele URL pot fi o modalitate eficientă pentru un browser web de a trimite un pic de informații către un server web și pot fi incluse mai multe informații dacă există mai puține restricții, deci o restricție de sensibilitate la majuscule și mici ar reduce cantitatea de informații care pot fi incluse.

Cu toate acestea, în multe cazuri, nu există un avantaj foarte convingător pentru sensibilitatea la majuscule, care este dovedit de faptul că IIS de obicei nu se deranjează cu el.

În rezumat, cel mai convingător motiv este probabil simplitatea pentru cei care au proiectat software-ul serverului web, în special pe o platformă sensibilă la majuscule și minuscule, cum ar fi Unix . (HTTP nu a fost ceva care a influențat designul original al Unix, deoarece Unix este mai vechi decât HTTP.)

Comentarii

• ” Un motiv cheie pentru un comportament diferit între diferite browsere web se reduce probabil la o chestiune de simplitate. ” – Presupun că înseamnă ” servere web „, mai degrabă decât ” browsere web ” aici și în alte câteva locuri?
• Actualizat. Revizuit fiecare caz al ” browserelor ” și am făcut mai multe înlocuiri. Vă mulțumim că ați subliniat acest lucru, astfel încât o anumită calitate să poată fi îmbunătățită.
• Am primit mai multe răspunsuri excelente la întrebarea mea, de la cele istorice la cele tehnic. Ezit să mă opun și să accept un răspuns mai scăzut, dar răspunsul lui @TOOGAM ‘ a fost cel mai util pentru pe mine. Acest răspuns este amănunțit și amplu, dar explică conceptul într-o manieră simplă, conversațională, pe care o pot înțelege. Și cred că acest răspuns este o introducere bună la explicațiile mai aprofundate.
• Motivul pentru care Windows are un sistem de fișiere care nu face sensibilitatea la majuscule și minuscule se datorează lui ‘ Patrimoniul DOS. MS-DOS a început viața pe computere precum Tandy TRS-80, care folosea un televizor ca afișaj și inițial nu suporta litere mici din cauza lipsei de rezoluție. Din moment ce nu putea ‘ t afișa minuscule, nu erau acceptate ‘ majuscule. MS-DOS a fost autorizat de IBM pentru a deveni originalul PC-DOS. În timp ce computerul original putea afișa minuscule, sistemul de fișiere a fost portat ca atare din MS-DOS.

Adresele URL nu sunt sensibile la majuscule, ci doar părți din ele.
De exemplu, nimic nu este sensibil la majuscule și minuscule în URL-ul https://google.com,

Cu referire la RFC 3986 – Uniform Resource Identifier (URI): sintaxă generică

În primul rând, de la Wikipedia , o adresă URL arată:

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

(Am eliminat user:password parte pentru că nu este interesant și rar folosit)

• scheme :

schemele nu disting majuscule și minuscule

• host :

Subcomponenta gazdă nu distinge majuscule / minuscule.

• path :

Componenta căii conține date …

• query :

Componenta de interogare conține date care nu sunt ierarhizate …

• fragment :

Tipurile de suporturi individuale își pot defini propriile restricții sau structuri în sintaxa identificatorului de fragment pentru specificarea diferitelor tipuri de subseturi, vizualizări sau referințe externe

Deci, scheme și host nu disting majuscule și minuscule.
Restul URL-ul este sensibil la majuscule și minuscule.

De ce este path diferențiat de majuscule și minuscule?

Aceasta pare a fi principala întrebare.
Este dificil de răspuns „de ce” s-a făcut ceva dacă nu a fost documentat, dar putem face o presupunere foarte bună.
Am „ales citate foarte specifice din specificație, cu accent pe date .
Să vedem din nou adresa URL:

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

• Locație – Locația are o formă canonică și nu face minuscule. De ce? Probabil, astfel încât să puteți cumpăra un nume de domeniu fără a fi nevoie să cumpărați mii de variante.

• Date – datele sunt utilizate de server țintă, iar aplicația poate alege ce înseamnă . Nu ar avea niciun sens să faceți ca datele să nu fie sensibile la majuscule. Aplicația ar trebui să aibă mai multe opțiuni, iar definirea insensibilității la majuscule și minuscule în specificații va limita aceste opțiuni.
  Aceasta este, de asemenea, o distincție utilă pentru HTTPS: datele sunt criptate , dar gazda este vizibilă.

Este util?

Case- sensibilitatea are capcane atunci când vine vorba de cache și URL-uri canonice, dar este cu siguranță utilă. Câteva exemple:

• Base64 , care este utilizat în URI-uri de date .
• Site-urile pot codifica date Base64 în adresa URL, de exemplu: http://tryroslyn.azurewebsites.net/#f:r/A4VwRgNglgxgBDCBDAziuBhOBvGB7AOxQBc4SAnKAgczLgF44AiAUQPwBMBTDuKuYgAsucAKoAlADIBCJgG4AvkA
• Scurttoarele URL utilizează sensibilitatea la majuscule și minuscule: /a5B poate fi diferit de /a5b
• După cum ați menționat, Wikipedia poate diferenția „SIDA” de „SIDA”.

Comentarii

• ” adresele URL nu sunt cas e-sensitive. ” / ” Restul adresei URL este sensibil la majuscule și minuscule. ” – Aceasta pare a fi o contradicție?
• Într-adevăr, schema definește la ce să ne așteptăm în restul adresei URL. http: și scheme conexe înseamnă că adresa URL se referă la un nume de gazdă DNS. DNS nu distingea majusculele ASCII cu mult înainte de inventarea adreselor URL. Consultați pagina 55 din ietf.org/rfc/rfc883.txt
• Frumos detaliat! Mergeam din punct de vedere istoric. Inițial, calea fișierului trebuia să fie sensibilă la majuscule și minuscule numai dacă apăsați sistemul de fișiere. Altfel, nu a fost. Dar astăzi lucrurile s-au schimbat. De exemplu, parametrii și CGI nu existau inițial. Răspunsul dvs. are o perspectivă actuală. A trebuit să-ți răsplătesc eforturile !! Chiar te-ai săpat de asta! Cine știa că acest lucru ar exploda așa cum a făcut-o ?? Noroc !!
• @ w3dk: ‘ este un aspect neobișnuit de terminologic, dar ai putea lua ” sensibil la majuscule ” pentru a însemna, ” modificând majusculele și minusculele unui caracter poate schimba întregul „, sau s-ar putea să-l înțelegeți, ” modificând majusculele și minusculele unui caracter întotdeauna schimbă întregul „. Kobi pare să-l afirme pe acesta din urmă, el preferă că sensibilitatea la majuscule și minuscule ar trebui să însemne ” orice modificare a cazului este semnificativă „, ceea ce desigur nu este adevărat pentru adresele URL. Îl preferați pe primul. ‘ este doar o chestiune de cât sunt sensibile la majuscule și minuscule.
• @ rybo111: Dacă un utilizator tastează example.com/fOObaR , specificația necesită ca serverul de la www.example.com să primească o cale ” / fOObaR ” așa cum este dat; este tăcut cu privire la întrebarea dacă serverul trebuie să trateze acest lucru diferit de ” / foOBaR „. >

Simplu. Sistemul de operare este sensibil la majuscule. Serverelor web nu le pasă, în general, decât dacă trebuie să acceseze sistemul de fișiere la un moment dat. Aici Linux și alte sisteme de operare bazate pe Unix aplică regulile sistemului de fișiere, caz în care sensibilitatea este o parte majoră. Acesta este motivul pentru care IIS nu a fost niciodată sensibil la majuscule; deoarece Windows nu a fost niciodată sensibil la majuscule.

[Actualizare]

Au existat câteva argumente puternice în comentarii (de când au fost șterse) dacă URL-urile au vreo relație cu sistemul de fișiere, așa cum am spus. Aceste argumente au devenit aprinse. Este extrem de miop să crezi că nu există o relație. Există absolut! Permiteți-mi să explic mai departe.

Programatorii de aplicații nu sunt, în general, programatori interni de sistem. Nu sunt insultător. Acestea sunt două discipline separate, iar cunoștințele interne ale sistemului nu sunt necesare pentru a scrie aplicații atunci când aplicațiile pot pur și simplu să apeleze la sistemul de operare. Deoarece programatorii de aplicații nu sunt programatori interni de sistem, nu este posibilă ocolirea serviciilor OS.Spun asta pentru că acestea sunt două tabere separate și rareori se încrucișează. Aplicațiile sunt scrise pentru a utiliza serviciile OS ca regulă. Există rareori unele excepții, desigur.

Înapoi când serverele web au început să apară, dezvoltatorii de aplicații nu au încercat să ocolească serviciile OS. Au existat mai multe motive pentru aceasta. Unul, nu era necesar. În al doilea rând, programatorii de aplicații nu știau în general cum să ocolească serviciile OS. Trei, majoritatea sistemelor de operare au fost fie extrem de stabile și robuste, fie extrem de simple și ușoare și nu merită costul.

Rețineți că primele servere web funcționau fie pe computere scumpe, cum ar fi DEC VAX / Serverele VMS și Unix-ul zilei (Berkeley și Ultrix, precum și altele) pe computerele cu cadru principal sau mijlociu, apoi la scurt timp după computerele ușoare, cum ar fi PC-urile și Windows 3.1. Când au început să apară motoare de căutare mai moderne, cum ar fi Google în 1997/8, Windows sa mutat în Windows NT și alte sisteme de operare precum Novell și Linux au început să ruleze și servere web. Apache a fost serverul web dominant, deși au existat altele, cum ar fi IIS și O „Reilly, care au fost, de asemenea, foarte populare. Niciunul dintre ele nu a ocolit atunci serviciile de sistem de operare. Este probabil ca niciunul dintre serverele web să nu o facă chiar și astăzi.

Primele servere web au fost destul de simple. Sunt și astăzi. Orice solicitare făcută pentru o resursă printr-o cerere HTTP care există pe un hard disk a fost / este făcută de serverul web prin sistemul de fișiere OS.

Sistemele de fișiere sunt mecanisme destul de simple. Pe măsură ce se face o cerere de acces la un fișier, dacă acel fișier există, cererea este transmisă subsistemului de autorizare și, dacă este acceptată, cererea inițială este satisfăcută. Dacă resursa nu nu există sau nu este autorizată, o excepție este aruncată de sistem. Când o aplicație face o cerere, se activează un declanșator și aplicația așteaptă. Când se răspunde la cerere, declanșatorul este aruncat și aplicația procesează răspunsul la cerere. funcționează așa și astăzi. Dacă aplicația vede că solicitarea a fost s atisfied continuă, dacă a eșuat, aplicația execută o condiție de eroare în codul său sau moare dacă nu este tratată. Simplu.

În cazul unui server web, presupunând că se face o cerere URL pentru o cale / fișier, serverul web preia porțiunea cale / fișier a cererii URL (URI) și face o cerere la sistemul de fișiere și este fie satisfăcut, fie aruncă o excepție. Serverul web procesează apoi răspunsul. Dacă, de exemplu, calea și fișierul solicitate sunt găsite și accesul este acordat de subsistemul de autorizare, atunci serverul web procesează solicitarea I / O în mod normal. Dacă sistemul de fișiere lansează o excepție, atunci serverul web returnează o eroare 404 dacă fișierul nu este găsit sau este interzis 403 dacă codul motiv nu este autorizat.

Deoarece unele sisteme de operare sunt sensibile la majuscule și la sistemele de fișiere ale acest tip necesită potriviri exacte, calea / fișierul solicitat de serverul web trebuie să se potrivească exact cu ceea ce există pe hard disk. Motivul pentru aceasta este simplu. Serverele web nu ghicesc la ce te referi. Niciun computer nu face acest lucru fără a fi programat. Serverele web procesează pur și simplu solicitările pe măsură ce le primesc. Dacă porțiunea de cale / fișier a cererii URL care este transmisă direct către sistemul de fișiere nu se potrivește cu cea de pe hard disk, atunci sistemul de fișiere aruncă o excepție și serverul web returnează o eroare 404 Not Found.

Este chiar atât de simplu. Nu este știință rachetă. Există o relație absolută între porțiunea de cale / fișier a unei adrese URL și sistemul de fișiere.

Comentarii

• Cred că argumentul dvs. este defect. În timp ce Berners-Lee nu ‘ nu a avut de ales cu privire la sensibilitatea la majuscule și minuscule a adreselor URL ftp. Trebuie să proiecteze URL-uri http. El le-ar fi putut specifica ca fiind doar US-ASCII și insensibile la majuscule. Dacă au existat vreodată servere web care tocmai au trecut calea URL către sistemul de fișiere, atunci acestea au fost nesigure și introducerea codării URL a rupt compatibilitatea cu acestea. Având în vedere că calea este în curs de procesare înainte de predare la sistemul de operare spargere, ar fi fost ușor de implementat. Prin urmare, cred că trebuie să considerăm aceasta ca o decizie de proiectare, nu ca o ciudățenie de implementare.
• @WilliamHay Acest lucru nu are nimic de-a face cu Berners-Lee sau cu designul web. Este vorba despre limitări și cerințe ale sistemului de operare. Sunt inginer intern de sisteme pensionar. La acel moment am lucrat la aceste sisteme. Vă spun exact de ce adresele URL sunt sensibile la majuscule și minuscule. Nu este o presupunere. Nu este o opinie. Este un fapt. Răspunsul meu a fost intenționat simplificat. Desigur, există verificări de fișiere și alte procese care pot fi efectuate înainte de a emite orice declarație deschisă. Și Da (!) Serverele web sunt parțial nesigure până în prezent, ca urmare.
• Dacă adresele URL sunt sensibile la majuscule și minuscule, nu are nimic de-a face cu proiectarea web? Într-adevăr? Argument de la autoritate urmat de Argument de afirmare.Faptul că serverele web transmit componenta cale a unei adrese URL mai mult sau mai puțin direct către un apel deschis este o consecință a proiectării adreselor URL, nu o cauză a acesteia. Serverele (sau clienții inteligenți în cazul FTP) ar fi putut ascunde utilizatorului sensibilitatea la majuscule a sistemelor de fișiere. Faptul că nu ‘ t este o decizie de proiectare.
• @WilliamHay Trebuie să încetiniți buncărul de iarbă și să recitiți ceea ce am scris. Sunt un inginer intern de sisteme pensionate care scrie componente OS, stive de protocol și cod router pentru ARPA-Net etc. Am lucrat cu Apache, O ‘ Reilly și IIS. Argumentul dvs. FTP nu reține apa deoarece cel puțin serverele FTP majore rămân sensibile la majuscule și minuscule din același motiv. În niciun moment nu am spus nimic despre proiectarea URL / URI. În niciun moment nu am spus că serverele web au trecut valori fără procesare. Am spus că serviciile de sistem de operare sunt utilizate în mod obișnuit și că sistemul de fișiere necesită o potrivire exactă pentru a reuși.
• @WilliamHay Vă rugăm să înțelegeți că tu și cu mine ne gândim la scopuri transversale. Tot ceea ce spuneam în răspunsul meu este că, pentru unele sisteme de operare, apelurile din sistemul de fișiere sunt sensibile la majuscule și minuscule. Aplicațiile care utilizează apeluri de sistem și, cel mai mult, se limitează la aplicarea regulilor sistemului de operare – în acest caz, sensibilitate la majuscule. Nu este imposibil să ocolești această regulă. De fapt, acest lucru poate fi oarecum banal în unele cazuri, deși nu este practic. Obișnuiam să ocolesc în mod obișnuit sistemul de fișiere din munca mea pentru a descărca hard disk-uri care mergeau kablooie dintr-un motiv sau altul sau pentru a analiza elementele interne ale fișierelor bazei de date etc.

1. URL-urile susțin că sunt un localizator de resurse UNIFORM și pot indica resurse care sunt anterioare internetului. Unele dintre acestea sunt sensibile la majuscule (de exemplu, multe servere ftp) și adresele URL trebuie să poată reprezenta aceste resurse într-un mod rezonabil de intuitiv.

2. Insensibilitatea la majuscule și minuscule necesită mai multă muncă atunci când căutați o potrivire (fie în sistemul de operare, fie deasupra acestuia).

3. Dacă definiți adresele URL ca fiind mai sensibile la majuscule și minuscule, serverele individuale le pot implementa ca insensibile la majuscule și minuscule, dacă doresc. Reversul nu este adevărat.

4. Insensibilitatea la majuscule și minuscule nu poate fi banală în contexte internaționale: https://en.wikipedia.org/wiki/Dotted_and_dotless_I . De asemenea, RFC1738 a permis utilizarea de caractere în afara intervalului ASCII, cu condiția ca acestea să fie codificate, dar nu a specificat un set de caractere. Acest lucru este destul de important pentru ceva care se numește World Wide Web. bug-uri.

5. Dacă încercați să împachetați o mulțime de date într-un URI (de exemplu, un URI de date ) puteți împacheta mai multe dacă majusculele și minusculele sunt distincte.

Comentarii

• I ‘ sunt destul de sigur că adresele URL au fost limitate în mod istoric la ASCII. Deci, este puțin probabil ca internaționalizarea să fie un motiv original. Istoria Unix care face sensibilitate la majuscule, OTOH, a jucat probabil un rol imens. li> În timp ce numai un subset de ASCII poate fi utilizat necodat într-o adresă URL RFC1738 specifică caracterele din afara intervalului ASCII pot fi utilizate codificate. Fără a specifica un set de caractere, nu este posibil să știe ‘ care octeți reprezintă același caracter actor cu excepția cazului. Actualizat.
• Re # 4: ‘ este de fapt mai rău decât atât. I punctat și fără punct sunt o demonstrație a principiului mai general că, chiar dacă totul este UTF-8 (sau un alt UTF), nu puteți majuscule sau minuscule corect fără a cunoaște localizarea la care aparține textul . În setările locale implicite, o literă latină cu majuscule I minuscule la o literă latină cu minuscule i, care este greșită în turcă, deoarece adaugă un punct (nu există ” capitală turcă fără puncte I ” punct de cod; ‘ sunteți destinat să utilizați punctul de cod ASCII). Introduceți diferențe de codificare, iar acest lucru merge de la ” foarte greu ” la ” complet intratabil . ”

Am furat de pe blog o Old New Thing obiceiul de a aborda întrebări de forma „de ce se întâmplă ceva?” cu contra-întrebarea „cum ar fi lumea, dacă nu ar fi cazul?”

Spuneți că am configurat un server web pentru a-mi servi fișierele de documente dintr-un folder, astfel încât să le pot citi pe telefonul când eram în birou. Acum, în folderul meu de documente, am trei fișiere, todo.txt, ToDo.txt și TODO.TXT (Știu, dar pentru mine a avut sens când am făcut fișierele).

Ce adresă URL aș dori să pot folosi, pentru a accesa aceste fișiere? Aș dori să le accesez într-un mod intuitiv, folosind http://www.example.com/docs/filename.

Să spun că am un script care îmi permite să adaug un contact în agenda mea, pe care îl pot faceți și pe web.Cum ar trebui să ia parametrii săi? Ei bine, aș vrea să-l folosesc ca: http://www.example.com/addcontact.php?name=Tom McHenry von der O"Reilly. Dar dacă nu ar exista nicio modalitate de a specifica numele după caz, cum aș face asta?

Cum aș diferenția paginile wiki pentru Cat și CAT, Text și TEXT, latex și LaTeX? Disambig pagini, cred, dar prefer să obțin doar ceea ce am cerut.

Dar tot ceea ce simți oricum, îmi place să răspundă la o întrebare greșită.

Întrebarea pe care cred că ți-o pui cu adevărat este „De ce serverele web 404 te fac doar pentru o diferență de caz, atunci când sunt computere, concepute pentru a simplifica viața , și sunt perfect capabili să găsească cel puțin cele mai evidente variații de caz în adresa URL pe care am introdus-o, care ar funcționa? „

Răspunsul la care este că, deși unele site-uri au făcut acest lucru (și mai bine, ele verificați și alte tipuri), nimănui nu i s-a părut că merită să schimbați pagina de eroare 404 implicită a unui server web pentru a face asta … dar poate ar trebui?

Comentarii

• Unele site-uri folosesc un fel de mecanism pentru a converti un ny interogare către toate minuscule sau ceva consecvent. Într-un fel, acest lucru este inteligent.
• Nu, nu ar trebui să ‘ t. Această funcționalitate poate fi și este adesea adăugată atunci când este de dorit (de exemplu, prin module din apache.) Impunerea acestui tip de schimbare ca comportament implicit – sau mai rău, comportament imuabil – ar fi mai perturbatoare decât relativ rar ocazie în care cineva trebuie să introducă manual o adresă URL dincolo de numele gazdei. Pentru un bun exemplu de ce să nu faceți acest lucru, amintiți-vă fiasco-ul când soluțiile de rețea ” au remediat ” erori de domeniu inexistente de la DNS-ul public interogări.
• @SirNickity Nimeni nu a propus imuabilitate la niciun nivel, iar paginile de eroare ale serverului web sunt configurabile pe fiecare server web pe care l-am folosit vreodată ‘ nimeni nu a sugerat înlocuirea codurilor 404 cu coduri 30 *, ci mai degrabă adăugarea unei liste de linkuri de sugestii care pot fi făcute clic pe oameni la pagina de eroare; numele de domenii sunt un subiect și o problemă foarte diferite, fiind nesensibile la majuscule și minuscule și într-un context de securitate diferit; și IIS deja automat ” remediază ” (ignorând) diferențele de majuscule în calea sau părțile de nume de fișier ale URI-urilor.
• Din 1996, Apache vă permite să faceți acest lucru cu mod_speling . Doar nu ‘ pare să fie un lucru foarte popular de făcut. Oamenii Unix / Linux consideră că insensibilitatea cu majuscule este o regulă, insensibilitatea cu majuscule ca fiind o excepție.

Deși răspunsul de mai sus este corect & bun. Aș dori să mai adaug câteva puncte.

Pentru a înțelege mai bine, ar trebui să înțelegem diferența de bază dintre serverul Unix (Linux) și Windows. Unix este sensibil la majuscule și minuscule & Windows nu este un sistem de operare sensibil la majuscule.

Protocolul HTTP a fost dezvoltat sau a început să fie implementat în jurul anului 1990. Protocolul HTTP a fost proiectat de inginerii care lucrează la Institutele CERN, în majoritatea acelor timpuri, oamenii de știință au folosit mașini Unix și nu Windows.

Majoritatea oamenilor de știință erau familiarizați cu Unix, deci ar fi putut fi influențați cu sistemul de fișiere în stil Unix.

Serverul Windows a fost lansat după 2000. cu mult înainte ca serverul Windows să devină popular protocolul HTTP a fost bine maturat și specificațiile au fost complete.

Acesta ar putea fi motivul.

Comentarii

• ” Serverul Windows a fost lansat după 2000. ” Echipa Windows NT 3.1 nu ar fi fost de acord cu dvs. în 1993. NT 3.51 în 1995 a fost probabil când NT a început să devină destul de matur și suficient de bine stabilit pentru a susține aplicațiile de server critice pentru afaceri.
• NT 3.51 avea interfața Win 3.1. Windows nu a decolat până la Windows 95 și a fost nevoie de NT 4.0 pentru a obține aceeași interfață.
• Michael Kj ö rling, a fost de acord. Permiteți-mi să îl modific.
• @Thorbj ø rnRavnAndersen Pe piața serverelor, NT 3.51 a avut un succes rezonabil. Pe piața consumatorilor / prosumerului, a durat până la Windows 2000 (NT 5.0) până când linia NT a început să câștige o tracțiune serioasă.
• Într-adevăr, WorldWideWeb a fost inițial dezvoltat pe sisteme bazate pe Unix, care au sensibilitate între majuscule și minuscule. sisteme de fișiere și majoritatea adreselor URL mapate direct la fișiere din sistemul de fișiere.

Cum ar trebui citit un „de ce a fost conceput astfel?” întrebare? Solicitați o prezentare corectă din punct de vedere istoric a procesului de luare a deciziilor sau vă întrebați „de ce ar fi conceput cineva așa?”?

Foarte rar este posibil să obțineți o precizie istorică cont.Uneori, atunci când deciziile sunt luate în comitetele de standarde, există o pistă documentară a modului în care s-a desfășurat dezbaterea, dar în primele zile ale web deciziile au fost luate în grabă de câțiva indivizi – în acest caz probabil chiar de către TimBL însuși – și motivarea este puțin probabilă să fi fost notat. Dar TimBL a recunoscut că a făcut greșeli în proiectarea adreselor URL – vezi http://www.dailymail.co.uk/sciencetech/article-1220286/Sir-Tim-Berners-Lee-admits-forward-slashes-web-address-mistake.html

În primele zile, adresele URL au fost mapate foarte direct la numele de fișiere, iar fișierele erau în general pe mașini asemănătoare Unix, iar mașinile asemănătoare Unix au nume de fișier sensibile la majuscule. Așadar, presupun că doar s-a întâmplat așa pentru confortul implementării și că nici măcar nu a fost luată în considerare utilizarea (pentru utilizatorii finali). Din nou, în primele zile utilizatorii erau oricum toți programatori Unix.

Comentarii

• Utilizatorii finali erau și utilizatori Unix (nu neapărat programatori, dar fizicieni cu energie ridicată și altele asemenea), așa că și ei erau obișnuiți cu insensibilitatea la majuscule.

Acest lucru nu are nimic de-a face cu locul în care ți-ai cumpărat domeniul, DNS nu ține cont de majuscule și minuscule. Dar sistemul de fișiere de pe serverul pe care îl utilizați pentru găzduire este.

Aceasta nu este într-adevăr o problemă și este destul de comună pe gazdele * nix. Asigurați-vă că toate linkurile pe care le scrieți pe paginile dvs. sunt corecte și că nu veți avea nicio problemă. Pentru a fi mai ușor, vă recomand să denumiți întotdeauna paginile cu majuscule, atunci nu trebuie să verificați niciodată numele atunci când scrieți un link.

Closetnoc are dreptate în ceea ce privește sistemul de operare. Unele sisteme de fișiere tratează același nume cu carcase diferite ca fișiere diferite.

De asemenea, există un scop real / avantajul de a avea o adresă URL sensibilă la majuscule (spre deosebire de marea majoritate a adreselor URL care indică aceeași pagină indiferent de importanță) majuscule)?

Da. pentru a evita dublarea problemelor de conținut.

Dacă ați avea, de exemplu, următoarele adrese 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 

și toți au indicat exact aceeași pagină cu același conținut exact, atunci veți avea conținut duplicat și sunt sigur dacă aveți o consolă de căutare Google (instrumente pentru webmasteri), Google vă va indica acest lucru.

Ceea ce vreau Aș sugera să faceți dacă vă aflați în această situație este să utilizați toate adresele URL minuscule, apoi redirecționați adresele URL cu cel puțin o literă majusculă în versiunea minusculă. Deci, în lista URL-urilor de mai sus, redirecționați toate adresele URL către prima adresă URL.

Comentarii

• ” Da. pentru a evita dublarea problemelor de conținut. ” – Dar opusul pare a fi adevărat? Faptul că adresele URL pot fi sensibile la litere mari și mici (și așa le tratează motoarele de căutare) provoacă problemele de conținut duplicat pe care le menționați. În cazul în care adresele URL ar fi universal diferențiate de majuscule și minuscule, atunci nu ar exista probleme de conținut duplicat cu majuscule și minuscule. page-1 ar fi același ca PAGE-1.
• Cred că o configurație de server slabă este ceea ce poate provoca conținut duplicat atunci când vine vorba de carcasă. De exemplu, declarația RewriteRule ^request-uri$ /targetscript.php [NC] stocată în .htaccess s-ar potrivi cu http://example.com/request-uri și http://example.com/ReQuEsT-Uri deoarece [NC] indică faptul că carcasa nu ‘ contează atunci când se evaluează acea expresie regulată.

Sensibilitatea cu majuscule are valoare.

Dacă există 26 de litere, fiecare dintre ele având capacitatea de a scrie cu majuscule, respectiv „52 de caractere.

4 caractere au posibilitatea de a combina 52 * 52 * 52 * 52 de combinații, egal cu 7311616 combinații.

Dacă nu puteți majuscula caracterele, cantitatea de combinații este 26 * 26 * 26 * 26 = 456976

Sunt de peste 14 ori mai multe combinații pentru 52 de caractere decât există pentru 26. Deci, pentru stocarea datelor, adresele URL pot fi mai scurte și mai multe informații pot fi transmise prin rețele cu mai puține date transferate.

Acesta este motivul pentru care vedeți youtube folosind adrese URL precum https://www.youtube.com/watch?v=xXxxXxxX