Hvorfor er webadresser store og små bogstaver?

Hvorfor ville ikke “t URLen er store og små bogstaver?

Jeg forstår, at det kan se ud som en provokerende (og “djævelens advokat”) type retorisk spørgsmål, men jeg synes, det er nyttigt at overveje. Designet af HTTP er at en “klient”, som vi ofte kalder en “webbrowser”, beder “webserveren” om data.

Der er mange, mange forskellige webservere, der frigives. Microsoft har frigivet IIS med Windows Serveroperativsystemer (og andre, inklusive Windows XP Professional). Unix har tungvægte som nginx og Apache, for ikke at nævne mindre tilbud som OpenBSDs interne httpd eller thttpd eller lighttpd. Derudover har mange netværkskompatible enheder indbygget webservere, der kan bruges til at konfigurere enheden, inklusive enheder med specifikke formål til netværk, som routere (inklusive mange Wi-Fi-adgangspunkter og DSL-modemer) og andre enheder som printere eller UPSer (batteristøttede afbrydelige strømforsyningsenheder), der muligvis har netværksforbindelse.

Så spørgsmålet “Hvorfor er URLer store og små bogstaver?” Spørger, “Hvorfor behandler webserverne URLen som er store og små bogstaver? ” Og det egentlige svar er: det gør de ikke alle. Mindst en webserver, som er temmelig populær, er typisk IKKE store og små bogstaver. (Webserveren er IIS.)

En vigtig årsag til forskellig adfærd mellem forskellige webservere kommer sandsynligvis ned til et spørgsmål om enkelhed. Den enkle måde at oprette en webserver på er at gøre ting på samme måde som hvordan computerens / enhedens operativsystem lokaliserer filer. Mange gange finder webservere en fil for at give et svar. Unix blev designet omkring avancerede computere, og så Unix leverede den ønskelige funktionalitet til at tillade store og små bogstaver. Unix besluttede at behandle store og små bogstaver som forskellige, fordi de er forskellige. Det er den ligefremme, naturlige ting at gøre. Windows har en historie med at være store og små bogstaver på grund af et ønske om at understøtte allerede oprettet software, og denne historie går tilbage til DOS, som simpelthen ikke understøttede små bogstaver, muligvis i et forsøg for at forenkle ting med mindre kraftfulde computere, der brugte mindre hukommelse. Da disse operativsystemer er forskellige, er resultatet, at simpelt designede (tidlige versioner af) webservere afspejler de samme forskelle.

Nu med alt det baggrund, her er nogle specifikke svar på de specifikke spørgsmål:

Når webadresser først blev designet, hvorfor blev store og små bogstaver til en funktion?

Hvorfor ikke? Hvis alle standard webservere ikke var store og små bogstaver, ville det indikere, at webserverne fulgte et sæt regler, der er specificeret af standarden. Der var simpelthen ingen regel, der siger, at sagen skal ignoreres. Årsagen til, at der ikke er nogen regel, er simpelthen, at der ikke var nogen grund til der er sådan en regel. Hvorfor gider at opfinde unødvendige regler?

Jeg spørger dette, fordi det ser ud til mig (dvs., en lægmand), at sagsfølsomhed foretrækkes for at forhindre unødvendige fejl og forenkle en allerede kompliceret tekststreng.

URLer blev designet til maskiner at behandle . Selvom en person kan skrive en fuld URL i en adresselinje, var det ikke “en vigtig del af det tilsigtede design. Det tilsigtede design er, at folk følger (” klik på “) hyperlinks. Hvis gennemsnitlige lægfolk gør det, så gør de virkelig er ligeglad med, om den usynlige URL er enkel eller kompliceret.

Er der også et reelt formål / fordel ved at have en sagsfølsom URL (som i modsætning til langt de fleste webadresser, der peger på den samme side, uanset store bogstaver)?

