Varför är webbadresser skiftlägeskänsliga?

Varför skulle inte ”t URL: n är skiftlägeskänslig?

Jag förstår att det kan se ut som en provocerande (och ”djävulens förespråkare”) typ av retorisk fråga, men jag tycker att det är användbart att tänka på. Designen av HTTP är att en ”klient”, som vi ofta kallar en ”webbläsare”, frågar ”webbservern” om data.

Det finns många, många olika webbservrar som släpps. Microsoft har släppt IIS med Windows Serveroperativsystem (och andra, inklusive Windows XP Professional). Unix har tungvikter som nginx och Apache, för att inte tala om mindre erbjudanden som OpenBSD: s interna httpd, eller thttpd eller lighttpd. Dessutom har många nätverksanpassade enheter inbyggda webbservrar som kan användas för att konfigurera enheten, inklusive enheter med specifika syften för nätverk, som routrar (inklusive många Wi-Fi-åtkomstpunkter och DSL-modem) och andra enheter som skrivare eller UPS (batteristödda avbrottsfria strömförsörjningsenheter) som kan ha nätverksanslutning.

Så frågan ”Varför är webbadresser skiftlägeskänsliga?”, Frågar ”Varför behandlar webbservrarna webbadressen som att vara skiftlägeskänslig? ” Och det faktiska svaret är: de gör inte alla det. Minst en webbserver, som är ganska populär, är vanligtvis INTE skiftlägeskänslig. (Webbservern är IIS.)

En viktig anledning till olika beteenden mellan olika webbservrar beror antagligen på enkelhet. Det enkla sättet att skapa en webbserver är att göra saker på samma sätt som hur datorns / enhetens operativsystem lokaliserar filer. Många gånger hittar webbservrar en fil för att ge ett svar. Unix designades kring högre datorer, och därför tillhandahöll Unix den önskvärda funktionaliteten att tillåta stora och små bokstäver. Unix bestämde sig för att behandla stora och små bokstäver som annorlunda eftersom de, ja, de är olika. Det är den enkla, naturliga saken att göra. Windows har en historia av att vara skiftlägeskänslig på grund av en önskan att stödja redan skapad programvara, och denna historik går tillbaka till DOS som helt enkelt inte stödde små bokstäver, möjligen i ett försök för att förenkla saker med mindre kraftfulla datorer som använde mindre minne. Eftersom dessa operativsystem är olika är resultatet att enkelt utformade (tidiga versioner av) webbservrar återspeglar samma skillnader.

Nu, med allt det bakgrund, här är några specifika svar på de specifika frågorna:

När webbadresser först utformades, varför var skiftlägeskänslighet en funktion?

Varför inte? Om alla vanliga webbservrar var skiftlägeskänsliga skulle det indikera att webbservrarna följde en uppsättning regler som specificerats av standarden. Det fanns helt enkelt inget regel som säger att fallet måste ignoreras. Anledningen till att det inte finns någon regel är helt enkelt att det inte fanns någon anledning till det finns en sådan regel. Varför bry sig om att göra onödiga regler?

Jag frågar detta eftersom det verkar för mig (dvs., en lekman) att skiftlägeskänslighet skulle föredras för att förhindra onödiga fel och förenkla en redan komplicerad textsträng.

Webbadresser utformades för maskiner att bearbeta . Även om en person kan skriva in en fullständig webbadress i ett adressfält, var det inte en stor del av den avsedda designen. Den avsedda designen är att folk skulle följa (”klicka på”) hyperlänkar. Om genomsnittliga lekmän gör det, så gör de verkligen bryr dig inte om den osynliga URL: en är enkel eller komplicerad.

Finns det också ett verkligt syfte / fördel med att ha en skiftkänslig webbadress (som motsätter de allra flesta webbadresser som pekar på samma sida oavsett versaler)?

Den femte numrerade punkten för William Hays svar nämner en teknisk fördel: URL kan vara ett effektivt sätt för en webbläsare att skicka lite information till en webbserver, och mer information kan inkluderas om det finns mindre begränsningar, så en begränsning av fallkänslighet skulle minska hur mycket information som kan inkluderas.

I många fall finns det dock inte en övertygande fördel med fallkänslighet, vilket är bevisat av det faktum att IIS vanligtvis inte bryr sig om det.

