Waarom zijn URLs hoofdlettergevoelig?

Waarom zou “t de URL hoofdlettergevoelig zijn?

Ik begrijp dat dit een provocerende (en “duivelse advocaat”) retorische vraag lijkt, maar ik denk dat het nuttig is om te overwegen. Het ontwerp van HTTP is dat een “client”, die we gewoonlijk een “webbrowser” noemen, de “webserver” om gegevens vraagt.

Er zijn veel, veel verschillende webservers die worden uitgebracht. Microsoft heeft IIS uitgebracht met Windows Serverbesturingssystemen (en andere, waaronder Windows XP Professional) Unix heeft zwaargewichten zoals nginx en Apache, om nog maar te zwijgen van kleinere aanbiedingen zoals OpenBSDs interne httpd, of thttpd, of lighttpd. Bovendien hebben veel apparaten met netwerkfunctionaliteit ingebouwde webservers die kunnen worden gebruikt om het apparaat te configureren, inclusief apparaten met netwerkspecifieke doeleinden, zoals routers (inclusief veel Wi-Fi-toegangspunten en DSL-modems) en andere apparaten zoals printers of UPSen (ononderbreekbare voedingseenheden met batterijvoeding) die mogelijk een netwerkverbinding hebben.

Dus de vraag “Waarom zijn URLs hoofdlettergevoelig?”, Is: “Waarom behandelen de webservers de URL als hoofdlettergevoelig zijn? ” En het daadwerkelijke antwoord is: dat doen ze niet allemaal. Ten minste één webserver, die redelijk populair is, is doorgaans NIET hoofdlettergevoelig. (De webserver is IIS.)

Een belangrijke reden voor Het verschillende gedrag tussen verschillende webservers komt waarschijnlijk neer op een kwestie van eenvoud De eenvoudige manier om een webserver te maken is door de dingen op dezelfde manier te doen als hoe het besturingssysteem van de computer / apparaat bestanden lokaliseert. Vaak zoeken webservers een bestand om een antwoord te geven. Unix is ontworpen rond high-end computers, en daarom bood Unix de gewenste functionaliteit om hoofdletters en kleine letters toe te staan. Unix besloot om hoofdletters en kleine letters als verschillend te behandelen omdat ze, nou ja, verschillend zijn. Dat is de eenvoudige, natuurlijke manier om te doen. Windows heeft een geschiedenis van hoofdlettergevoelig zijn vanwege de wens om reeds gemaakte software te ondersteunen, en deze geschiedenis gaat terug naar DOS, dat eenvoudig geen kleine letters ondersteunde, mogelijk in een poging om dingen te vereenvoudigen met minder krachtige computers die minder geheugen gebruikten. Aangezien deze besturingssystemen verschillend zijn, is het resultaat dat eenvoudig ontworpen (vroege versies van) webservers dezelfde verschillen vertonen.

Nu, met dat alles achtergrond, hier zijn enkele specifieke antwoorden op de specifieke vragen:

Toen URLs voor het eerst werden ontworpen, waarom was hoofdlettergevoeligheid dan een functie?

Waarom niet? Als alle standaardwebservers niet hoofdlettergevoelig waren, zou dat erop wijzen dat de webservers een reeks regels volgden die door de standaard waren gespecificeerd. Er was simpelweg geen regel die zegt dat het geval genegeerd moet worden De reden dat er geen regel is, is simpelweg dat er geen reden voor was er moet zon regel zijn. Waarom zou ik onnodige regels verzinnen?

Ik vraag dit omdat het mij lijkt (d.w.z., een leek) dat hoofdletterongevoeligheid de voorkeur zou hebben om onnodige fouten te voorkomen en een reeds gecompliceerde reeks tekst te vereenvoudigen.

URLs zijn ontworpen voor machines om te verwerken . Hoewel een persoon een volledige URL in een adresbalk kan typen, was dat niet “het grootste deel van het beoogde ontwerp. Het beoogde ontwerp is dat mensen hyperlinks volgen (” klikken op “). Als gemiddelde leken dat doen, maakt niet uit of de onzichtbare URL eenvoudig of ingewikkeld is.

Er is ook een echt doel / voordeel aan het hebben van een hoofdlettergevoelige URL (zoals in tegenstelling tot de overgrote meerderheid van URLs die naar dezelfde pagina verwijzen, ongeacht het hoofdlettergebruik)?

