Dlaczego w adresach URL jest rozróżniana wielkość liter?

Dlaczego nie w adresie URL uwzględniana jest wielkość liter?

Rozumiem, że może to wyglądać na prowokacyjne (i „adwokata diabła”) pytanie retoryczne, ale myślę, że warto to rozważyć. Projekt protokołu HTTP jest że „klient”, który zwykle nazywamy „przeglądarką internetową”, prosi „serwer sieciowy” o dane.

Jest wiele, wiele różnych serwerów internetowych, które są udostępniane. Microsoft wypuścił IIS w systemie Windows Systemy operacyjne dla serwerów (i inne, w tym Windows XP Professional). Unix ma duże rozmiary, takie jak nginx i Apache, nie wspominając o mniejszych ofertach, takich jak wewnętrzny httpd lub thttpd lub lighttpd w OpenBSD. Ponadto wiele urządzeń obsługujących sieć ma wbudowane serwery internetowe, które można wykorzystać do konfiguracji urządzenia, w tym urządzenia przeznaczone do celów specyficznych dla sieci, takie jak routery (w tym wiele punktów dostępu Wi-Fi i modemy DSL) i inne urządzenia, takie jak drukarki lub UPS (zasilacze bezprzerwowe z podtrzymaniem bateryjnym), które mogą mieć łączność z siecią.

Pytanie „Dlaczego w adresach URL jest rozróżniana wielkość liter?” Brzmi: „Dlaczego serwery internetowe traktują adres URL uwzględniając wielkość liter? ” A właściwa odpowiedź brzmi: nie wszyscy tego robią. Przynajmniej jeden serwer sieciowy, który jest dość popularny, zwykle NIE rozróżnia wielkości liter. (Serwer sieciowy to IIS).

Głównym powodem różne zachowania między różnymi serwerami sieciowymi prawdopodobnie sprowadzają się do kwestii prostoty. Prostym sposobem utworzenia serwera WWW jest zrobienie takich samych rzeczy, jak system operacyjny komputera / urządzenia lokalizujący pliki. Wiele razy serwery WWW lokalizują plik w celu udzielenia odpowiedzi. Unix został zaprojektowany z myślą o komputerach wyższej klasy, więc Unix zapewnił pożądaną funkcjonalność zezwalania na wielkie i małe litery. Unix zdecydował się traktować wielkie i małe litery jako różne, ponieważ są one różne. To jest prosta, naturalna rzecz do zrobienia. W systemie Windows nie było rozróżniania wielkości liter z powodu chęci obsługi już utworzonego oprogramowania, a ta historia sięga do DOS, który po prostu nie obsługiwał małych liter, prawdopodobnie w ramach wysiłku aby uprościć sprawę z mniej wydajnymi komputerami, które zużywały mniej pamięci. Ponieważ te systemy operacyjne są różne, w rezultacie prostsze (wczesne wersje) serwerów WWW odzwierciedlają te same różnice.

Teraz, przy tym wszystkim tło, oto kilka odpowiedzi na konkretne pytania:

Dlaczego przy projektowaniu adresów URL uwzględniono wielkość liter?

Dlaczego nie? Gdyby na wszystkich standardowych serwerach WWW wielkość liter nie była rozróżniana, oznaczałoby to, że serwery WWW przestrzegały zestawu reguł określonych w standardzie. Po prostu nie było regułę, która mówi, że przypadek należy zignorować. Przyczyną braku reguły jest po prostu brak powodu była taka zasada. Po co zawracać sobie głowę zbędnymi regułami?

Pytam, ponieważ wydaje mi się (tj., laik), że nieuwzględnianie wielkości liter byłoby preferowane, aby zapobiec niepotrzebnym błędom i uprościć już skomplikowany ciąg tekstu.

Adresy URL zostały zaprojektowane do przetwarzania przez komputery . Chociaż osoba może wpisać pełny adres URL w pasku adresu, nie było to główną częścią zamierzonego projektu. Planowany projekt zakłada, że ludzie będą podążać za hiperłączami („klikać”). Jeśli robią to przeciętni laicy, to naprawdę nie obchodzi mnie, czy niewidoczny adres URL jest prosty czy skomplikowany.

Ponadto, czy istnieje prawdziwy cel / zaleta posiadania adresu URL z rozróżnianiem wielkości liter (jak w przeciwieństwie do zdecydowanej większości adresów URL, które prowadzą do tej samej strony bez względu na wielkość liter)?