Det femte nummererede punkt på William Hays svar nævner en teknisk fordel: URLer kan være en effektiv måde for en webbrowser at sende lidt information til en webserver, og mere information kan medtages, hvis der er mindre begrænsninger, så en sagsfølsomhedsbegrænsning vil reducere, hvor meget information der kan medtages.

I mange tilfælde er der imidlertid ikke en super overbevisende fordel ved sagsfølsomhed, hvilket er bevist af det faktum, at IIS typisk ikke gider med det.

Sammenfattende er den mest overbevisende årsag sandsynligvis bare enkelhed for dem, der designede webserversoftwaren, især på en sagsfølsom platform som Unix . (HTTP var ikke noget, der påvirkede det originale design af Unix, da Unix især er ældre end HTTP.)

Kommentarer

• ” En vigtig årsag til forskellig opførsel mellem forskellige webbrowsere koges sandsynligvis til et spørgsmål om enkelhed. ” – Jeg antager, at du betyder ” webservere ” i stedet for ” webbrowsere ” her og et par andre steder?
• Opdateret. Gennemgået hvert tilfælde af ” browsere ” og foretog flere udskiftninger. Tak fordi du påpegede dette, så noget af kvaliteten kunne forbedres.
• Jeg har modtaget flere fremragende svar på mit spørgsmål lige fra det historiske til det tekniske. Jeg tøver med at gå imod kornet og acceptere et svar med lavere vurdering, men @TOOGAM ‘ s svar var det mest nyttige til mig. Dette svar er grundigt og omfattende, men det forklarer konceptet på en ukompliceret samtalsmåde, som jeg kan forstå. Og jeg synes, at dette svar er en god introduktion til de mere dybtgående forklaringer.
• Årsagen til, at Windows har et skiftesensitivt filsystem, skyldes det ‘ s DOS arv. MS-DOS startede livet på computere som Tandy TRS-80, der brugte et tv som skærm, og understøttede oprindeligt ikke små bogstaver på grund af den manglende opløsning. Da det ikke kunne ‘ t vise små bogstaver, understøttedes ikke store bogstaver ‘. MS-DOS fik licens fra IBM til at blive den originale PC-DOS. Mens den originale pc kunne vise små bogstaver, blev filsystemet porteret som det er fra MS-DOS.

URLer er ikke store og små bogstaver, kun dele af dem.
Intet er f.eks. ikke store og små bogstaver i URLen https://google.com,

Med henvisning til RFC 3986 – Uniform Resource Identifier (URI): Generisk syntaks

Først fra Wikipedia , en URL ser ud som:

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

(Jeg har fjernet user:password del, fordi det ikke er interessant og sjældent brugt)

• scheme :

ordninger er store og små bogstaver

• host :

Værtsunderkomponenten er ufølsom over for store og små bogstaver.

• path :

Stykomponenten indeholder data …

• query :

Forespørgselskomponenten indeholder ikke-hierarkiske data …

• fragment :

Individuelle medietyper kan definere deres egne begrænsninger på eller strukturer inden for fragmentidentifikatorens syntaks til at specificere forskellige typer undergrupper, visninger eller eksterne referencer

Så scheme og host er ikke store og små bogstaver.
Resten af URLen er store og små bogstaver.

Hvorfor er path store og små bogstaver?

Dette ser ud til at være hovedspørgsmålet.
Det er vanskeligt at besvare “hvorfor” noget blev gjort, hvis det ikke var dokumenteret, men vi kan komme med et meget godt gæt.
Jeg har plukket meget specifikke citater fra specifikationen med vægt på data .
Lad os se på URLen igen:

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

• Placering – Placeringen har en kanonisk form og skelner ikke mellem store og små bogstaver. Hvorfor? Sandsynligvis så du kunne købe et domænenavn uden at skulle købe tusindvis af varianter.

• Data – dataene bruges af målserver, og applikationen kan vælge, hvad det betyder . Det ville ikke give nogen mening at gøre data store og små bogstaver. Applikationen burde have flere muligheder, og at definere store og små bogstaver i specifikationen vil begrænse disse muligheder.
  Dette er også en nyttig skelnen for HTTPS: dataene er krypteret , men værten er synlig.