Sammanfattningsvis är den mest övertygande orsaken sannolikt bara enkelhet för dem som designade webbserverprogramvaran, särskilt på en skiftlägeskänslig plattform som Unix . (HTTP var inte något som påverkade Unix ursprungliga design, eftersom Unix är särskilt äldre än HTTP.)

Kommentarer

• ” En viktig orsak till olika beteenden mellan olika webbläsare beror antagligen på en enkelhet. ” – Jag antar att du menar ” webbservrar ”, snarare än ” webbläsare ” här och på ett par andra platser?
• Uppdaterat. Granskade alla fall av ” webbläsare ” och gjort flera ersättningar. Tack för att ni påpekade detta så att en del kvalitet kunde förbättras.
• Jag har fått flera utmärkta svar på min fråga, allt från historiska till Det tekniska. Jag tvekar att gå emot spannet och acceptera ett svar med lägre betyg, men @TOOGAM ’ svaret var det mest användbara för mig. Detta svar är grundligt och omfattande men ändå förklarar konceptet på ett okomplicerat, konversationsmässigt sätt som jag kan förstå. Och jag tycker att det här svaret är en bra introduktion till de mer fördjupade förklaringarna.
• Anledningen till att Windows har ett skiftlägeskänsligt filsystem beror på det ’ s DOS-arv. MS-DOS började sitt liv på datorer som Tandy TRS-80, som använde en TV som skärm och ursprungligen inte stödde små bokstäver på grund av bristande upplösning. Eftersom den inte kunde ’ t visa små bokstäver stöddes inte gemener ’. MS-DOS licensierades av IBM för att bli den ursprungliga PC-DOS. Medan den ursprungliga datorn kunde visa små bokstäver, överfördes filsystemet som det var från MS-DOS.

URL: er är inte skiftlägeskänsliga, bara delar av dem.
Ingenting är till exempel skiftlägeskänsligt i webbadressen https://google.com,

Med hänvisning till RFC 3986 – Uniform Resource Identifier (URI): Generic Syntax

Först från Wikipedia , en URL ser ut som:

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

(Jag har tagit bort user:password del eftersom det inte är intressant och sällan används)

• scheme :

-scheman är skiftlägeskänsliga

• host :

Värdunderkomponenten är skiftlägeskänslig.

• path :

Sökvägskomponenten innehåller data …

• query :

Frågekomponenten innehåller icke-hierarkiska data …

• fragment :

Enskilda mediatyper kan definiera sina egna begränsningar eller strukturer inom fragmentidentifieringssyntaxen för att specificera olika typer av underuppsättningar, vyer eller externa referenser

Så, scheme och host är skiftlägeskänsliga.
Resten av webbadressen är skiftlägeskänslig.

Varför är path skiftlägeskänslig?

Detta verkar vara huvudfrågan.
Det är svårt att svara ”varför” något gjordes om det inte dokumenterades, men vi kan göra en mycket bra gissning.
Jag har plockat mycket specifika citat från specifikationen, med betoning på data .
Låt oss titta på webbadressen igen:

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

• Plats – Platsen har en kanonisk form och är skiftlägeskänslig. Varför? Förmodligen så att du kan köpa ett domännamn utan att behöva köpa tusentals varianter.

• Data – data används som används av målservern, och applikationen kan välja vad det betyder . Det skulle inte vara meningsfullt att göra dataläget okänsligt. Applikationen borde ha fler alternativ och att definiera skiftlägeskänslighet i specifikationen kommer att begränsa dessa alternativ.
  Detta är också en användbar åtskillnad för HTTPS: data är krypterade , men värden är synlig.

Är det användbart?

Fall- känslighet har sina fallgropar när det gäller cachning och kanoniska webbadresser, men det är verkligen användbart. Några exempel:

• Base64 , som används i Data URI: er .
• Webbplatser kan koda Base64-data i webbadressen, till exempel: http://tryroslyn.azurewebsites.net/#f:r/A4VwRgNglgxgBDCBDAziuBhOBvGB7AOxQBc4SAnKAgczLgF44AiAUQPwBMBTDuKuYgAsucAKoAlADIBCJgG4AvkA
• URL-förkortare använder skiftlägeskänslighet: /a5B kan vara annorlunda än /a5b
• Som du nämnde kan Wikipedia skilja ”AIDS” från ”Aids”.

Kommentarer

