Jak strony internetowe powinny obsługiwać nazwę hosta z kropką?

Przeczytałem to pytanie. W jaki sposób adresy URL mogą mieć kropkę? na końcu, np. www.bla.de.? i zdaj sobie sprawę, że nazwa FQDN powinna zawierać znak końcowy .dla etykiety głównej drzewa DNS:

example.com. zamiast example.com

Istnieją jednak problemy wskazane w tym artykule na blogu :

Jeśli nie bierzesz pod uwagę faktu, że użytkownik może przypadkowo wprowadzić nazwę domeny z kropką na końcu lub skorzystać z linku otrzymanego od „dobrego życzenia” i uzyskać nazwę domeny z kropką na końcu, jako wynik może prowadzić do nieoczekiwanych konsekwencji:

1) Jeśli witryna korzysta z HTTPS, podczas przechodzenia do nazwy domeny z kropką na końcu przeglądarka wyświetli ostrzeżenie o niezaufanym połączeniu.

2) Uwierzytelnianie może zostać zerwane, ponieważ pliki cookie są zwykle ustawiane dla nazwy domeny bez kropki na końcu. Użytkownik w tym przypadku będzie zaskoczony, dlaczego nie może się zalogować. Warto zauważyć, że jeśli ustawisz plik cookie dla nazwy domeny z kropką na końcu, ten plik cookie nie zostanie przekazany do nazwy domeny bez kropki na końcu i odwrotnie.

3) JavaScript na stronie może być uszkodzony.

4) Mogą występować problemy z buforowaniem stron internetowych (na przykład https://www.cloudflare.com/nie usuwa pamięci podręcznej stron, jeśli nazwa domeny ma kropkę na końcu, uznając ją za nieprawidłową nazwę domeny).

5) Jeśli w warunkach konfiguracji serwera WWW korzystasz z konkretnej nazwy domeny ($ http_host w Nginx,% {HTTP_HOST} w Apache) bez kropki na końcu, możesz napotkać różne nieoczekiwane sytuacje: nieoczekiwane przekierowania, podstawowe problemy z autoryzacją itp.

6) Jeśli serwer internetowy nie jest skonfigurowany do akceptowania żądań dotyczących nazwy domeny z kropką końcową, każdy użytkownik, który przypadkowo wpisał nazwę domeny z kropką końcową, zobaczy coś w rodzaju Złe żądanie - niepoprawna nazwa hosta.

7) Możliwe jest, że wyszukiwarki mogą stwierdzić, że Twój zasób ma zduplikowaną treść, jeśli ktoś przypadkowo lub celowo opublikuje linki do twoich stron internetowych z kropką na końcu nazwy domeny.

Zdaję sobie również sprawę, że http://webmasters.stackexchange.com./robi 400 Bad Request. Ale skoro właściwa nazwa domeny powinna zawierać .na końcu, to czy nie powinniśmy wydawać 400błędów lub 301przekierowywać nazw hostów bez kropki? Jaki jest właściwy sposób rozwiązania tego problemu w spójny i konsekwentny sposób?

Aby częściowo odpowiedzieć na twoje pytanie, możesz dodać je do htaccess kanonicznych reguł przekazywania. W podstawowym znaczeniu HTTP szuka okresu przed identyfikatorem URI i przekształca go w dowolny mechanizm przekierowywania, którego używasz. Oto przykład obejmujący wspólną trasę podrzędną „domeny dodatków”:

RewriteCond %{HTTP_HOST} ^domain\.hostdomain\.com(|\.)$ [OR]
RewriteCond %{HTTP_HOST} ^www\.domain\.hostdomain\.com(|\.)$ [OR]
RewriteCond %{HTTP_HOST} ^domain\.com(|\.)$ [OR]
RewriteCond %{HTTP_HOST} ^www.domain\.com\.$
RewriteRule ^(.*)$ "http\:\/\/www\.domain\.com\/$1" [R=301,L]