Het vijfde genummerde punt van Het antwoord van William Hay noemt één technisch voordeel: URLs kunnen een effectieve manier zijn voor een webbrowser om een beetje informatie naar een webserver te sturen, en er kan meer informatie worden toegevoegd als er minder is beperkingen, dus een beperking van hoofdlettergevoeligheid zou de hoeveelheid informatie die kan worden opgenomen, verminderen.

In veel gevallen is er echter geen superieur voordeel aan hoofdlettergevoeligheid, namelijk bewezen door het feit dat IIS er doorgaans geen moeite mee heeft.

Samengevat is de meest dwingende reden waarschijnlijk de eenvoud voor degenen die de webserversoftware hebben ontworpen, vooral op een hoofdlettergevoelig platform zoals Unix . (HTTP was niet iets dat het oorspronkelijke ontwerp van Unix beïnvloedde, aangezien Unix aanzienlijk ouder is dan HTTP.)

Reacties

• ” Een belangrijke reden voor verschillend gedrag tussen verschillende webbrowsers komt waarschijnlijk neer op een kwestie van eenvoud. ” – ik neem aan dat u gemiddelde ” webservers “, in plaats van ” webbrowsers ” hier en op een paar andere plaatsen?
• Bijgewerkt. Elk geval van ” browsers ” en hebben meerdere vervangingen gemaakt. Bedankt dat je hierop hebt gewezen, zodat de kwaliteit kan worden verbeterd.
• Ik heb verschillende uitstekende antwoorden op mijn vraag ontvangen, variërend van historisch tot het technische. Ik aarzel om tegen de stroom in te gaan en een antwoord met een lagere score te accepteren, maar het antwoord van @TOOGAM ‘ was het nuttigst om me. Dit antwoord is grondig en uitgebreid, maar het legt het concept op een ongecompliceerde, gemoedelijke manier uit die ik kan begrijpen. En ik denk dat dit antwoord een goede inleiding is tot de meer diepgaande uitleg.
• De reden dat Windows een niet-hoofdlettergevoelig bestandssysteem heeft, is er door ‘ s DOS-erfgoed. MS-DOS begon zijn leven op computers zoals de Tandy TRS-80, die een tv als beeldscherm gebruikte en oorspronkelijk geen kleine letters ondersteunde vanwege het gebrek aan resolutie. Omdat het ‘ t kleine letters kon weergeven, werd hoofdlettergebruik niet ‘ t ondersteund. MS-DOS kreeg een licentie van IBM om de originele PC-DOS te worden. Hoewel de originele pc kleine letters kon weergeven, werd het bestandssysteem ongewijzigd overgedragen vanuit MS-DOS.

URLs zijn niet hoofdlettergevoelig, alleen delen ervan.
Niets is bijvoorbeeld hoofdlettergevoelig in de URL https://google.com,

Met verwijzing naar RFC 3986 – Uniform Resource Identifier (URI): algemene syntaxis

Ten eerste, van Wikipedia , een URL ziet er als volgt uit:

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

(Ik heb de user:password deel omdat het niet interessant is en zelden wordt gebruikt)

• scheme :

schemas zijn niet hoofdlettergevoelig

• host :

De host-subcomponent is niet hoofdlettergevoelig.

• path :

De padcomponent bevat gegevens …

• query :

De querycomponent bevat niet-hiërarchische gegevens …

• fragment :

Individuele mediatypen kunnen hun eigen beperkingen of structuren binnen de fragment-ID-syntaxis definiëren voor het specificeren van verschillende soorten subsets, weergaven of externe verwijzingen

De scheme en host zijn dus niet hoofdlettergevoelig.
De rest van de URL is hoofdlettergevoelig.

Waarom is de path hoofdlettergevoelig?

Dit lijkt de belangrijkste vraag te zijn.
Het is moeilijk te beantwoorden “waarom” er is iets gedaan als het niet gedocumenteerd was, maar we kunnen een zeer goede gok maken.
Ik heb zeer specifieke citaten uit de specificatie gekozen, met de nadruk op data .
Laten we de URL nog eens bekijken:

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

• Locatie – De locatie heeft een canonieke vorm en is niet hoofdlettergevoelig. Waarom? Waarschijnlijk kunt u dus een domeinnaam kopen zonder duizenden varianten te hoeven kopen.