Piąty numerowany punkt w Odpowiedź Williama Haya wspomina o jednej technicznej przewadze: adresy URL mogą być skutecznym sposobem, aby przeglądarka internetowa wysyłała trochę informacji na serwer sieciowy, a więcej informacji można dołączyć, jeśli jest ich mniej ograniczenia, więc ograniczenie rozróżniania wielkości liter zmniejszyłoby ilość informacji, które można uwzględnić.

Jednak w wielu przypadkach nie ma żadnej nadzwyczajnej korzyści z rozróżniania wielkości liter, co jest udowodnione przez fakt, że IIS zazwyczaj nie zawraca sobie tym głowy.

Podsumowując, najbardziej istotnym powodem jest prawdopodobnie prostota dla tych, którzy zaprojektowali oprogramowanie serwera internetowego, szczególnie na platformach z rozróżnianiem wielkości liter, takich jak Unix . (HTTP nie był czymś, co wpłynęło na oryginalny projekt Uniksa, ponieważ Unix jest znacznie starszy niż HTTP.)

Komentarze

• ” Główny powód odmiennego zachowania różnych przeglądarek internetowych prawdopodobnie sprowadza się do prostoty. ” – zakładam, że oznacza ” serwery internetowe „, a nie ” przeglądarki internetowe ” tutaj i w kilku innych miejscach?
• Zaktualizowano. Sprawdzono każdy przypadek ” przeglądarek ” i dokonałem wielu zmian. Dziękuję za wskazanie tego, aby można było poprawić jakość.
• Otrzymałem kilka doskonałych odpowiedzi na moje pytanie, od historycznych po Waham się, czy pójść pod prąd i zaakceptować odpowiedź o niższej ocenie, ale odpowiedź @TOOGAM ' była najbardziej pomocna, mnie. Ta odpowiedź jest dokładna i obszerna, ale wyjaśnia koncepcję w nieskomplikowany, konwersacyjny sposób, który mogę zrozumieć. Myślę, że ta odpowiedź jest dobrym wprowadzeniem do bardziej szczegółowych wyjaśnień.
• Powodem, dla którego Windows ma system plików bez rozróżniania wielkości liter, jest to, że ' s Dziedzictwo DOS. MS-DOS rozpoczął życie na komputerach takich jak Tandy TRS-80, które używały telewizora jako wyświetlacza i pierwotnie nie obsługiwały małych liter ze względu na brak rozdzielczości. Ponieważ nie mógł ' wyświetlać małych liter, nie były one ' obsługiwane. MS-DOS został licencjonowany przez IBM jako oryginalny PC-DOS. Podczas gdy oryginalny komputer mógł wyświetlać małe litery, system plików został przeniesiony z MS-DOS.

W adresach URL nie jest rozróżniana wielkość liter, tylko ich części.
Na przykład w adresie URL https://google.com,

nie jest rozróżniana wielkość liter. W odniesieniu do RFC 3986 – Uniform Resource Identifier (URI): Generic Syntax

Najpierw z Wikipedia , adres URL wygląda następująco:

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

(Usunąłem user:password część, ponieważ nie jest interesująca i rzadko używana)

• scheme :

W schematach wielkość liter nie jest rozróżniana

• host :

W składniku podrzędnym hosta nie jest rozróżniana wielkość liter.

• path :

Składnik ścieżki zawiera dane …

• query :

Składnik zapytania zawiera dane niehierarchiczne …

• fragment :

Poszczególne typy mediów mogą definiować własne ograniczenia lub struktury w składni identyfikatora fragmentów w celu określenia różnych typów podzbiorów, widoków lub odniesień zewnętrznych

Tak więc w scheme i host nie jest rozróżniana wielkość liter.
W pozostałych w adresie URL rozróżniana jest wielkość liter.

Dlaczego w path rozróżniana jest wielkość liter?

Wydaje się, że jest to główne pytanie.
Trudno odpowiedzieć „dlaczego” coś zostało zrobione, jeśli nie zostało to udokumentowane, ale możemy zgadnąć.
Wybrałem bardzo konkretne cytaty ze specyfikacji, z naciskiem na data .
Spójrzmy jeszcze raz na adres URL:

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

• Lokalizacja – lokalizacja ma formę kanoniczną i nie jest rozróżniana wielkość liter. Dlaczego? Prawdopodobnie mógłbyś kupić nazwę domeny bez konieczności kupowania tysięcy wariantów.