Powoduje to przekazanie wszystkich następujących elementów do kanonicznej domeny HTTP HTTP:

• domena.hostdomain.com
• domena.hostdomain.com.
• www.domain.hostdomain.com
• www.domain.hostdomain.com.
• domena.com
• domena.com.
• www.domain.com.

Wszyscy przekazują do:

• http://www.domain.com

Jest jednak pewne zastrzeżenie - jak stwierdzono w oryginalnym cytacie na blogu, SSL nie będzie poprawnie przesyłany dalej i wyświetli ostrzeżenie przeglądarki lub błąd 400 złych żądań w większości instancji serwera (szczególnie w przypadku HSTS). Wynika to z tego, że widzi „host” SSL w przypadku użycia po okresie TLD. Nie jestem pewien, jak obejść to ostrzeżenie dotyczące protokołu SSL hosta, ponieważ pojawia się ono przed htaccess i tym podobne.

Lubię myśleć o kropce końcowej jako o „prawdziwym” źródle Internetu i że żyje ona w Wirginii w USA. Jeśli pominiesz kropkę, zawsze sugerowany jest jakiś korzeń. Dla zwykłych użytkowników jest to ten sam katalog główny i taką sytuację omówię dzisiaj.

Na swój perwersyjny sposób uważam, że kropka końcowa jest całkiem przydatna. Jeśli sprawdzam czyjąś stronę internetową i chcę zacząć od nowa, bez buforowania, bez plików cookie itp., I jestem zbyt leniwy, aby je wyrzucić, użyję innej przeglądarki lub dodam kropkę. Jeśli witryna mnie nie przekierowuje, mam zupełnie nowe, niebuforowane adresy URL dla wszystkich stron witryny i innych zasobów.

Jako webmaster chcę, aby wszyscy ludzie i roboty przeglądające stronę przeglądały ją z tym samym adresem URL, a zatem z tą samą nazwą hosta. Jeśli nazwa hosta nie jest tą, której chcę, użyję natychmiastowego przekierowania 301, aby zobaczyli prawidłowy adres URL w przeglądarce. W przypadku moich witryn opartych na PHP radzę sobie z problemem w PHP, a nie w pliku .htaccess lub web.config, ponieważ jest on bardziej przenośny i łatwiej go testować na serwerach programistycznych i testowych. Obsługuję połączenia z bazą danych jednocześnie, ponieważ różnią się one również między serwerami programistycznymi / testowymi / produkcyjnymi.

Oto uproszczona wersja mojego typowego kodu. Zwróć uwagę na kanoniczne przekierowania na koniec.

    $Host = $_SERVER['HTTP_HOST'];
    switch ( $Host ) {
        case 'exampleweb.local':                    // my local dev machine
                $MysqliParams = array(
                        'host'      =>  'localhost',
                        'username'  =>  'root',
                        'passwd'    =>  'snoopy',
                        'dbname'    =>  'exampledb');
                break;
        case 'www.exampleweb.com':                  // the "live" site
                $MysqliParams = array(
                        'host'      =>  'superhost1.net',
                        'username'  =>  'examp302',
                        'passwd'    =>  'anything-but-snoopy',
                        'dbname'    =>  'examp302_db');
                $GoogleAccount = 'UA-13243546-01;   // only enable for live site
                break;
        case 'exampleweb.mystagingsite.net':        // the client preview site
                $MysqliParams = array(
                        'host'      =>  'superhost1.net',
                        'username'  =>  'examp302',
                        'passwd'    =>  'anything-but-snoopy',
                        'dbname'    =>  'examp302_staging');
                break;
        case 'exampleweb.com':                  // canonical redirects 
        case 'exampleweb.com.':
        case 'www.exampleweb.com.':
                header('HTTP/1.1 301 Moved Permanently');
                header("Location: http://www.exampleweb.com");
                exit;
        default:
                die("invalid hostname $Host");
    }   

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.