• Gegevens – de gegevens zijn gebruikt door de doelserver, en de applicatie kan kiezen wat het betekent . Het heeft geen zin om gegevens hoofdletterongevoelig te maken. De applicatie zou meer opties moeten hebben, en het definiëren van hoofdletterongevoeligheid in de specificatie zal deze opties beperken.
  Dit is ook een handig onderscheid voor HTTPS: de gegevens zijn versleuteld , maar de host is zichtbaar.

Is het nuttig?

Case- gevoeligheid heeft zijn valkuilen als het gaat om caching en canonieke URLs, maar het is zeker nuttig. Enkele voorbeelden:

• Base64 , die wordt gebruikt in Gegevens-URIs .
• Sites kunnen Base64-gegevens in de url coderen, bijvoorbeeld: http://tryroslyn.azurewebsites.net/#f:r/A4VwRgNglgxgBDCBDAziuBhOBvGB7AOxQBc4SAnKAgczLgF44AiAUQPwBMBTDuKuYgAsucAKoAlADIBCJgG4AvkA
• URL-verkorters gebruiken hoofdlettergevoeligheid: /a5B kan anders zijn dan /a5b
• Zoals je “al zei, kan Wikipedia” AIDS “onderscheiden van” Aids “.

Opmerkingen

• ” URLs zijn niet cas e-sensitive. ” / ” De rest van de URL is hoofdlettergevoelig. ” – Dit lijkt in tegenspraak te zijn?
• In werkelijkheid definieert het schema wat te verwachten in de rest van de URL. http: en gerelateerde schemas betekenen dat de URL verwijst naar een DNS-hostnaam. DNS was niet hoofdlettergevoelig ASCII lang voordat de URLs werden uitgevonden. Zie pagina 55 van ietf.org/rfc/rfc883.txt
• Mooi gedetailleerd! Ik ging vanuit historisch oogpunt. Het was oorspronkelijk het bestandspad dat alleen hoofdlettergevoelig moest zijn als u het bestandssysteem raakte. Anders was het dat niet. Maar vandaag zijn de dingen veranderd. Parameters en CGI bestonden bijvoorbeeld oorspronkelijk niet. Uw antwoord heeft een actueel perspectief. Ik moest je inspanningen belonen !! Je hebt deze echt ingegraven! Wie wist dat dit zou ontploffen zoals het deed ?? Proost !!
• @ w3dk: it ‘ is een niet erg interessante gril van terminologie, maar je zou ” hoofdlettergevoelig ” betekenen, ” het wijzigen van het hoofdlettergebruik van een teken kan de hele “, of je zou het kunnen opvatten, ” het veranderen van het hoofdlettergebruik van een teken altijd verandert het hele “. Kobi lijkt het laatste te beweren, hij geeft er de voorkeur aan dat hoofdlettergevoelig moet betekenen ” elke wijziging in het geval dat significant is “, wat natuurlijk geldt niet voor URLs. U geeft de voorkeur aan het eerste. Het ‘ is slechts een kwestie van hoe gevoelig ze zijn voor hoofdlettergebruik.
• @ rybo111: als een gebruiker example.com/fOObaR , vereist de specificatie dat de server op www.example.com een pad ” / fOObaR ” zoals opgegeven; het zwijgt over de vraag of de server dat anders moet behandelen dan ” / foOBaR “.

Eenvoudig. Het besturingssysteem is hoofdlettergevoelig. Webservers geven er over het algemeen niets om, tenzij ze op een gegeven moment het bestandssysteem moeten raken. Dit is waar Linux en andere op Unix gebaseerde besturingssystemen de regels van het bestandssysteem afdwingen, waarbij hoofdlettergevoeligheid een belangrijk onderdeel is. Dit is de reden waarom IIS nooit hoofdlettergevoelig is geweest; omdat Windows nooit hoofdlettergevoelig was.

[Update]

Er zijn enkele sterke argumenten in de commentaren (sinds ze zijn verwijderd) over de vraag of URLs een relatie hebben met het bestandssysteem zoals ik heb aangegeven. Deze argumenten zijn verhit geraakt. Het is buitengewoon kortzichtig om te geloven dat er geen relatie is. Er is absoluut! Laat me het verder uitleggen.