Er det nyttigt?

Sag- følsomhed har sine faldgruber, når det kommer til caching og kanoniske webadresser, men det er bestemt nyttigt. Nogle eksempler:

• Base64 , som bruges i Data URIer .
• Websteder kan kode Base64-data i url, for eksempel: http://tryroslyn.azurewebsites.net/#f:r/A4VwRgNglgxgBDCBDAziuBhOBvGB7AOxQBc4SAnKAgczLgF44AiAUQPwBMBTDuKuYgAsucAKoAlADIBCJgG4AvkA
• URL-forkortere bruger store og små bogstaver: /a5B kan være anderledes end /a5b
• Som du har nævnt, kan Wikipedia skelne “AIDS” fra “Aids”.

Kommentarer

• ” URLer er ikke cas e-følsom. ” / ” Resten af webadressen er store og små bogstaver. ” – Dette ser ud til at være en modsigelse?
• I virkeligheden definerer ordningen, hvad man kan forvente i resten af URLen. http: og relaterede ordninger betyder, at URLen henviser til et DNS-værtsnavn. DNS var ASCII-ufølsom over for store bogstaver længe før opfindelsen af webadresser. Se side 55 i ietf.org/rfc/rfc883.txt
• Pænt detaljeret! Jeg gik fra et historisk synspunkt. Det var oprindeligt filstien, der kun krævede, at der skulle være store og små bogstaver, hvis du ramte filsystemet. Ellers var det ikke. Men i dag har tingene ændret sig. For eksempel eksisterede parametre og CGI ikke oprindeligt. Dit svar tager et dags perspektiv. Jeg var nødt til at belønne din indsats !! Du gravede virkelig ind på denne! Hvem vidste, at dette ville sprænge som det gjorde ?? Skål !!
• @ w3dk: det ‘ er en ikke-meget interessant terminologi, men du kan tage ” store og små bogstaver ” for at betyde, ” ændring af store og små bogstaver kan ændre hele “, eller du kan forstå det, at ” at ændre tilfældet med et tegn altid ændrer hele “. Kobi ser ud til at hævde sidstnævnte, han foretrækker, at store og små bogstaver bør betyde ” enhver ændring i sagen er signifikant “, hvilket naturligvis gælder ikke for webadresser. Du foretrækker førstnævnte. Det ‘ er bare et spørgsmål om hvor følsomme de er over for store og små bogstaver.
• @ rybo111: Hvis en bruger skriver eksempel.com/fOObaR , spec kræver, at serveren på www.example.com modtager en sti ” / fOObaR ” som angivet; det er stille om spørgsmålet om, hvorvidt serveren skal behandle det anderledes end ” / foOBaR “.

Simple. Operativsystemet er store og små bogstaver. Webservere er generelt ligeglad, medmindre de er nødt til at ramme filsystemet på et eller andet tidspunkt. Det er her Linux og andre Unix-baserede operativsystemer håndhæver filsystemets regler, i hvilket tilfælde følsomhed er en vigtig del. Dette er grunden til, at IIS aldrig har været store og små bogstaver; fordi Windows aldrig var store og små bogstaver.

[Opdater]

Der har været nogle stærke argumenter i kommentarerne (siden de blev slettet) om, hvorvidt webadresser har noget forhold til filsystemet, som jeg har sagt. Disse argumenter er blevet opvarmede. Det er ekstremt kortsynt at tro, at der ikke er et forhold. Der er absolut! Lad mig forklare yderligere.

Applikationsprogrammerere er normalt ikke systeminterne programmerere. Jeg fornærmer ikke. De er to separate discipliner, og systemintern viden er ikke påkrævet for at skrive applikationer, når applikationer simpelthen kan foretage opkald til operativsystemet. Da applikationsprogrammerere ikke er systeminterne programmerere, er det ikke muligt at omgå OS-tjenesterne.Jeg siger dette, fordi dette er to separate lejre, og de krydser sjældent. Applikationer er skrevet for at bruge OS-tjenester som regel. Der er naturligvis sjældne nogle undtagelser.

