mój komentarz na https://core.trac.wordpress.org/ticket/35248#comment:9 :
moja odpowiedź na tekst pierwszym linkiem ( https://web.archive.org/web/20160604095348/http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/web-fully-qualified-domain-name.html ):
Pierwotnie, jak zdefiniowano w RFC 1738 (§ 3.1), część „hosta” adresu URL (Common Internet Scheme) była zawsze i jednoznacznie w pełni kwalifikowaną nazwą domeny oraz konwencjonalnym mechanizmem odróżniania w pełni kwalifikowanych nazw domen od niepełnych- kwalifikowane nazwy domen nie miały zastosowania. Czy to example.com. lub example.com, host miał być taki sam.
- myślę, że nie ma racji, myślę, że „przyklad.com” nie był w ogóle dozwolony w adresach URL zgodnie z rfc 1738, jest cytowany w drugim tekście i cytuję to:
3.1 Wspólna składnia schematu internetowego
// <użytkownik>: <hasło> @ <host>: <port> / <ścieżka_url>
gospodarz
W pełni kwalifikowana nazwa domeny hosta sieciowego
i „example.com” nie mogły być wówczas używane w nagłówkach http, ponieważ rfc 1738 pochodzi z 1994 roku, a pole hosta pojawiło się tylko z http 1.1 w 1997 roku (można to sprawdzić w wikipedii).
tak więc w adresach URL pozostawiono tylko fqdn. myślę, że był to błąd w rfc 1738, ponieważ w ten sposób uczyniłem (próbowałem uczynić) funkcję „domen względnych” bezużyteczną. jeśli to nie zabraniałoby, teoretycznie mogłyby być użyte w tagach „a” hrefs w lokalnych witrynach ze skryptami lub w statycznej dokumentacji HTML wewnątrz dużych firm, które korzystały z domen względnych, jeśli przeglądarki i serwery to obsługiwały. ale nawet jeśli rfc 1738 ich nie zezwalał, ludzie nie przestrzegali go: nadal używali domen najwyższego poziomu w formie względnej, tj. bez kropki końcowej, więc to niedopuszczenie przez rfc 1738 i tak nie było dużym problemem praktycznym, a ludzie mieli i stosowali alternatywę do domen względnych: właśnie utworzyli lokalne domeny najwyższego poziomu, takie jak „localhost” (i użyły ich i używają ich również bez kropki).
potem mówi:
Niestety, w praktyce przeglądarki internetowe zawsze łamały tę specyfikację i przepuszczały część „hosta” poprzez procedury kwalifikowania nazw swoich bibliotek klienta DNS podczas mapowania nazwy hosta na zestaw adresów IP. (Na przykład te, które korzystały z biblioteki klienta BIND DNS pozostawiłyby zestaw opcji RES_DNSRCH i nie dołączałyby końcowej kropki końcowej, gdyby jej brakowało).
- myślę, że miał na myśli, że hosty bez kropki powinny być po prostu wyrzucone jako błąd, a tylko domeny absolutne (fqdn) powinny być przekazywane do dns. myślę, że prawdopodobnie przeglądarki przekazały wszystkie domeny do dns, ponieważ ludzie używali niestandardowych lokalnych domen najwyższego poziomu, takich jak „localhost”. w każdym razie później w rfc 2396 opublikowanym w 1998 r. dozwolone było używanie domen najwyższego poziomu w adresach URL bez kropek końcowych.
następnie autor (Jonathan de Boyne Pollard) cytuje RFC 2396 i żałuje, że zmienił się zgodnie z ustalonym ludzkim zachowaniem, tj. de facto standardami, powiedział, że lepiej byłoby, gdyby przeglądarki zastosowały RFC 1738 i zaleca wszystkim ludziom, aby używali tylko FQDN, w wszystkie miejsca, jak dowodził rfc 1738.
- ale co by się stało, gdyby ludzie byli posłuszni RFC 1738? adresy URL takie jak „http://example.com/test.html ”i„http: //localhost/test.html „wszystko trzeba było przepisać jako”http://example.com./test.html ”i„http://localhost./test.html". przeglądarka musiałaby albo oznaczyć hosty bez kropek jako błąd, albo przekierować je klikając na ich pełną / bezwzględną formę. wszyscy ludzie, którzy skonfigurowali lokalne domeny najwyższego poziomu, takie jak" localhost ", musieliby skonfigurować swoje serwery, aby akceptowały tylko żądania dla domen takich jak „localhost.” lub zaakceptuj i przekieruj [wszystkie adresy URL] „localhost” na [odpowiadające adresy URL] „localhost.”. tekst taki jak „localhost” pozostanie użyteczny tylko podczas wpisywania go w pasku adresu przeglądarki, ale to byłoby bardzo bezużyteczne, a funkcja domeny względnej nie jest do tego potrzebna, ponieważ przeglądarki wyszukują domeny podczas pisania. użycie ich w źródle HTML byłoby bezużyteczne, ponieważ prowadziłoby do tego, że takie linki nie działałyby lub klikanie wszystkich linki z „localhost” przeniosłyby użytkownika do „localhost”.”i byłoby to dodatkowe przekierowanie za każdym kliknięciem (na takich linkach). więc rfc 1738 sprawiłby, że planowana funkcja„ domeny względnej ”byłaby całkowicie bezużyteczna. gdyby jakaś firma korzystała z tej funkcji i używała swoich domen względnych w swoich lokalnych witrynach, a ich adresy URL z domenami względnymi nie były przekierowywane przez przeglądarki do bezwzględnej formy, więc ich strony działały normalnie, jeśli również byłyby posłuszne rfc 1736, skonfigurowałyby swoje serwery, aby akceptowały tylko fqdn, i musiałyby albo przepisać wszystkie swoje adresy URL za pomocą fqdn lub pracuj z dodatkowym przekierowaniem przy każdym kliknięciu takich adresów URL. jeśli firmy lubiły mieć krótką domenę, taką jak „team101” zamiast „team101.microsoft.com.” w swoich paskach adresowych i źródłach HTML, musieliby zacząć korzystać ich niestandardowe wewnętrzne domeny najwyższego poziomu, takie jak „team101”.localhost. ”zamiast subdomen takich jak„ team101.microsoft.com. ”(które mogą być użyte jako„ team101 ”, zanim zdecydują się zastosować RFC 1738).
-
i dowiedziałem się, że kropka końcowa, która była tak mocno wspierana przez rfc 1738, naprawdę pojawiła się dopiero po standardzie bez kropek końcowych! pojawił się z rfc 1034 w 1987 roku, jest cytowany w drugim linku i cytuję to:
Ponieważ pełna nazwa domeny kończy się etykietą root, prowadzi to do
wydrukowany formularz, który kończy się kropką. Używamy tej właściwości do rozróżnienia między:
- ciąg znaków reprezentujący pełną nazwę domeny
(często nazywany „absolutnym”). Na przykład „poneria.ISI.EDU”.
- ciąg znaków reprezentujący początkowe etykiety a
nazwa domeny, która jest niekompletna i powinna zostać uzupełniona przez
lokalne oprogramowanie wykorzystujące wiedzę o lokalnej domenie (często
nazywany „względnym”). Na przykład „poneria” używany w
Domena ISI.EDU.
rfc 1034 (z 1987 r.) właśnie zadeklarował wszystkie używane domeny, wygląda na to, że wszystkie były pozbawione kropek, zadeklarował je wszystkie jako domeny względne! ale nadal działały jak poprzednio, więc prawdopodobnie niewiele osób wiedziało o tym i nadal myślało, że jednoznacznie prosi o unikalną prawdziwą witrynę „przyklad.com”, gdy używa „przyklad.com” bez kropki. dlatego w niektórych przypadkach stało się to dodatkowym naruszeniem bezpieczeństwa: słynny prawdziwy example.com może zostać sfałszowany przez administratora subdomeny, nawet jeśli nie otrzymałby uprawnień do utworzenia domeny lokalnej, takiej jak „localhost”. więc rfc 1034 również nie został bardzo dobrze zaprojektowany: wydaje się, że jego autorzy nie spodziewali się, że być może {nie będzie powszechnie znany, co spowoduje naruszenie bezpieczeństwa}!
prawdopodobnie rfc 1738 (1994) w końcu próbował wprowadzić rozróżnienie między domenami bezwzględnymi i względnymi dla szerokiego grona odbiorców, a także naprawić to naruszenie bezpieczeństwa po 6 latach, {ale naprawiając naruszenie bezpieczeństwa poprzez niedopuszczenie względnych domen w adresach URL, uczyniło domeny względne bezużytecznymi , {ale myślę, że prawdopodobnie nie były szeroko stosowane, prawdopodobnie tylko w niektórych dużych firmach}}. więc co by [pozostało] w wyniku RFC 1737, gdyby byłoby to przestrzegane? - 1) względne domeny zadeklarowane w 1987 r. Stałyby się w końcu bezużyteczne, więc kropka końcowa, zaprojektowana w celu pokazania domeny absolutnej, stałaby się w końcu również bezużyteczna i zbędna „legalnie”, tj. Zgodnie z definicją rfcs! (ale może planowali później ponownie zezwolić na względne domeny w adresach URL po wielu latach, kiedy szeroka publiczność (ogół społeczeństwa) zaczyna wiedzieć o możliwości względnych domen). 2) i rfc 1737, jeśli byłby przestrzegany, naprawiłby również naruszenie bezpieczeństwa. - ale nawet rfc 1034 nie stworzyłby naruszenia bezpieczeństwa, gdyby osiągnął masę i było szeroko rozumiane, że używanie względnej domeny nie jest bezpieczne! - główny przepis na naprawę dotarł do szerokiego grona odbiorców, a opublikowanie jeszcze jednego pliku rfc było tylko jednym z wielu sposobów.
myślę teraz, że prawdopodobnie względna funkcja domeny nie stała się powszechnie znana po rfc 1034 (z 1987 r.), ponieważ była zbyt ograniczona w użyciu: tylko w niektórych dużych firmach lub lokalnych sieciach lokalnych i była to funkcja bez praktycznej wartości, ponieważ sieci lokalne mogły już utworzyć dowolną domenę lokalną, więc ta funkcja była tylko dla siebie, w rzeczywistości był to po prostu bezużyteczny tekst w rfc, który każdy powinien znać i używać bez żadnych dodatkowych korzyści! ale ludzie stworzyli małe naruszenie bezpieczeństwa, szeroko ignorując RFC, podczas gdy przeglądarki zaczęły go przestrzegać.
wczoraj sprawdziłem funkcję domen względnych, działa. (jest w porządku, ponieważ rfc 2396 (z 1998 r.) ponownie zezwolił na to po odrzuceniu rfc 1034 (z 1987 r.), a później rfc 3986 (z 2005 r.) nadal na to zezwala). dodałem sufiks dns w Windows 10 - panel sterowania - ... - właściwości urządzenia sieciowego - właściwości ipv4 - dodatkowe - zakładka dns. kiedy dodałem „google.com”, a następnie otworzyłem „http: // mail / ”w przeglądarce Firefox, otworzył serwer Google, ale nie został skonfigurowany do pracy z„ mailem ”w nagłówku http„ host ”, więc mam coś w rodzaju strony„ 404 ”.
-
moja odpowiedź na tekst drugim linkiem ( http://www.dns-sd.org/trailingdotsindomainnames.html ):
cytuje także regułę w rfc 1738 i mówi:
Niestety osoby wdrażające klientów przeglądarek internetowych nie rozumiały, co to znaczy. Gdy uzyskujesz dostęp do strony internetowej, wartość, którą większość przeglądarek internetowych umieszcza w polu „Host:”, jest tym, co wpisał użytkownik, a nie tym, co komputer faktycznie wykorzystał, po zastosowaniu listy wyszukiwania użytkownika DNS w celu utworzenia w pełni kwalifikowanej nazwy z częściowe imię. Na przykład oto trzy różne sposoby, w jakie użytkownik może odwoływać się do hosta „www.example.com”. ... Podczas wysyłania parametru „Host:” do serwera WWW klient przeglądarki internetowej wprowadza to, co wpisał użytkownik („www.example.com.”, „Www.example.com” lub „www”) tego, co klient faktycznie szukał w DNS („www.example.com.” we wszystkich trzech przypadkach). ...
- nie jest to zbyt prawdziwe (poprawne), ponieważ rfc 1738 był bardzo rygorystyczny w tym względzie i nie pozwalał na względne domeny we wszystkich adresach URL, nawet jeśli znajduje się w pasku adresu przeglądarki, a sam adres URL jest [zalecanym] sposobem tworzenia wszelkie odniesienia do stron, nawet jeśli ludzie piszą to na papierze, więc użytkownicy nie mogli odwoływać się do tej witryny w ten 3 sposób, do rfc 1738, jeśli użytkownicy będą myśleć, że użyli adresu URL!
i wydaje się, że autor tego tekstu (Stuart Cheshire) nie wiedział o rfc 2396, więc ten tekst jest nieaktualny.
-
a jaka jest obecnie sytuacja? rfc 3986 (https://tools.ietf.org/html/rfc3986#page-21 ) pozwala odwoływać się do domeny absolutnej bez kropki: mówi „Po prawej stronie etykiety w pełni kwalifikowanej nazwy domeny w DNS może występować pojedynczy”. „” i że należy go użyć, jeśli „konieczne jest rozróżnienie pełnej nazwy domeny od niektórych domen lokalnych”. Myślę, że ze względu na faktyczne standardy prawie nigdy nie jest to konieczne, więc Wordpress może zaakceptować de facto standard i przekierować z adresu za pomocą kropki na adres bez niego.