Applicatieprogrammeurs zijn over het algemeen geen systeeminterne programmeurs. Ik ben niet beledigend. Het zijn twee afzonderlijke disciplines en de interne kennis van het systeem is niet vereist om applicaties te schrijven wanneer applicaties eenvoudigweg naar het besturingssysteem kunnen bellen. Aangezien applicatieprogrammeurs geen systeeminterne programmeurs zijn, is het omzeilen van de OS-services niet mogelijk.Ik zeg dit omdat dit twee afzonderlijke kampen zijn en ze zelden overgaan. Toepassingen zijn in de regel geschreven om OS-services te gebruiken. Er zijn natuurlijk enkele uitzonderingen.

Toen webservers begonnen te verschijnen, probeerden applicatieontwikkelaars niet om OS-services te omzeilen. Hiervoor waren verschillende redenen. Ten eerste was het niet nodig. Ten tweede wisten applicatieprogrammeurs over het algemeen niet hoe ze OS-services moesten omzeilen. Drie, de meeste besturingssystemen waren ofwel extreem stabiel en robuust, of extreem eenvoudig en lichtgewicht en de kosten niet waard.

Houd in gedachten dat de vroege webservers ofwel op dure computers draaiden, zoals de DEC VAX / VMS-servers en de Unix van de dag (Berkeley en Ultrix en andere) op mainframe- of mid-frame computers, en kort daarna op lichtgewicht computers zoals pcs en Windows 3.1. Toen er meer moderne zoekmachines begonnen te verschijnen, zoals Google in 1997/8, was Windows overgestapt op Windows NT en begonnen andere besturingssystemen zoals Novell en Linux ook webservers te draaien. Apache was de dominante webserver, hoewel er andere waren, zoals IIS en O “Reilly, die ook erg populair waren. Geen van hen omzeilde destijds de OS-services. Het is waarschijnlijk dat geen van de webservers dat zelfs vandaag de dag doet.

Vroege webservers waren vrij eenvoudig. Ze zijn dat nog steeds. Elk verzoek om een bron via een HTTP-verzoek dat op een harde schijf staat, werd / wordt gedaan door de webserver via het OS-bestandssysteem.

Bestandssystemen zijn tamelijk eenvoudige mechanismen. Aangezien een verzoek wordt gedaan om toegang tot een bestand, wordt het verzoek, als dat bestand bestaat, doorgegeven aan het autorisatiesubsysteem en als het wordt ingewilligd, wordt aan het oorspronkelijke verzoek voldaan. niet bestaat of niet is geautoriseerd, wordt er een uitzondering gegenereerd door het systeem. Wanneer een applicatie een verzoek doet, wordt een trigger ingesteld en wacht de applicatie. Wanneer het verzoek wordt beantwoord, wordt de trigger gegenereerd en verwerkt de applicatie de respons van het verzoek. werkt nog steeds zo vandaag. Als de applicatie ziet dat het verzoek is atisfied gaat het verder, als het is mislukt, voert de applicatie een foutconditie uit binnen zijn code of sterft als het niet wordt afgehandeld. Eenvoudig.

In het geval van een webserver, aangenomen dat een URL-verzoek voor een pad / bestand wordt gedaan, neemt de webserver het pad / bestandsgedeelte van het URL-verzoek (URI) en doet een verzoek naar het bestandssysteem en het is voldaan of genereert een uitzondering. De webserver verwerkt vervolgens het antwoord. Als bijvoorbeeld het gevraagde pad en bestand worden gevonden en toegang wordt verleend door het autorisatiesubsysteem, dan verwerkt de webserver die I / O-aanvraag zoals normaal. Als het bestandssysteem een uitzondering genereert, retourneert de webserver een 404-fout als het bestand niet gevonden is of een 403 verboden als de oorzaakcode niet geautoriseerd is.

Aangezien sommige besturingssystemen hoofdlettergevoelig zijn en bestandssystemen van dit type vereist exacte overeenkomsten, het pad / bestand dat wordt gevraagd van de webserver moet exact overeenkomen met wat er op de harde schijf staat. De reden hiervoor is simpel. Webservers raden niet wat u bedoelt. Geen enkele computer doet dit zonder te zijn geprogrammeerd. Webservers verwerken verzoeken eenvoudigweg zoals ze deze ontvangen. Als het pad / bestandsgedeelte van het URL-verzoek dat rechtstreeks aan het bestandssysteem wordt doorgegeven, niet overeenkomt met wat er op de harde schijf staat, genereert het bestandssysteem een uitzondering en geeft de webserver een 404 Not Found-foutmelding.

Het zijn echt zo simpele mensen. Het is geen rocket science. Er is een absolute relatie tussen het pad / bestandsgedeelte van een URL en het bestandssysteem.