Tilbage da webservere begyndte at vises, forsøgte applikationsudviklere ikke at omgå OS-tjenester. Der var flere grunde til dette. En, det var ikke nødvendigt. To, applikationsprogrammerere vidste generelt ikke, hvordan man omgå OS-tjenester. Tre, de fleste operativsystemer var enten ekstremt stabile og robuste eller ekstremt enkle og lette og ikke omkostningerne værd.

Husk, at de tidlige webservere enten kørte på dyre computere som DEC VAX / VMS-servere og Unix of the Day (Berkeley og Ultrix såvel som andre) på main-frame eller mid-frame computere, derefter kort efter på lette computere som pcer og Windows 3.1. Da mere moderne søgemaskiner begyndte at dukke op, såsom Google i 1997/8, var Windows flyttet ind i Windows NT, og andre operativsystemer som Novell og Linux var også begyndt at køre webservere. Apache var den dominerende webserver, selvom der var andre som IIS og O “Reilly, som også var meget populære. Ingen af dem omgåede på det tidspunkt OS-tjenester. Det er sandsynligt, at ingen af webserverne gør det selv i dag.

Tidlige webservere var ret enkle. De er stadig i dag. Enhver anmodning, der blev fremsat om en ressource via en HTTP-anmodning, der findes på en harddisk, blev / foretages af webserveren via OS-filsystemet.

Filsystemer er ret enkle mekanismer. Da der fremsættes en anmodning om adgang til en fil, sendes anmodningen til autorisationsundersystemet, hvis den findes, og hvis den imødekommes, imødekommes den oprindelige anmodning. ikke findes eller ikke er autoriseret, kastes en undtagelse af systemet. Når en applikation fremsætter en anmodning, indstilles en trigger, og applikationen venter. Når anmodningen besvares, kastes triggeren, og applikationen behandler anmodningen. fungerer stadig sådan i dag. Hvis applikationen ser, at anmodningen er blevet s atisfied fortsætter det, hvis det mislykkes, udfører applikationen en fejltilstand i sin kode eller dør, hvis den ikke håndteres. Enkel.

I tilfælde af en webserver, forudsat at der foretages en URL-anmodning om en sti / fil, tager webserveren stien / fildelen af URL-anmodningen (URI) og fremsætter en anmodning til filsystemet, og det er enten tilfreds eller kaster en undtagelse. Webserveren behandler derefter svaret. Hvis f.eks. Den ønskede sti og fil findes, og adgangen gives af autorisationsundersystemet, behandler webserveren den I / O-anmodning som normalt. Hvis filsystemet kaster en undtagelse, returnerer webserveren en 404-fejl, hvis filen ikke findes eller en 403 forbudt, hvis årsagskoden er uautoriseret.

Da nogle operativsystemer er store og små bogstaver og filsystemer af denne type kræver nøjagtige matches, den sti / fil, der kræves af webserveren, skal matche det, der findes på harddisken nøjagtigt. Årsagen til dette er enkel. Webservere gætter ikke hvad du mener. Ingen computere gør det uden at være programmeret til. Webservere behandler simpelthen anmodninger, når de modtager dem. Hvis stien / fildelen af URL-anmodningen, der sendes direkte til filsystemet, ikke stemmer overens med det, der er på harddisken, kaster filsystemet en undtagelse, og webserveren returnerer en 404 Not Found-fejl.

Det er virkelig så enkle folk. Det er ikke raketvidenskab. Der er en absolut sammenhæng mellem stien / fildelen af en URL og filsystemet.

Kommentarer