• ” URL: er är inte cas e-känslig. ” / ” Resten av webbadressen är skiftlägeskänslig. ” – Detta verkar vara en motsägelse?
• I själva verket definierar schemat vad man kan förvänta sig i resten av webbadressen. http: och relaterade scheman betyder att webbadressen hänvisar till ett DNS-värdnamn. DNS var ASCII skiftlägeskänsligt långt före uppfinningen av webbadresser. Se sida 55 i ietf.org/rfc/rfc883.txt
• Snyggt detaljerat! Jag gick från en historisk synvinkel. Det var ursprungligen filvägen som endast krävde att vara skiftlägeskänslig om du träffade filsystemet. Annars var det inte. Men idag har saker och ting förändrats. Till exempel existerade inte parametrar och CGI ursprungligen. Ditt svar tar ett aktuellt dagsperspektiv. Jag var tvungen att belöna dina ansträngningar !! Du grävde verkligen in på den här! Vem visste att detta skulle sprängas som det gjorde ?? Skål !!
• @ w3dk: det ’ är en inte särskilt intressant terminologi, men du kan ta ” skiftlägeskänslig ” för att betyda, ” att ändra fallet med ett tecken kan ändra hela ”, eller så kan du säga att ” att ändra bokstaven för ett tecken alltid ändrar hela ”. Kobi verkar hävda det senare, han föredrar att skiftlägeskänsliga borde betyda ” varje förändring i fall är betydande ” gäller inte webbadresser. Du föredrar det förra. Det ’ är bara en fråga om hur känsliga de är för skiftläge.
• @ rybo111: Om en användare skriver exempel.com/fOObaR , specifikationen kräver att servern på www.example.com får en sökväg ” / fOObaR ” som angivet; det är tyst om frågan om servern måste behandla det på något annat sätt än ” / foOBaR ”.

Enkelt. Operativsystemet är skiftlägeskänsligt. Webbservrar bryr sig i allmänhet inte om de inte måste träffa filsystemet någon gång. Det är här Linux och andra Unix-baserade operativsystem tillämpar filsystemets regler, i vilket fall känslighet är en viktig del. Det är därför IIS aldrig har varit skiftlägeskänslig; eftersom Windows aldrig var skiftlägeskänsligt.

[Uppdatering]

Det har funnits några starka argument i kommentarerna (sedan borttagna) om huruvida webbadresser har något samband med filsystemet som jag har sagt. Dessa argument har blivit heta. Det är extremt kortsynt att tro att det inte finns ett förhållande. Det finns absolut! Låt mig förklara ytterligare.

Applikationsprogrammerare är vanligtvis inte systemintern programmerare. Jag är inte förolämpande. De är två separata discipliner och systemintern kunskap krävs inte för att skriva applikationer när applikationer helt enkelt kan ringa samtal till operativsystemet. Eftersom applikationsprogrammerare inte är systeminterna programmerare är det inte möjligt att kringgå OS-tjänsterna.Jag säger detta eftersom det här är två separata läger och de sällan passerar över. Applikationer skrivs för att använda OS-tjänster som regel. Det finns naturligtvis sällsynta undantag.

Tillbaka när webbservrar började visas, försökte applikationsutvecklare inte kringgå OS-tjänster. Det fanns flera orsaker till detta. En, det var inte nödvändigt. Två, applikationsprogrammerare visste vanligtvis inte hur man skulle kringgå OS-tjänster. Tre, de flesta operativsystem var antingen extremt stabila och robusta eller extremt enkla och lätta och inte värda kostnaden.

Tänk på att de tidiga webbservrarna antingen körde på dyra datorer som DEC VAX / VMS-servrar och dagens Unix (Berkeley och Ultrix liksom andra) på datorer i huvud- eller mellanramar, sedan kort därefter på lätta datorer som datorer och Windows 3.1. När mer moderna sökmotorer började dyka upp, som Google 1997/8, hade Windows flyttat in i Windows NT och andra operativsystem som Novell och Linux hade också börjat köra webbservrar. Apache var den dominerande webbservern men det fanns andra som IIS och O ”Reilly som också var mycket populära. Ingen av dem kringgick OS-tjänster vid den tiden. Det är troligt att ingen av webbservrarna gör det ens idag.