Opmerkingen

• Ik denk dat je argument onjuist is. Hoewel Berners-Lee ‘ geen keuze had over de hoofdlettergevoeligheid van ftp-URLs. Hij moest http-URLs ontwerpen. Hij had ze alleen kunnen specificeren als US-ASCII en niet hoofdlettergevoelig. Als er ooit webservers waren die zojuist het URL-pad aan het bestandssysteem hebben doorgegeven, waren ze onveilig en door de introductie van URL-codering werd de compatibiliteit daarmee verbroken. Gezien het feit dat het pad wordt verwerkt voordat het aan het besturingssysteem wordt overgedragen, zou het eenvoudig te implementeren zijn geweest. Daarom denk ik dat we dit moeten beschouwen als een ontwerpbeslissing en niet als een implementatieleer.
• @WilliamHay Dit heeft niets te maken met Berners-Lee of het ontwerp van het web. Het gaat over beperkingen en vereisten van het besturingssysteem. Ik ben een gepensioneerde systeemingenieur. Ik heb destijds aan deze systemen gewerkt. Ik vertel je precies waarom URLs hoofdlettergevoelig zijn. Het is geen gok. Het is geen mening. Het is een feit. Mijn antwoord was opzettelijk vereenvoudigd. Natuurlijk zijn er bestandscontroles en andere processen die kunnen worden uitgevoerd voordat een open verklaring wordt afgegeven. En ja (!) Webservers zijn tot op de dag van vandaag nog steeds gedeeltelijk onveilig.
• Of URLs hoofdlettergevoelig zijn, heeft niets te maken met het ontwerp van het web? Werkelijk? Argument van Authority gevolgd door Argument by Assertion.Dat webservers de padcomponent van een URL min of meer direct doorgeven aan een open call, is een gevolg van het ontwerp van URLs en geen oorzaak daarvan. Servers (of slimme clients in het geval van FTP) zouden de hoofdlettergevoeligheid van bestandssystemen voor de gebruiker kunnen hebben verborgen. Dat ze ‘ t niet doen, is een ontwerpbeslissing.
• @WilliamHay Je moet de grasopvangbak vertragen en herlezen wat ik heb geschreven. Ik ben een gepensioneerde systeemingenieur die OS-componenten, protocolstacks en routercode voor het ARPA-Net, enz. Schrijft. Ik werkte met Apache, O ‘ Reilly en IIS-internals. Uw FTP-argument houdt geen steek, aangezien de belangrijkste FTP-servers om dezelfde reden hoofdlettergevoelig blijven. Ik heb nooit iets gezegd over het ontwerp van URL / URI. Ik heb nooit gezegd dat webservers waarden doorgeven zonder te verwerken. Ik heb wel gezegd dat OS-services vaak worden gebruikt en dat het bestandssysteem een exacte match vereist om te slagen.
• @WilliamHay Begrijp alsjeblieft dat jij en ik aan elkaar denken. Het enige dat ik in mijn antwoord zei, is dat voor sommige besturingssystemen bestandssysteemaanroepen hoofdlettergevoelig zijn. Toepassingen die systeemaanroepen gebruiken, en de meeste doen dat ook, zijn beperkt tot het afdwingen van de OS-regels – in dit geval hoofdlettergevoeligheid. Het is niet onmogelijk om deze regel te omzeilen. Dit kan in sommige gevallen zelfs wat triviaal zijn, maar niet praktisch. Ik omzeilde routinematig het bestandssysteem in mijn werk om harde schijven te decoderen die om de een of andere reden kablooie gingen of om interne bestanden van databasebestanden te analyseren, enz.

1. URLs claimen een UNIFORM Resource locator te zijn en kunnen verwijzen naar bronnen die ouder zijn dan het web. Sommige hiervan zijn hoofdlettergevoelig (bijv. Veel ftp-servers) en URLs moeten deze bronnen op een redelijk intuïtieve manier kunnen weergeven.

2. Case-ongevoeligheid vereist meer werk bij het zoeken naar een match (in het besturingssysteem of erboven).

3. Als u URLs definieert als hoofdlettergevoelig, kunnen individuele servers deze als hoofdlettergevoelig implementeren als ze dat willen. Het omgekeerde is niet waar.