• Jeg synes, at dit argument er mangelfuldt. Mens Berners-Lee ikke havde ‘ t noget valg om sagsfølsomhed for ftp-URLer. Han skulle designe http URLer. Han kunne have specificeret dem som kun US-ASCII og ikke store og små bogstaver. Hvis der nogensinde var webservere, der netop sendte URL-stien til filsystemet, var de usikre, og indførelsen af URL-kodning brød kompatibilitet med dem. I betragtning af at stien behandles inden aflevering til OS-smashing-sagen, ville det have været let at implementere. Derfor tror jeg, at vi er nødt til at betragte dette som en designbeslutning, ikke som en implementeringsegenskab.
• @WilliamHay Dette har intet at gøre med Berners-Lee eller webdesignet. Det handler om begrænsninger og krav til operativsystemet. Jeg er en pensioneret systemintern ingeniør. Jeg arbejdede på disse systemer på det tidspunkt. Jeg fortæller dig nøjagtigt, hvorfor webadresser er store og små. Det er ikke et gæt. Det er ikke en mening. Det er en kendsgerning. Mit svar blev bevidst forenklet. Naturligvis er der filkontrol og andre processer, der kan udføres, inden der udstedes en åben erklæring. Og ja (!) Webservere er delvist usikre stadig den dag i dag som følge heraf.
• Hvorvidt webadresser er store og små bogstaver har ikke noget at gøre med designet af internettet? Virkelig? Argument fra autoritet efterfulgt af argument ved påstand.At webservere videregiver sti-komponenten til en URL mere eller mindre direkte til et åbent opkald er en konsekvens af, at URL-design ikke er årsag til det. Servere (eller smartklienter i tilfælde af FTP) kunne have skjult sagsfølsomheden for filsystemer for brugeren. At de ikke ‘ t er en designbeslutning.
• @WilliamHay Du er nødt til at bremse græsbeholderen og læse igen, hvad jeg har skrevet. Jeg er pensioneret systemintern ingeniør, der skriver OS-komponenter, protokolstakke og routerkode til ARPA-Net osv. Jeg arbejdede med Apache, O ‘ Reilly og IIS internals. Dit FTP-argument holder ikke vand, da i det mindste de største FTP-servere forbliver store og små bogstaver af samme grund. På intet tidspunkt sagde jeg noget om design af URL / URI. På intet tidspunkt sagde jeg, at webservere overførte værdier uden behandling. Jeg sagde, at OS-tjenester ofte bruges, og at filsystemet kræver en nøjagtig matchning for at få succes.
• @WilliamHay Vær venlig at forstå, at du og jeg tænker på tværs. Alt hvad jeg sagde i mit svar er, at for nogle operativsystemer er filsystemopkald store og små bogstaver af design. Applikationer, der bruger systemopkald, og de fleste gør, er begrænset til håndhævelse af OS-reglerne – i dette tilfælde sagsfølsomhed. Det er ikke umuligt at omgå denne regel. Faktisk kan dette være noget trivielt i nogle tilfælde, men ikke praktisk. Jeg plejede rutinemæssigt at omgå filsystemet i mit arbejde for at fjerne harddiske, der blev kablooie af en eller anden grund eller til at analysere interne databasefiler osv.

1. URLer hævder at være en UNIFORM ressourcelokator og kan pege på ressourcer, der går forud for internettet. Nogle af disse er store og små bogstaver (f.eks. Mange ftp-servere), og webadresser skal være i stand til at repræsentere disse ressourcer på en rimelig intuitiv måde.

2. Sagsfølsomhed kræver mere arbejde, når man leder efter en kamp (enten i operativsystemet eller over det).

3. Hvis du definerer webadresser som store og små bogstaver, kan de enkelte servere implementere dem som store og små bogstaver, hvis de ønsker det. Det modsatte er ikke sandt.