Tidiga webbservrar var ganska enkla. De är fortfarande idag. Varje begäran om en resurs via en HTTP-begäran som finns på en hårddisk gjordes / görs av webbservern via OS-filsystemet.

Filsystem är ganska enkla mekanismer. Eftersom en begäran görs om åtkomst till en fil, om filen finns, skickas begäran till auktoriseringsundersystemet och om den beviljas uppfylls den ursprungliga begäran. existerar inte eller är inte auktoriserat, ett undantag kastas av systemet. När en applikation gör en begäran ställs en utlösare in och applikationen väntar. När begäran besvaras kastas utlösaren och applikationen bearbetar begäran. fungerar fortfarande så idag. Om applikationen ser att begäran har varit s förblir det fortsätter, om det misslyckas, kör applikationen ett felvillkor i sin kod eller dör om det inte hanteras. Enkelt.

När det gäller en webbserver, förutsatt att en URL-begäran om en sökväg / fil görs, tar webbservern sökvägen / fildelen av URL-begäran (URI) och gör en begäran till filsystemet och det är antingen nöjt eller ger ett undantag. Webbservern behandlar sedan svaret. Om till exempel sökvägen och filen hittas och åtkomst beviljas av auktoriseringsundersystemet, behandlar webbservern den I / O-begäran som normalt. Om filsystemet ger ett undantag returnerar webbservern ett 404-fel om filen inte hittas eller en 403 förbjuden om orsakskoden är obehörig.

Eftersom vissa operativsystem är skiftlägeskänsliga och filsystem den här typen kräver exakta matchningar, sökvägen / filen som begärs av webbservern måste matcha exakt vad som finns på hårddisken. Anledningen till detta är enkel. Webbservrar gissar inte vad du menar. Ingen dator gör det utan att vara programmerat till. Webbservrar behandlar helt enkelt förfrågningar när de tar emot dem. Om sökvägen / fildelen av URL-begäran som skickas direkt till filsystemet inte matchar vad som finns på hårddisken, kastar filsystemet ett undantag och webbservern returnerar ett 404-fel hittades inte.

Det är verkligen så enkla människor. Det är inte raketvetenskap. Det finns ett absolut samband mellan sökvägen / fildelen av en URL och filsystemet.

Kommentarer

• Jag tror att ditt argument är felaktigt. Medan Berners-Lee inte ’ inte hade något val om fallkänsligheten för ftp-URL: er. Han måste designa http-URL: er. Han kunde ha specificerat dem endast som US-ASCII och skiftlägeskänsliga. Om det någonsin fanns några webbservrar som precis skickade URL-sökvägen till filsystemet var de osäkra och införandet av URL-kodning bröt kompatibiliteten med dem. Med tanke på att sökvägen behandlas innan överlämnande till OS-smashing-fallet skulle ha varit lätt att implementera. Därför tror jag att vi måste betrakta detta som ett designbeslut, inte som en implementeringsegenskap.
• @WilliamHay Detta har ingenting att göra med Berners-Lee eller utformningen av webben. Det handlar om begränsningar och krav för operativsystemet. Jag är pensionerad systemingenjör. Jag arbetade med dessa system vid den tiden. Jag berättar exakt varför webbadresser är skiftlägeskänsliga. Det är ingen gissning. Det är inte en åsikt. Det är fakta. Mitt svar var avsiktligt förenklat. Naturligtvis finns det filkontroller och andra processer som kan göras innan ett öppet uttalande ges ut. Och Ja (!) Webbservrar är fortfarande osäkra än i dag som ett resultat.
• Huruvida webbadresser är skiftlägeskänsliga har inget att göra med webbens design? Verkligen? Argument från myndighet följt av argument av påstående.Att webbservrar skickar sökvägskomponenten i en URL mer eller mindre direkt till ett öppet samtal är en konsekvens av att webbadresserna inte är orsaken till det. Servrar (eller smarta klienter i fallet med FTP) kunde ha dolt fallkänsligheten för filsystem från användaren. Att de inte ’ t är ett designbeslut.
• @WilliamHay Du måste sakta ner gräshopparen och läsa om vad jag har skrivit. Jag är en pensionerad systemintern ingenjör som skriver OS-komponenter, protokollstackar och routerkod för ARPA-Net, etc. Jag arbetade med Apache, O ’ Reilly och IIS internals. Ditt FTP-argument håller inte vatten eftersom åtminstone de stora FTP-servrarna förblir skiftlägeskänsliga av samma anledning. Inte vid något tillfälle sa jag något om design av URL / URI. Inte vid något tillfälle sa jag att webbservrar skickade värden utan bearbetning. Jag sa att OS-tjänster ofta används och att filsystemet kräver en exakt matchning för att lyckas.
• @WilliamHay Förstå att du och jag tänker tvärsöver. Allt jag sa i mitt svar är att för vissa operativsystem är filsystemsamtal skiftlägeskänsliga av design. Applikationer som använder systemanrop, och de flesta gör, är begränsade till tillämpningen av OS-reglerna – i det här fallet skiftlägeskänslighet. Det är inte omöjligt att kringgå denna regel. I själva verket kan detta vara lite trivialt i vissa fall men inte praktiskt. Jag brukade rutinmässigt kringgå filsystemet i mitt arbete för att avkoda hårddiskar som gick kablooie av en eller annan anledning eller för att analysera internt i databasfiler etc.