4. Hoofdletterongevoeligheid kan in internationale contexten niet triviaal zijn: https://en.wikipedia.org/wiki/Dotted_and_dotless_I . Ook stond RFC1738 het gebruik van tekens buiten het ASCII-bereik toe, op voorwaarde dat ze waren gecodeerd, maar geen tekenset specificeerden. Dit is vrij belangrijk voor iets dat zichzelf het WORLD wide web noemt. Het definiëren van URLs als hoofdletterongevoelig zou veel ruimte bieden voor bugs.

5. Als u probeert veel gegevens in een URI te verpakken (bijv. een Data URI ) kunt u meer inpakken als hoofd- en kleine letters verschillend zijn.

Opmerkingen

• I ‘ Ik ben er vrij zeker van dat URLs historisch beperkt waren tot ASCII. Het is dus onwaarschijnlijk dat internationalisering een originele reden is. De geschiedenis van de hoofdlettergevoeligheid van Unix, OTOH, speelde waarschijnlijk een grote rol.
• Hoewel alleen een subset van ASCII ongecodeerd kan worden gebruikt in een URL, geeft RFC1738 specifiek aan dat tekens buiten het ASCII-bereik gecodeerd mogen worden gebruikt. Zonder een tekenset te specificeren is de isn ‘ mogelijk om te weten welke octetten staan voor hetzelfde char acteur behalve voor case. Bijgewerkt.
• Re # 4: Het is ‘ eigenlijk erger dan dat. Gestippeld en zonder punten Ik ben een demonstratie van het meer algemene principe dat, zelfs als alles UTF-8 is (of een andere UTF), je niet correct kunt hoofdletters of kleine letters gebruiken zonder de landinstelling te kennen waartoe de tekst behoort . In de standaardlandinstelling wordt een Latijnse hoofdletter I kleine letters in een kleine Latijnse letter i, wat onjuist is in het Turks omdat er een punt wordt toegevoegd (er is geen ” Turkse hoofdletter I zonder punt ” codepunt; je ‘ zou het ASCII-codepunt moeten gebruiken). Voeg coderingsverschillen toe, en dit gaat van ” heel moeilijk ” tot ” volledig onhandelbaar . ”

Ik heb van de blog een Old New Thing de gewoonte om vragen te benaderen met de vorm “waarom is iets het geval?” met de tegenvraag “hoe zou de wereld eruit zien als dit niet het geval was?”

Stel dat ik een webserver heb opgezet om mezelf mijn documentbestanden uit een map te bedienen, zodat ik ze kan lezen op de telefoon toen ik niet op kantoor was. Nu heb ik in mijn documentenmap drie bestanden, todo.txt, ToDo.txt en TODO.TXT (Ik weet het, maar het was logisch voor mij toen ik de bestanden maakte).

Welke URL zou ik willen gebruiken om toegang te krijgen tot deze bestanden? Ik zou ze op een intuïtieve manier willen openen, met http://www.example.com/docs/filename.

Stel dat ik een script heb waarmee ik een contactpersoon aan mijn adresboek kan toevoegen, wat ik kan doe ook via internet.Hoe moet dat zijn parameters nemen? Nou, ik “zou het willen gebruiken als: http://www.example.com/addcontact.php?name=Tom McHenry von der O"Reilly. Maar als ik de naam niet per hoofdletter kon specificeren, hoe zou ik dat dan doen?

Hoe zou ik de wikipaginas voor Cat en CAT, Text and TEXT, latex en LaTeX differentiëren? Disambig-paginas, denk ik, maar ik geef er de voorkeur aan gewoon datgene te krijgen waar ik om vroeg.

Maar dat voelt allemaal alsof het hoe dan ook de verkeerde vraag beantwoordt.

De vraag die ik denk dat je eigenlijk stelde, is “Waarom webservers 404 u slechts voor een klein verschil, als het computers zijn, ontworpen om het leven eenvoudiger te maken , en ze zijn perfect in staat om op zijn minst de meest voor de hand liggende variaties in hoofdletters en kleine letters te vinden in de URL die ik heb getypt die zouden werken? “

Het antwoord hierop is dat hoewel sommige sites dit hebben gedaan (en beter, ze controleer ook op andere typefouten), vond niemand het de moeite waard om de standaard 404-foutpagina van een webserver te veranderen om dat te doen … maar misschien zouden ze dat moeten doen?

Opmerkingen