4. Ufølsomhed i sager kan være ikke-trivielt i internationale sammenhænge: https://en.wikipedia.org/wiki/Dotted_and_dotless_I . RFC1738 tillod også brug af tegn uden for ASCII-området, forudsat at de var kodet, men ikke angav et tegnsæt. Dette er ret vigtigt for noget, der kalder sig verdensomspændende web. Definition af webadresser som store og små bogstaver ville åbne for et stort bugs.

5. Hvis du prøver at pakke en masse data i en URI (f.eks. en Data URI ) du kan pakke mere, hvis store og små bogstaver er forskellige.

Kommentarer

• I ‘ Jeg er temmelig sikker på, at webadresser historisk var begrænset til ASCII. Så internationalisering er sandsynligvis ikke en original grund. Historien om, at Unix var store og små bogstaver, OTOH, spillede sandsynligvis en enorm rolle.
• Selvom kun et undersæt af ASCII kan bruges ukodet i en URL, angiver RFC1738 specifikt tegn uden for ASCII-området, der kan bruges kodet. Uden at angive et tegnsæt er det ikke ‘ ikke muligt at vide hvilke oktetter repræsenterer den samme char handling undtagen tilfælde. Opdateret.
• Re # 4: Det ‘ er faktisk værre end det. Prikket og punktfri er jeg en demonstration af det mere generelle princip, at selvom alt er UTF-8 (eller en anden UTF), kan du ikke bruge store eller små bogstaver korrekt uden at kende det sted, hvor teksten hører til . I standardområdet er det store latinske bogstav I med små bogstaver i, hvilket er forkert på tyrkisk, fordi det tilføjer en prik (der er ingen ” Tyrkisk hovedstad punktfri I ” kodepunkt; du ‘ er beregnet til at bruge ASCII-kodepunktet). Kast kodningsforskelle, og dette går fra ” virkelig hårdt ” til ” fuldstændig uhåndterlig . ”

Jeg stjal fra bloggen en Gammel ny ting vane med at nærme sig spørgsmål til formularen “hvorfor er det noget, der er tilfældet?” med modspørgsmålet “hvordan ville verden være, hvis det ikke var tilfældet?”

Sig, at jeg oprettede en webserver til at tjene mig selv mine dokumentfiler fra en mappe, så jeg kunne læse dem videre telefonen, da jeg var ude på kontoret. Nu, i min dokumentmappe har jeg tre filer, todo.txt, ToDo.txt og TODO.TXT (Jeg ved det, men det gav mening for mig, da jeg lavede filerne).

Hvilken URL vil jeg kunne bruge til at få adgang til disse filer? Jeg vil gerne have adgang til dem på en intuitiv måde ved hjælp af http://www.example.com/docs/filename.

Sig, at jeg har et script, der lader mig tilføje en kontakt til min adressebog, som jeg kan gør det også via internettet.Hvordan skal det tage dets parametre? Nå, jeg vil gerne bruge det som: http://www.example.com/addcontact.php?name=Tom McHenry von der O"Reilly. Men hvis der ikke var nogen måde for mig at specificere navnet efter sag, hvordan ville jeg så gøre det?

Hvordan skelner jeg wiki-siderne for Cat og CAT, Text og TEXT, latex og LaTeX? Uensartede sider antager jeg, men jeg foretrækker bare at få den ting, jeg bad om.

Men alt det der føles som om det besvarer det forkerte spørgsmål alligevel.

Det spørgsmål, jeg tror, du virkelig stillede, er “Hvorfor gør webservere 404 dig bare for en sagforskel, når de er computere, designet til at gøre livet enklere , og de er perfekt i stand til at finde i det mindste de mest åbenlyse case-variationer i den URL, jeg skrev, der ville fungere? “

Svaret på det er, at mens nogle websteder har gjort dette (og bedre, de tjek for andre skrivefejl også), ingen syntes det er værd at ændre en webservers standard 404-fejlside for at gøre det … men måske skulle de gøre det?

Kommentarer