1. URL-adresser hävdar att de är en UNIFORM Resource Locator och kan peka på resurser som föregår webben. En del av dessa är skiftlägeskänsliga (t.ex. många ftp-servrar) och webbadresser måste kunna representera dessa resurser på ett rimligt intuitivt sätt.

2. Fallkänslighet kräver mer arbete när man letar efter en matchning (antingen i operativsystemet eller ovanför det).

3. Om du definierar webbadresser som skiftlägeskänsliga kan enskilda servrar implementera dem som skiftlägeskänsliga om de vill. Det omvända är inte sant.

4. Fallkänslighet kan vara trivialt i internationella sammanhang: https://en.wikipedia.org/wiki/Dotted_and_dotless_I . RFC1738 tillät också användning av tecken utanför ASCII-intervallet förutsatt att de var kodade men inte angav en teckenuppsättning. Detta är ganska viktigt för något som kallar sig WORLD wide web. Att definiera webbadresser som skiftlägeskänsliga skulle öppna mycket utrymme för buggar.

5. Om du försöker packa mycket data i en URI (t.ex. en Data URI ) Du kan packa mer om stora och små bokstäver är olika.

Kommentarer

• I ’ jag är ganska säker på att webbadresser historiskt sett var begränsade till ASCII. Så internationalisering är sannolikt inte en original anledning. Historien om att Unix var skiftlägeskänslig, OTOH, spelade förmodligen en enorm roll.
• Medan endast en delmängd av ASCII kan användas okodad i en URL anger RFC1738 specifikt att tecken utanför ASCII-intervallet kan användas kodade. Utan att ange ett tecken är det inte ’ det är inte möjligt att veta vilka oktetter representerar samma röding handling utom för fall. Uppdaterad.
• Re # 4: Det ’ är faktiskt värre än så. Prickad och pricklös är jag en demonstration av den mer allmänna principen att, även om allt är UTF-8 (eller någon annan UTF), kan du inte använda stora eller små bokstäver korrekt utan att känna till det språk som texten hör till . I standardinställningen sänker en stor latinsk bokstav I till en liten latinsk bokstav i, vilket är fel på turkiska eftersom det lägger till en punkt (det finns ingen ” Turkisk huvudstad punktlös I ” kodpunkt; du ’ är avsedd att använda ASCII-kodpunkten). Kasta in kodningsskillnader, och det går från ” riktigt svårt ” till ” helt otrevligt . ”

Jag stal en blogg från bloggen Old New Thing vana att närma sig frågor i formen ”varför är det något som är fallet?” med motfrågan ”hur skulle världen vara, om det inte vore fallet?”

Säg att jag skapade en webbserver för att själv skicka mina dokumentfiler från en mapp så att jag kunde läsa dem på telefonen när jag var ute på kontoret. Nu har jag i min dokumentmapp tre filer, todo.txt, ToDo.txt och TODO.TXT (Jag vet, men det var vettigt för mig när jag skapade filerna).

Vilken webbadress vill jag kunna använda för att komma åt dessa filer? Jag vill komma åt dem på ett intuitivt sätt med http://www.example.com/docs/filename.

Säg att jag har ett skript som låter mig lägga till en kontakt i min adressbok, som jag kan gör det också via webben.Hur ska det ta dess parametrar? Tja, jag skulle vilja använda den som: http://www.example.com/addcontact.php?name=Tom McHenry von der O"Reilly. Men om det inte fanns något sätt för mig att specificera namnet för fall, hur skulle jag göra det?