• Sommige sites gebruiken een soort mechanisme om een ny vraag naar allemaal kleine letters of iets consistents. In zekere zin is dit slim.
• Nee, ze zouden niet ‘ t moeten zijn. Deze functionaliteit kan worden toegevoegd, en wordt vaak toegevoegd wanneer het wenselijk is (bijv. Door modules in apache.). Dit soort verandering opleggen als standaardgedrag – of erger nog, onveranderlijk gedrag – zou meer ontwrichtend zijn dan het relatief zeldzame gelegenheid waarbij iemand handmatig een URL buiten de hostnaam moet typen. Voor een goed voorbeeld van waarom u dit niet zou doen, herinnert u zich het fiasco toen Network Solutions ” ” niet-bestaande domeinfouten van openbare DNS repareerde queries.
• @SirNickity Niemand stelde onveranderlijkheid voor op welk niveau dan ook en webserverfoutpaginas zijn configureerbaar op elke webserver die ik ‘ ooit heb gebruikt; niemand stelde voor om 404 te vervangen door 30 * codes, maar eerder een lijst met door mensen aanklikbare suggestielinks toe te voegen aan de foutpagina; domeinnamen zijn een heel ander onderwerp en het probleem is niet hoofdlettergevoelig en in een andere beveiligingscontext; en IIS herstelt al automatisch ” ” (door hoofdletterverschillen in het pad of de bestandsnaam van URIs te negeren).
• Sinds 1996 laat Apache je dit doen met mod_speling . Het lijkt gewoon niet erg populair om ‘ te doen. Unix / Linux-mensen zien hoofdletterongevoeligheid als regel, hoofdletterongevoeligheid als uitzondering.

Hoewel de bovenstaande antwoord is correct & goed. Ik zou nog wat meer punten willen toevoegen.

Om beter te begrijpen, moet men het fundamentele verschil tussen Unix (Linux) en Windows-server begrijpen. Unix is hoofdlettergevoelig & Windows is niet hoofdlettergevoelig besturingssysteem.

Het HTTP-protocol is ontwikkeld of begint geïmplementeerd te worden rond 1990. Het HTTP-protocol is ontworpen door ingenieurs die werken bij CERN-instituten, de meeste van die dagen gebruikten wetenschappers Unix-machines en niet de Windows.

De meeste wetenschappers waren bekend met Unix, dus ze waren mogelijk beïnvloed door het bestandssysteem in Unix-stijl.

Windows-server werd uitgebracht na 2000. lang voordat Windows-server populair werd, was het HTTP-protocol goed ontwikkeld en was de specificatie compleet.

Dit zou de reden kunnen zijn.

Opmerkingen

• ” Windows-server is uitgebracht na 2000. ” Het Windows NT 3.1 -team zou het in 1993 niet met je eens zijn geweest. NT 3.51 in 1995 was waarschijnlijk toen NT begon te worden volwassen en goed ingeburgerd genoeg om bedrijfskritische servertoepassingen te ondersteunen.
• NT 3.51 had de Win 3.1-interface. Windows kwam pas echt van de grond tot Windows 95 en er was NT 4.0 voor nodig om dezelfde interface te krijgen.
• Michael Kj ö rling, was het daarmee eens. Laat me het aanpassen.
• @Thorbj ø rnRavnAndersen Op de servermarkt was NT 3.51 redelijk succesvol. In de consumenten- / prosumentenmarkt duurde het tot Windows 2000 (NT 5.0) voordat de NT-lijn serieuze aandacht begon te winnen.
• Inderdaad, het WorldWideWeb werd aanvankelijk ontwikkeld op Unix-gebaseerde systemen, die hoofdlettergevoelig zijn. bestandssystemen, en de meeste URLs zijn direct toegewezen aan bestanden op het bestandssysteem.

Hoe moet iemand lezen een “waarom is het zo ontworpen?” vraag? Vraagt u om een historisch accuraat verslag van het besluitvormingsproces, of vraagt u “waarom zou iemand het op deze manier ontwerpen?”?

Het is zeer zelden mogelijk om een historisch correcte account.Soms, wanneer beslissingen worden genomen in normcommissies, is er een documentair spoor van hoe het debat werd gevoerd, maar in de vroege dagen van het web werden beslissingen overhaast genomen door een paar individuen – in dit geval waarschijnlijk door TimBL zelf – en de grondgedachte is onwaarschijnlijk zijn opgeschreven. Maar TimBL heeft toegegeven dat hij fouten heeft gemaakt bij het ontwerpen van URLs – zie http://www.dailymail.co.uk/sciencetech/article-1220286/Sir-Tim-Berners-Lee-admits-forward-slashes-web-address-mistake.html