• Dane – dane są używane przez serwer docelowy, a aplikacja może wybrać, co to oznacza . Nie ma sensu, aby dane nie uwzględniały wielkości liter. Aplikacja powinna mieć więcej opcji, a zdefiniowanie niewrażliwości na wielkość liter w specyfikacji ograniczy te opcje.
  Jest to również przydatne rozróżnienie w przypadku protokołu HTTPS: dane są zaszyfrowane , ale host jest widoczny.

Czy to przydatne?

Przypadek- czułość ma swoje pułapki, jeśli chodzi o buforowanie i kanoniczne adresy URL, ale z pewnością jest przydatna. Kilka przykładów:

• Base64 , który jest używany w identyfikatorach URI danych .
• Witryny mogą kodować dane Base64 w adresie URL, na przykład: http://tryroslyn.azurewebsites.net/#f:r/A4VwRgNglgxgBDCBDAziuBhOBvGB7AOxQBc4SAnKAgczLgF44AiAUQPwBMBTDuKuYgAsucAKoAlADIBCJgG4AvkA
• Skracacze adresów URL uwzględniają wielkość liter: /a5B może być inne niż /a5b
• Jak wspomniałeś, Wikipedia potrafi odróżnić „AIDS” od „AIDS”.

Komentarze

• ” URL-e nie są przypadkami wrażliwe na e-maile. ” / ” W pozostałej części adresu URL rozróżniana jest wielkość liter. ” – Wydaje się, że to sprzeczność?
• Prawdę mówiąc, schemat definiuje, czego się spodziewać w pozostałej części adresu URL. http: i powiązane schematy oznaczają, że adres URL odnosi się do nazwy hosta DNS. DNS na długo przed wynalezieniem adresów URL nie rozróżniał wielkości liter w ASCII. Zobacz stronę 55 ietf.org/rfc/rfc883.txt
• Bardzo szczegółowe! Szedłem z historycznego punktu widzenia. Pierwotnie była to ścieżka pliku, która wymagała rozróżniania wielkości liter tylko wtedy, gdy trafiłeś do systemu plików. W przeciwnym razie tak nie było. Ale dzisiaj sytuacja się zmieniła. Na przykład parametry i CGI pierwotnie nie istniały. Twoja odpowiedź dotyczy aktualnej perspektywy dnia. Musiałem wynagrodzić twoje wysiłki !! Naprawdę się przyłożyłeś do tego! Kto by pomyślał, że to wybuchnie w taki sposób? Pozdrawiam !!
• @ w3dk: it ' to niezbyt interesujące dziwactwo terminologiczne, ale możesz wziąć ” rozróżniana wielkość liter ” oznacza, ” zmiana wielkości liter może zmienić całą ” lub możesz to rozumieć, ” zmiana wielkości liter zawsze zmienia całą „. Kobi wydaje się twierdzić, że to drugie, woli, aby uwzględnianie wielkości liter oznaczało ” każda zmiana wielkości liter jest znacząca „, co oczywiście nie dotyczy adresów URL. Wolisz to pierwsze. To ' to tylko kwestia jak są wrażliwe na wielkość liter.
• @ rybo111: Jeśli użytkownik wpisze example.com/fOObaR , specyfikacja wymaga, aby serwer www.example.com otrzymał ścieżkę ” / fOObaR ” jak podano; milczy w kwestii, czy serwer musi traktować to inaczej niż ” / foOBaR „.

Proste. System operacyjny rozróżnia wielkość liter. Serwery internetowe zwykle nie dbają o to, chyba że w pewnym momencie będą musiały uderzyć w system plików. W tym miejscu Linux i inne systemy operacyjne oparte na Uniksie wymuszają reguły systemu plików, w których rozróżnianie wielkości liter jest główną częścią. Dlatego w IIS nigdy nie była rozróżniana wielkość liter; ponieważ Windows nigdy nie rozróżniał wielkości liter.

[Aktualizacja]

W komentarzach (od czasu usunięcia) pojawiły się mocne argumenty dotyczące tego, czy adresy URL mają jakikolwiek związek z systemem plików, jak już wspomniałem. Te argumenty zaostrzyły się. Wierzenie, że nie ma związku, jest skrajnie krótkowzroczne. Jest absolutnie! Pozwólcie, że wyjaśnię dalej.