Hur skulle jag skilja på wikisidorna för Cat och CAT, Text och TEXT, latex och LaTeX? Mycket små sidor antar jag, men jag föredrar att bara få det jag bad om.

Men allt som känns gillar att det svarar på fel fråga, hur som helst.

Frågan som jag tror att du verkligen ställde är ”Varför gör webbservrar 404 dig bara för en skillnad i fall, när de är datorer, utformade för att göra livet enklare , och de är helt kapabla att hitta åtminstone de mest uppenbara fallvariationerna i webbadressen som jag skrev som skulle fungera? ”

Svaret på är att medan vissa webbplatser har gjort detta (och bättre, de kolla efter andra stavfel också), tyckte ingen att det är värt att ändra en webbservers 404-felsida för att göra det … men kanske borde de göra det?

Kommentarer

• Vissa webbplatser använder någon form av mekanism för att konvertera en ny fråga till alla gemener eller något konsekvent. På ett sätt är det smart.
• Nej, de borde inte ’ t. Denna funktionalitet kan läggas till och läggs ofta till när det är önskvärt (t.ex. av moduler i apache.) Att införa denna typ av förändring som standardbeteende – eller värre, oföränderligt beteende – skulle vara mer störande än det relativt sällsynta tillfälle där någon måste skriva in en webbadress manuellt bortom värdnamnet. För ett bra exempel på varför inte göra det, kom ihåg fiaskot när nätverkslösningar ” fixade ” obefintliga domänfel från offentliga DNS frågor.
• @SirNickity Ingen föreslog oföränderlighet på någon nivå och webserverfelsidor kan konfigureras på varje webbserver jag ’ någonsin har använt; ingen föreslog att 404 skulle ersättas med 30 * -koder utan snarare att lägga till en lista med förslagslänkar som kan klickas på människor till felsidan; domännamn är ett mycket annorlunda ämne och är skiftlägeskänsligt och i ett annat säkerhetskontext; och IIS fixar redan ” ” (genom att ignorera) fallskillnader i sökvägen eller filnamnens delar av URI: er.
• Sedan 1996 har Apache låtit dig göra detta med mod_speling . Det verkar bara som att ’ inte är en mycket populär sak att göra. Unix / Linux-personer ser fallkänslighet som regel, fallkänslighet är undantaget.

Även om ovanstående svar är korrekt & bra. Jag skulle vilja lägga till några fler poäng.

För att förstå bättre bör man förstå den grundläggande skillnaden mellan Unix (Linux) och Windows-servern. Unix är skiftlägeskänsligt & Windows är inte skiftlägeskänsligt operativsystem.

HTTP-protokollet utvecklades eller började implementeras runt 1990. HTTP-protokollet designades av ingenjörer som arbetar på CERN-institut, de flesta av dessa dagar använde forskare Unix-maskiner och inte Windows.

De flesta vetenskapsmän kände till Unix, så de kan ha påverkats av Unix-filsystem.

Windows-servern släpptes efter 2000. mycket innan Windows-servern blev populärt HTTP-protokollet var väl mognat och specifikationen var komplett.

Detta kan vara orsaken.

Kommentarer

• ” Windows-servern släpptes efter 2000. ” Windows NT 3.1 teamet skulle ha varit oense med dig 1993. NT 3.51 1995 var förmodligen när NT började bli mogna och tillräckligt väletablerade för att stödja affärskritiska serverapplikationer.
• NT 3.51 hade Win 3.1-gränssnittet. Windows startade inte riktigt förrän i Windows 95 och det tog NT 4.0 att få samma gränssnitt.
• Michael Kj ö rling, instämde. Låt mig ändra det.
• @Thorbj ø rnRavnAndersen På servermarknaden var NT 3.51 ganska framgångsrik. På konsument- / kundmarknaden tog det fram till Windows 2000 (NT 5.0) innan NT-linjen började få allvarlig dragkraft.
• WorldWideWeb utvecklades faktiskt ursprungligen på Unix-baserade system som har skiftlägeskänsliga filsystem och de flesta webbadresser mappade direkt till filer i filsystemet.