• Nogle websteder bruger en slags mekanisme til at konvertere en ny forespørgsel til alle små bogstaver eller noget konsistent. På en måde er dette smart.
• Nej, de burde ikke ‘ t. Denne funktionalitet kan tilføjes og tilføjes ofte, når det er ønskeligt (f.eks. Af moduler i apache.) At pålægge denne form for ændring som standardadfærd – eller værre, uforanderlig adfærd – ville være mere forstyrrende end den relativt sjældne lejlighed, hvor nogen skal indtaste en URL manuelt ud over værtsnavnet. For et godt eksempel på, hvorfor ikke gøre dette, skal du huske fiaskoen, når netværksløsninger ” fikserede ” ikke-eksisterende domæne fejl fra offentlig DNS forespørgsler.
• @SirNickity Ingen foreslog uforanderlighed på ethvert niveau, og webserverfejlsider kan konfigureres på hver webserver, jeg ‘ nogensinde har brugt; ingen foreslog at erstatte 404 med 30 * koder, men snarere tilføje en liste med forslag, der kunne klikes på mennesker, til fejlsiden; domænenavne er et meget andet emne og emne, der ikke skelnes mellem store og små bogstaver og i en anden sikkerhedssammenhæng; og IIS rettes allerede automatisk ” ” (ved at ignorere) sagsforskelle i stien eller filnavnet til URIer.
• Siden 1996 har Apache ladet dig gøre dette med mod_speling . Det synes bare ikke ‘ at være en meget populær ting at gøre. Unix / Linux-folk ser sagsfølsomhed som regel, sagsfølsomhed som undtagelse.

Selvom ovenstående svar er korrekt & godt. Jeg vil gerne tilføje nogle flere punkter.

For at forstå bedre skal man forstå den grundlæggende forskel mellem Unix (Linux) Vs Windows-server. Unix er store og små bogstaver & Windows er ikke store og små bogstaver.

HTTP-protokol blev udviklet eller begyndte at blive implementeret omkring 1990. HTTP-protokol blev designet af ingeniører, der arbejder på CERN-institutter brugte de fleste af disse dage Unix-maskiner og ikke Windows.

De fleste videnskabsmænd kendte Unix, så de kunne have været påvirket af Unix-filsystem.

Windows-server blev frigivet efter 2000. meget før windows-server blev populær HTTP-protokol var godt modnet, og specifikationen var komplet.

Dette kan være årsagen.

Kommentarer

• ” Windows-server blev frigivet efter 2000. ” Windows NT 3.1 teamet ville have været uenig med dig i 1993. NT 3.51 i 1995 var sandsynligvis da NT begyndte at blive moden og veletableret nok til at understøtte forretningskritiske serverapplikationer.
• NT 3.51 havde Win 3.1-grænsefladen. Windows startede ikke rigtig før i Windows 95, og det tog NT 4.0 at få den samme grænseflade.
• Michael Kj ö rling, aftalt. Lad mig ændre det.
• @Thorbj ø rnRavnAndersen På servermarkedet var NT 3.51 med rimelighed en succes. På forbruger- / prosumermarkedet tog det indtil Windows 2000 (NT 5.0), før NT-linjen begyndte at få alvorlig trækkraft.
• Faktisk blev WorldWideWeb oprindeligt udviklet på Unix-baserede systemer, som har store og små bogstaver filsystemer og de fleste URLer tilknyttet direkte til filer på filsystemet.

Hvordan skal man læse en “hvorfor blev den designet på denne måde?” spørgsmål? Beder du om en historisk nøjagtig redegørelse for beslutningsprocessen, eller spørger du “hvorfor skulle nogen designe det på denne måde?”?

Det er meget sjældent muligt at få en historisk nøjagtig konto.Nogle gange, når der træffes beslutninger i standardkomiteer, er der et dokumentationsspor for, hvordan debatten blev ført, men i de tidlige dage af webbeslutningerne blev der hurtigt taget beslutninger af nogle få personer – i dette tilfælde sandsynligvis af TimBL selv – og begrundelsen er usandsynlig at være blevet skrevet ned. Men TimBL har indrømmet, at han lavede fejl i designet af webadresser – se http://www.dailymail.co.uk/sciencetech/article-1220286/Sir-Tim-Berners-Lee-admits-forward-slashes-web-address-mistake.html