Programiści aplikacji nie są na ogół programistami wewnętrznymi systemów. Nie obrażam się. Są to dwie odrębne dyscypliny i wiedza o wewnętrznych systemach nie jest wymagana do pisania aplikacji, gdy aplikacje mogą po prostu wykonywać wywołania do systemu operacyjnego. Ponieważ programiści aplikacji nie są programistami wewnętrznymi systemu, ominięcie usług systemu operacyjnego nie jest możliwe.Mówię to, ponieważ są to dwa oddzielne obozy i rzadko się krzyżują. Aplikacje są napisane w taki sposób, aby z reguły korzystały z usług systemu operacyjnego. Oczywiście istnieją pewne wyjątki.

Kiedy zaczęły pojawiać się serwery internetowe, twórcy aplikacji nie próbowali ominąć usług systemu operacyjnego. Złożyło się na to kilka powodów. Po pierwsze, nie było to konieczne. Po drugie, programiści aplikacji na ogół nie wiedzieli, jak ominąć usługi systemu operacyjnego. Po trzecie, większość systemów operacyjnych była albo wyjątkowo stabilna i solidna, albo wyjątkowo prosta i lekka i nie warta swojej ceny.

Należy pamiętać, że wczesne serwery internetowe działały albo na drogich komputerach, takich jak DEC VAX / Serwery VMS i ówczesny Unix (Berkeley i Ultrix oraz inne) na komputerach typu main-frame lub mid-frame, a wkrótce potem na lekkich komputerach, takich jak PC i Windows 3.1. Kiedy zaczęły pojawiać się bardziej nowoczesne wyszukiwarki, takie jak Google w latach 1997/8, Windows przeniósł się do Windows NT, a inne systemy operacyjne, takie jak Novell i Linux, również zaczęły uruchamiać serwery sieciowe. Apache był dominującym serwerem internetowym, chociaż istniały inne, takie jak IIS i O „Reilly, które również były bardzo popularne. Żaden z nich nie omijał wtedy usług systemu operacyjnego. Jest prawdopodobne, że żaden z serwerów WWW nie działa nawet dzisiaj.

Wczesne serwery WWW były dość proste. Nadal istnieją. Każde żądanie dotyczące zasobu za pośrednictwem żądania HTTP znajdującego się na dysku twardym było / jest wysyłane przez serwer sieciowy za pośrednictwem systemu plików systemu operacyjnego.

Systemy plików są raczej prostymi mechanizmami. Ponieważ żąda się dostępu do pliku, jeśli ten plik istnieje, żądanie jest przekazywane do podsystemu autoryzacji i jeśli zostanie przyznane, pierwotne żądanie jest spełnione. Jeśli zasób tak nie istnieje lub nie ma autoryzacji, system zgłasza wyjątek. Gdy aplikacja wysyła żądanie, ustawiany jest wyzwalacz i aplikacja czeka. Po otrzymaniu odpowiedzi wyzwalacz jest generowany, a aplikacja przetwarza odpowiedź na żądanie. nadal tak działa. Jeśli aplikacja widzi, że żądanie zostało s jeśli jest spełniony, kontynuuje, jeśli nie powiodło się, aplikacja wykonuje warunek błędu w swoim kodzie lub umiera, jeśli nie zostanie obsłużona. Proste.

W przypadku serwera WWW, zakładając, że zostało wysłane żądanie adresu URL dla ścieżki / pliku, serwer WWW pobiera część ścieżki / pliku żądania adresu URL (URI) i wysyła żądanie do systemu plików i jest spełniony lub zgłasza wyjątek. Następnie serwer sieciowy przetwarza odpowiedź. Jeśli na przykład żądana ścieżka i plik zostaną znalezione, a dostęp jest udzielony przez podsystem autoryzacji, serwer sieciowy przetwarza to żądanie we / wy normalnie. Jeśli system plików zgłasza wyjątek, serwer sieciowy zwraca błąd 404, jeśli plik nie został znaleziony lub 403 zabroniony, jeśli kod przyczyny jest nieautoryzowany.

Ponieważ w niektórych systemach jest rozróżniana wielkość liter, a systemy plików ten typ wymaga dokładnych dopasowań, ścieżka / plik żądany od serwera WWW musi dokładnie odpowiadać temu, co istnieje na dysku twardym. Powód jest prosty. Serwery internetowe nie odgadują, co masz na myśli. Żaden komputer nie robi tego bez zaprogramowania. Serwery WWW po prostu przetwarzają żądania w miarę ich otrzymywania. Jeśli część ścieżki / pliku żądania URL przekazywanego bezpośrednio do systemu plików nie jest zgodna z tym, co znajduje się na dysku twardym, system plików zgłasza wyjątek, a serwer sieciowy zwraca błąd 404 Not Found.