Hur ska man läsa en ”varför var den utformad så?” fråga? Frågar du efter en historiskt korrekt redogörelse för beslutsprocessen, eller frågar du ”varför skulle någon utforma det så?”?

Det är mycket sällan möjligt att få en historiskt korrekt konto.Ibland när beslut fattas i standardkommittéer finns det ett dokument om hur debatten fördes, men i början av webben fattades beslut snabbt av några få individer – i detta fall förmodligen av TimBL själv – och motivet är osannolikt att ha skrivits ner. Men TimBL har medgett att han gjorde misstag i utformningen av webbadresser – se http://www.dailymail.co.uk/sciencetech/article-1220286/Sir-Tim-Berners-Lee-admits-forward-slashes-web-address-mistake.html

I de tidiga dagarna mappades webbadresser mycket direkt till filnamn, och filerna fanns i allmänhet på Unix-liknande maskiner och Unix-liknande maskiner har skiftlägeskänsliga filnamn. Så min gissning är att det bara hände så för implementeringsbekvämlighet, och användbarhet (för slutanvändare) övervägdes aldrig ens. I början var alla användare alla Unix-programmerare ändå.

Kommentarer

• Slutanvändare var också Unix-användare (inte nödvändigtvis programmerare, men högenergifysiker och liknande), så de var också vana vid skiftlägeskänslighet.

Detta har inget att göra med var du köpte din domän, DNS är inte skiftlägeskänsligt. Men filsystemet på servern du använder för hosting är.

Det här är inte riktigt ett problem och det är ganska vanligt på * nix-värdar. Se bara till att alla länkar du skriver på dina sidor är korrekta och att du inte har något problem. För att göra det enklare rekommenderar jag att du alltid namnger dina sidor med små bokstäver, du behöver aldrig dubbelkontrollera namnet när du skriver en länk.

Closetnoc är rätt om operativsystemet. Vissa filsystem behandlar samma namn med olika höljen som olika filer.

Finns det också ett verkligt syfte / fördel med att ha en skiftlägeskänslig URL (i motsats till de allra flesta webbadresser som pekar på samma sida oavsett kapitalisering)?

Ja. för att undvika dubbletter av innehållsproblem.

Om du till exempel hade följande webbadresser:

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 

och de pekade alla på exakt samma sida med exakt samma innehåll, då skulle du ha duplicerat innehåll, och jag är säker på om du har en Googles sökkonsol (webbmästarverktyg) -kontot, Google kommer att ange detta för dig.

Vad jag vill Jag föreslår att du gör om du befinner dig i den situationen är att använda alla gemener-webbadresser och omdirigerar sedan webbadresserna med minst en stor bokstav i den till gemener. Så i listan över webbadresser ovan omdirigerar du alla webbadresser till den första webbadressen.

Kommentarer

• ” Ja. för att undvika dubbletter av innehållsproblem. ” – Men det motsatta verkar vara sant? Det faktum att webbadresser kan vara skiftlägeskänsliga (och det är så sökmotorer behandlar dem) orsakar de dubbletter av innehållsproblem som du nämner. Om webbadresser var allmänt skiftlägeskänsliga skulle det inte finnas några duplicerade innehållsproblem med olika fall. page-1 skulle vara samma som PAGE-1.
• Jag tror att en dålig serverkonfiguration är det som kan orsaka duplicerat innehåll när det gäller höljet. Till exempel skulle uttalandet RewriteRule ^request-uri$ /targetscript.php [NC] lagrat i .htaccess matcha http://example.com/request-uri och http://example.com/ReQuEsT-Uri eftersom [NC] indikerar att höljet inte betyder ’ när man utvärderar ett reguljärt uttryck.

Skiftlägeskänslighet har värde.

Om det finns 26 bokstäver, var och en med kapacitet att använda stora bokstäver, är ”52 tecken.

4 tecken har möjligheten 52 * 52 * 52 * 52 kombinationer, motsvarar 7311616 kombinationer.

Om du inte kan använda stora bokstäver är antalet kombinationer 26 * 26 * 26 * 26 = 456976

De är mer än 14 gånger fler kombinationer för 52 tecken än det finns för 26. Så för lagring av data kan webbadresser vara kortare och mer information kan skickas över nätverk med mindre data överförd.

Det är därför du ser youtube med webbadresser som https://www.youtube.com/watch?v=xXxxXxxX