I de tidlige dage blev URLer kortlagt meget direkte til filnavne, og filerne var generelt på Unix-lignende maskiner, og Unix-lignende maskiner har store og små bogstaver. Så mit gæt er, at det netop skete på den måde for implementeringsbekvemmelighed, og brugervenlighed (for slutbrugere) blev aldrig engang overvejet. I de første dage var brugerne alligevel alle Unix-programmører.

Kommentarer

• Slutbrugere var også Unix-brugere (ikke nødvendigvis programmører, men højenergifysikere og lignende), så også de var vant til ufølsomhed i store og små bogstaver.

Dette har intet at gøre med, hvor du købte dit domæne, DNS er ikke store og små bogstaver. Men filsystemet på den server, du bruger til hosting er.

Dette er ikke et problem, og det er ret almindeligt på * nix-værter. Bare sørg for, at alle links, du skriver på dine sider, er korrekte, og at du ikke har et problem. For at gøre det lettere anbefaler jeg altid at navngive dine sider i små bogstaver, så du behøver aldrig at dobbelttjekke navnet, når du skriver et link.

Closetnoc har ret i operativsystemet. Nogle filsystemer behandler det samme navn med forskellige hylstre som forskellige filer.

Er der også et reelt formål / fordel ved at have en sagsfølsom URL (i modsætning til langt de fleste URLer, der peger på den samme side uanset store bogstaver)?

Ja. for at undgå duplikerede indholdsproblemer.

Hvis du f.eks. havde følgende webadresser:

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 

og de pegede alle på nøjagtig den samme side med nøjagtigt det samme indhold, så ville du have duplikatindhold, og jeg er sikker på, at hvis du har en Google-søgekonsol (webmaster-værktøjskonto), Google vil angive dette for dig.

Hvad jeg ville Jeg foreslår at gøre, hvis du er i den situation, er at bruge alle små og store URLer, og omdiriger derefter URLerne med mindst et stort bogstav i den til små bogstaver. Så på listen over URLer ovenfor omdirigerer du alle URLerne til den første URL.

Kommentarer

• ” Ja. for at undgå duplikerede indholdsproblemer. ” – Men det modsatte synes at være sandt? Det faktum, at webadresser kan være store og små bogstaver (og sådan behandler søgemaskiner dem) forårsager de duplikatindholdsproblemer, du nævner. Hvis webadresser generelt ikke skelner mellem store og små bogstaver, ville der ikke være duplikat med indholdsproblemer med forskellige sager. page-1 ville være det samme som PAGE-1.
• Jeg synes en dårlig serverkonfiguration er, hvad der kan forårsage duplikatindhold, når det kommer til casing. For eksempel vil udsagnet RewriteRule ^request-uri$ /targetscript.php [NC], der er gemt i .htaccess, matche http://example.com/request-uri og http://example.com/ReQuEsT-Uri fordi [NC] angiver, at kabinettet ikke betyder ‘, når man vurderer det ene regulære udtryk.

Sagsfølsomhed har værdi.

Hvis der er 26 bogstaver, som hver især har evnen til at bruge store bogstaver, er det 52 tegn.

4 tegn har muligheden 52 * 52 * 52 * 52 kombinationer, svarende til 7311616 kombinationer.

Hvis du ikke kan bruge store bogstaver, er antallet af kombinationer 26 * 26 * 26 * 26 = 456976

De er mere end 14 gange flere kombinationer for 52 tegn end der er for 26. Så til lagring af data kan webadresser være kortere, og flere oplysninger kan sendes over netværk med færre data overført.

Dette er grunden til, at du ser youtube ved hjælp af webadresser som https://www.youtube.com/watch?v=xXxxXxxX