To naprawdę tacy prości ludzie. To nie jest fizyka jądrowa. Istnieje bezwzględny związek między ścieżką / częścią pliku adresu URL a systemem plików.

Komentarze

• Uważam, że argument jest błędny. Chociaż Berners-Lee nie ' nie miał żadnego wyboru co do rozróżniania wielkości liter w adresach URL ftp. Musiał zaprojektować adresy URL http. Mógł określić je jako tylko US-ASCII i nie rozróżniać wielkości liter. Jeśli kiedykolwiek istniały serwery internetowe, które właśnie przekazały ścieżkę adresu URL do systemu plików, były one niezabezpieczone, a wprowadzenie kodowania adresów URL zepsuło z nimi zgodność. Biorąc pod uwagę, że ścieżka jest przetwarzana przed przekazaniem do przypadku zniszczenia systemu operacyjnego, byłoby łatwe do zaimplementowania. Dlatego myślę, że powinniśmy traktować to jako decyzję projektową, a nie dziwactwo wdrożeniowe.
• @WilliamHay Nie ma to nic wspólnego z Berners-Lee ani projektem sieci. Chodzi o ograniczenia i wymagania systemu operacyjnego. Jestem emerytowanym inżynierem ds. Wewnętrznych systemów. Pracowałem wtedy nad tymi systemami. Dokładnie wyjaśniam, dlaczego w adresach URL jest rozróżniana wielkość liter. To nie jest domysł. To nie jest opinia. To jest fakt. Moja odpowiedź została celowo uproszczona. Oczywiście istnieją kontrole plików i inne procesy, które można wykonać przed wydaniem jakiegokolwiek otwartego oświadczenia. I tak (!) Serwery internetowe są do dziś częściowo niezabezpieczone.
• To, czy adresy URL uwzględniają wielkość liter, nie ma nic wspólnego z projektem sieci? Naprawdę? Argument from Authority, po którym następuje Argument by Assertion.To, że serwery internetowe przekazują składnik ścieżki adresu URL mniej więcej bezpośrednio do otwartego wywołania, jest konsekwencją zaprojektowania adresu URL, a nie jego przyczyną. Serwery (lub inteligentni klienci w przypadku FTP) mogą ukryć przed użytkownikiem rozróżnianie wielkości liter w systemach plików. To, że nie ' t jest decyzją projektową.
• @WilliamHay Musisz zwolnić kosz na trawę i ponownie przeczytać to, co napisałem. Jestem emerytowanym inżynierem ds. Systemów wewnętrznych i piszę komponenty systemu operacyjnego, stosy protokołów i kod routera dla sieci ARPA-Net itp. Pracowałem z Apache, O ' Reilly i wewnętrznymi usługami IIS. Twój argument FTP nie jest wystarczający, ponieważ przynajmniej główne serwery FTP uwzględniają wielkość liter z tego samego powodu. Nigdy nie mówiłem nic o projektowaniu adresu URL / URI. Nigdy nie powiedziałem, że serwery sieciowe przekazują wartości bez przetwarzania. Powiedziałem, że usługi systemu operacyjnego są powszechnie używane i że system plików wymaga dokładnego dopasowania, aby odnieść sukces.
• @WilliamHay Proszę zrozumieć, że ty i ja myślimy na różne sposoby. W mojej odpowiedzi powiedziałem tylko, że w przypadku niektórych systemów operacyjnych w wywołaniach systemu plików wielkość liter ma znaczenie. Aplikacje, które używają wywołań systemowych, a większość z nich to robi, są ograniczone do egzekwowania reguł systemu operacyjnego – w tym przypadku rozróżniania wielkości liter. Nie da się obejść tej zasady. W rzeczywistości może to być nieco trywialne w niektórych przypadkach, choć niepraktyczne. Kiedyś rutynowo omijałem system plików w mojej pracy, aby rozszyfrować dyski twarde, które z jakiegoś powodu były kablooie, lub aby przeanalizować wewnętrzne pliki bazy danych itp.

1. Adresy URL twierdzą, że są UNIFORM lokalizatorem zasobów i mogą wskazywać na zasoby sprzed sieci. W niektórych z nich jest rozróżniana wielkość liter (np. Wiele serwerów ftp), a adresy URL muszą być w stanie reprezentować te zasoby w rozsądnie intuicyjny sposób.

2. Niewrażliwość na wielkość liter wymaga więcej pracy przy wyszukiwaniu dopasowanie (w systemie operacyjnym lub powyżej).