In het begin waren URLs zeer direct toegewezen aan bestandsnamen, en de bestanden bevonden zich over het algemeen op Unix-achtige machines, en Unix-achtige machines hebben hoofdlettergevoelige bestandsnamen. Dus mijn gok is dat het gewoon zo gebeurde voor het gemak van de implementatie, en bruikbaarheid (voor eindgebruikers) werd zelfs nooit overwogen. Nogmaals, in de begintijd waren de gebruikers sowieso allemaal Unix-programmeurs.

Opmerkingen

• Eindgebruikers waren ook Unix-gebruikers (niet noodzakelijkerwijs programmeurs, maar hoogenergetische fysici en dergelijke), dus ook zij waren gewend aan hoofdletterongevoeligheid.

Dit heeft niets te maken met waar u uw domein heeft gekocht, DNS is niet hoofdlettergevoelig. Maar het bestandssysteem op de server die u gebruikt voor hosting is.

Dit is niet echt een probleem en het komt vrij vaak voor op * nix-hosts. Zorg ervoor dat alle links die u op uw paginas schrijft correct zijn en dat u geen probleem zult hebben. Om het gemakkelijker te maken, raad ik aan om uw paginas altijd in kleine letters te noemen. U hoeft de naam dan nooit dubbel te controleren bij het schrijven van een link.

Closetnoc heeft gelijk over het besturingssysteem. Sommige bestandssystemen behandelen dezelfde naam met verschillende hoofdletters en kleine letters als verschillende bestanden.

Er is ook een echt doel / voordeel aan het hebben van een hoofdlettergevoelige URL (in tegenstelling tot de overgrote meerderheid van URLs die naar dezelfde pagina verwijzen, ongeacht het hoofdlettergebruik)?

Ja. om dubbele inhoudsproblemen te voorkomen.

Als u bijvoorbeeld de volgende URLs had:

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 

en ze wezen allemaal naar exact dezelfde pagina met exact dezelfde inhoud, dan zou je dubbele inhoud hebben, en ik weet zeker dat als je een Google-zoekconsole hebt (webmaster tools) account, zal Google dit aan u aangeven.

Wat ik wil Als je je in die situatie bevindt, raad ik aan om alle URLs met kleine letters te gebruiken, en de URLs met ten minste één hoofdletter erin om te leiden naar de versie met kleine letters. Dus leid in de lijst met URLs hierboven alle URLs om naar de eerste URL.

Reacties

• ” Ja. om dubbele inhoudsproblemen te voorkomen. ” – Maar het tegenovergestelde lijkt waar te zijn? Het feit dat URLs hoofdlettergevoelig kunnen zijn (en dit is hoe zoekmachines ze behandelen) veroorzaakt de dubbele inhoudsproblemen die u noemt. Als URLs universeel hoofdletterongevoelig zouden zijn, zouden er geen dubbele inhoudsproblemen zijn met verschillende hoofdletters. page-1 zou hetzelfde zijn als PAGE-1.
• Ik denk dat een slechte serverconfiguratie is wat dubbele inhoud kan veroorzaken als het om behuizing gaat. De instructie RewriteRule ^request-uri$ /targetscript.php [NC] opgeslagen in .htaccess zou bijvoorbeeld overeenkomen met http://example.com/request-uri en http://example.com/ReQuEsT-Uri omdat de [NC] geeft aan dat hoofdlettergebruik ‘ niet uitmaakt bij het evalueren van die ene reguliere expressie.

Hoofdlettergevoeligheid heeft waarde.

Als er 26 letters zijn, elk met de mogelijkheid om een hoofdletter te maken, zijn dat 52 karakters.

4 karakters hebben de mogelijkheid van 52 * 52 * 52 * 52 combinaties, gelijk aan 7311616 combinaties.

Als u de tekens niet in hoofdletters kunt schrijven, is het aantal combinaties 26 * 26 * 26 * 26 = 456976

Het zijn meer dan 14 keer meer combinaties voor 52 tekens dan er zijn er voor 26. Dus voor het opslaan van gegevens kunnen URLs korter zijn en kan meer informatie via netwerken worden doorgegeven met minder gegevensoverdracht.

Daarom zie je YouTube met URLs zoals https://www.youtube.com/watch?v=xXxxXxxX