3. Jeśli zdefiniujesz adresy URL z rozróżnianiem wielkości liter, poszczególne serwery mogą je zaimplementować bez rozróżniania wielkości liter, jeśli chcą. Odwrotność nie jest prawdą.

4. Niewrażliwość na wielkość liter może być nietrywialna w kontekstach międzynarodowych: https://en.wikipedia.org/wiki/Dotted_and_dotless_I . RFC1738 zezwalało również na użycie znaków spoza zakresu ASCII, pod warunkiem, że były zakodowane, ale nie określały zestawu znaków. Jest to dość ważne w przypadku czegoś, co nazywa się siecią ogólnoświatową. Definiowanie adresów URL jako niewrażliwych na wielkość liter otworzyłoby wiele możliwości dla błędy.

5. Jeśli próbujesz spakować dużo danych do identyfikatora URI (np. URI danych) ) możesz spakować więcej, jeśli duże i małe litery są różne.

Komentarze

• I ' m jestem całkiem pewien, że adresy URL były historycznie ograniczone do ASCII. Dlatego internacjonalizacja raczej nie jest oryginalnym powodem. Historia Uniksa z rozróżnianiem wielkości liter, OTOH, prawdopodobnie odegrała ogromną rolę.
• Chociaż tylko podzbiór znaków ASCII może być używany w postaci niezakodowanej w adresie URL, RFC1738 wyraźnie stwierdza, że znaki spoza zakresu ASCII mogą być używane w postaci zakodowanej. Bez określenia zestawu znaków, jego nie ' nie można poznać które oktety reprezentują ten sam znak acter z wyjątkiem przypadku. Zaktualizowano.
• Ad # 4: To ' jest gorsze niż to. Kropkowane i bez kropki Jestem przykładem bardziej ogólnej zasady, że nawet jeśli wszystko jest w formacie UTF-8 (lub jakimś innym UTF), nie możesz używać wielkich liter ani małych liter bez znajomości ustawień regionalnych, do których należy tekst . W domyślnych ustawieniach regionalnych duża litera łacińska I zamieniana jest na małą literę łacińską i, co jest błędne w języku tureckim, ponieważ dodaje kropkę (nie ma ” tureckiej dużej litery bez kropki I ” punkt kodowy; ' zamierzasz używać punktu kodowego ASCII). Dorzuć różnice w kodowaniu, a to przechodzi od ” naprawdę trudnych ” do ” całkowicie trudnych . ”

Ukradłem z bloga Old New Thing zwyczaj podchodzenia do pytań w formie „dlaczego tak się dzieje?” z kontrpytaniem „jak wyglądałby świat, gdyby tak nie było?”

Załóżmy, że skonfigurowałem serwer sieciowy, aby udostępniać sobie pliki dokumentów z folderu, aby móc je czytać telefon, kiedy byłem poza biurem. Teraz w folderze dokumentów mam trzy pliki, todo.txt, ToDo.txt i TODO.TXT (Wiem, ale miało to dla mnie sens, kiedy tworzyłem pliki).

Jakiego adresu URL chciałbym używać, aby uzyskać dostęp do tych plików? Chciałbym mieć do nich dostęp w intuicyjny sposób, używając http://www.example.com/docs/filename.

Powiedzmy, że mam skrypt, który pozwala mi dodać kontakt do mojej książki adresowej, co mogę również w internecie.Jak to powinno mieć jego parametry? Cóż, chciałbym go używać na przykład: http://www.example.com/addcontact.php?name=Tom McHenry von der O"Reilly. Ale gdyby nie było możliwości określenia nazwy według wielkości liter, jak bym to zrobił?

Jak rozróżniłbym strony wiki dla Cat i CAT, Text and TEXT, Latex i LaTeX? Chyba strony disambig, ale wolę po prostu dostać to, o co prosiłem.

Ale wszystko to wydaje się w każdym razie odpowiada na złe pytanie.

Pytanie, które wydaje mi się, że tak naprawdę zadawałeś, brzmi: „Dlaczego serwery internetowe 404 są dla Ciebie tak ważne, skoro są to komputery zaprojektowane tak, aby ułatwić życie , i są w stanie znaleźć co najmniej najbardziej oczywiste odmiany wpisanego przeze mnie adresu URL, które zadziałają? ”

Odpowiedź brzmi: chociaż niektóre witryny już to zrobiły (i lepiej, sprawdzić też inne literówki), nikt nie pomyślał, że warto zmienić domyślną stronę błędu 404 serwera WWW, aby to zrobić … ale może powinni?

Komentarze

• Niektóre witryny używają pewnego rodzaju mechanizmu do konwersji pliku ny zapytanie do wszystkich małych liter lub czegoś spójnego. W pewnym sensie jest to sprytne.
• Nie, nie powinny one ' t. Ta funkcjonalność może być i często jest dodawana, gdy jest to pożądane (np. Przez moduły w Apache). Narzucenie tego rodzaju zmiany jako zachowanie domyślne – lub, co gorsza, niezmienne zachowanie – byłoby bardziej uciążliwe niż stosunkowo rzadkie okazja, gdy ktoś musi ręcznie wpisać adres URL poza nazwą hosta. Aby zobaczyć dobry przykład, dlaczego tego nie robić, przypomnij sobie fiasko, gdy Network Solutions ” naprawiło ” nieistniejące błędy domeny z publicznego DNS zapytania.
• @SirNickity Nikt nie proponował niezmienności na żadnym poziomie, a strony błędów serwera WWW można konfigurować na każdym serwerze, z ' kiedykolwiek używanym; nikt nie sugerował zastąpienia 404 kodami 30 *, ale raczej dodanie listy linków z sugestiami, które można kliknąć na stronie błędu; nazwy domen to zupełnie inny temat i problem bez rozróżniania wielkości liter i w innym kontekście bezpieczeństwa; a IIS już automatycznie ” naprawia ” (ignorując) różnice wielkości liter w ścieżkach lub częściach nazw plików identyfikatorów URI.
• Od 1996 Apache pozwala ci to robić za pomocą mod_speling . Po prostu nie ' nie wydaje się być bardzo popularną czynnością. Użytkownicy Uniksa / Linuksa postrzegają jako regułę niewrażliwość na wielkość liter, wyjątek na wielkość liter.

Chociaż powyższa odpowiedź jest poprawna & dobrze. Chciałbym dodać więcej punktów.

Aby lepiej zrozumieć, należy zrozumieć podstawową różnicę między serwerem Unix (Linux) a serwerem Windows. W systemie Unix rozróżniana jest wielkość liter & System Windows nie rozróżnia wielkości liter.

Protokół HTTP ewoluował lub zaczął być wdrażany około 1990 roku. Protokół HTTP został zaprojektowany przez inżynierów pracujących w Instytuty CERN przez większość czasu naukowcy korzystali z maszyn Unix, a nie Windows.

Większość naukowców była zaznajomiona z Uniksem, więc prawdopodobnie wpłynął na nich system plików w stylu uniksowym.

Serwer Windows został wydany po 2000 roku. Dużo zanim serwer Windows stał się popularny Protokół HTTP był dobrze rozwinięty i specyfikacja była kompletna.

To może być powód.

Komentarze

• ” Serwer Windows został wydany po 2000 roku. ” Zespół Windows NT 3.1 nie zgodziłby się z Tobą w 1993 roku. NT 3.51 w 1995 roku prawdopodobnie zaczął być wystarczająco dojrzałe i ugruntowane, aby obsługiwać krytyczne dla firmy aplikacje serwerowe.
• NT 3.51 miał interfejs Win 3.1. Windows tak naprawdę nie wystartował aż do Windows 95 i zajęło NT 4.0, aby uzyskać ten sam interfejs.
• Michael Kj ö rling, zgodził się. Pozwólcie, że zmodyfikuję.
• @Thorbj ø rnRavnAndersen Na rynku serwerów NT 3.51 odniósł spory sukces. Na rynku konsumenckim / prosumenckim minęło aż Windows 2000 (NT 5.0), zanim linia NT zaczęła zyskiwać na znaczeniu.
• Rzeczywiście, WorldWideWeb początkowo został opracowany na systemach Unix, w których rozróżniana jest wielkość liter systemy plików i większość adresów URL odwzorowanych bezpośrednio na pliki w systemie plików.

Jak należy czytać a „dlaczego został zaprojektowany w ten sposób?” pytanie? Czy pytasz o historycznie dokładny opis procesu podejmowania decyzji, czy też pytasz „dlaczego ktokolwiek miałby to zaprojektować w ten sposób?”?

Bardzo rzadko można uzyskać dokładne historycznie konto.Czasami, gdy decyzje są podejmowane w komitetach normalizacyjnych, jest dokumentalny ślad tego, jak przebiegała debata, ale na początku istnienia sieci decyzje były podejmowane w pośpiechu przez kilka osób – w tym przypadku prawdopodobnie przez samego TimBLa – i uzasadnienie jest mało prawdopodobne zostały zapisane. Ale TimBL przyznał, że popełnił błędy w projektowaniu adresów URL – patrz http://www.dailymail.co.uk/sciencetech/article-1220286/Sir-Tim-Berners-Lee-admits-forward-slashes-web-address-mistake.html

Na początku adresy URL były mapowane bardzo bezpośrednio na nazwy plików, a pliki znajdowały się na ogół na maszynach uniksopodobnych, a maszyny podobne do Uniksa miały w nazwach plików rozróżnianą wielkość liter. Domyślam się, że tak się stało ze względu na wygodę implementacji, a użyteczność (dla użytkowników końcowych) nigdy nie była brana pod uwagę. Ponownie, na początku wszyscy użytkownicy byli i tak programistami uniksowymi.

Komentarze

• Użytkownicy końcowi również byli użytkownikami Uniksa (niekoniecznie programistami, ale fizycy wysokich energii itp.), więc oni również byli przyzwyczajeni do niewrażliwości na wielkość liter.

To nie ma nic wspólnego z miejscem zakupu domeny, DNS nie rozróżnia wielkości liter. Ale system plików na serwerze, którego używasz do hostingu, to.

To naprawdę nie jest problem i jest dość powszechny na hostach * nix. Po prostu upewnij się, że wszystkie linki, które piszesz na swoich stronach są poprawne i nie będziesz miał problemu. Aby to ułatwić, zalecam zawsze nazywać strony małymi literami, dzięki czemu nigdy nie będziesz musiał dwukrotnie sprawdzać nazwy podczas pisania linku.

Closetnoc ma rację co do systemu operacyjnego. Niektóre systemy plików traktują tę samą nazwę z różnymi wielkościami liter jako różne pliki.

Poza tym, czy istnieje prawdziwy cel / zaleta posiadania adresu URL z rozróżnianiem wielkości liter (w przeciwieństwie do ogromnej większości adresów URL, które prowadzą do tej samej strony bez względu na wielkie litery)?

Tak. Aby uniknąć problemów z powielaniem treści.

Jeśli masz na przykład następujące adresy 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 wszystkie wskazywały dokładnie na tę samą stronę z dokładnie taką samą treścią, wtedy miałbyś zduplikowaną treść i jestem pewien, że masz konsolę wyszukiwania Google (narzędzia dla webmasterów), Google wskaże Ci to.

Co dla Ciebie ld sugeruje, aby zrobić, jeśli jesteś w takiej sytuacji, aby użyć wszystkich adresów URL z małymi literami, a następnie przekierować adresy URL zawierające co najmniej jedną wielką literę do wersji z małymi literami. Dlatego na powyższej liście adresów URL przekieruj wszystkie adresy URL do pierwszego adresu URL.

Komentarze

• ” Tak. aby uniknąć problemów z powielaniem treści. ” – Ale wydaje się, że jest odwrotnie? Fakt, że w adresach URL może być rozróżniana wielkość liter (i tak traktują je wyszukiwarki) powoduje wspomniane problemy z powieleniem treści. Gdyby w adresach URL powszechnie nie rozróżniano wielkości liter, nie byłoby problemów z powielaniem treści o różnej wielkości. page-1 byłoby to samo co PAGE-1.
• Myślę, że zła konfiguracja serwera jest tym, co może powodować powielanie treści w przypadku obudowy. Na przykład instrukcja RewriteRule ^request-uri$ /targetscript.php [NC] przechowywana w .htaccess będzie pasować do http://example.com/request-uri i http://example.com/ReQuEsT-Uri, ponieważ [NC] wskazuje, że wielkość liter nie ' nie ma znaczenia przy obliczaniu tego jednego wyrażenia regularnego.

Uwzględnianie wielkości liter ma wartość.

Jeśli jest 26 liter, każda z możliwością wielkich liter, to 52 znaki.

4 znaki dają możliwość 52 * 52 * 52 * 52 kombinacji, równa 7311616 kombinacji.

Jeśli nie możesz użyć wielkich liter, liczba kombinacji wynosi 26 * 26 * 26 * 26 = 456976

Ponad 14 razy więcej kombinacji dla 52 znaków niż jest ich 26. Tak więc w przypadku przechowywania danych adresy URL mogą być krótsze i więcej informacji może być przesyłanych przez sieci z mniejszą ilością przesyłanych danych.

Dlatego widzisz youtube przy użyciu adresów URL, takich jak https://www.youtube.com/watch?v=xXxxXxxX