Bagaimana seharusnya situs web menangani nama host dengan trailing dot?

Saya membaca pertanyaan ini. Bagaimana URL dapat memiliki titik. pada akhirnya, misalnya www.bla.de.? dan sadari bahwa FQDN harus mengandung trailing .untuk label root dari pohon DNS:

example.com. dari pada example.com

Namun, ada masalah yang ditunjukkan dalam artikel blog ini :

Jika Anda tidak mempertimbangkan fakta bahwa pengguna dapat secara tidak sengaja memasukkan nama domain dengan titik di bagian akhir, atau mengikuti tautan yang diterima dari beberapa "penikmat-baik" dan dapatkan nama domain Anda dengan titik di bagian akhir, karena hasil itu dapat menyebabkan konsekuensi yang tak terduga:

1) Jika situs web menggunakan HTTPS, saat bernavigasi ke nama domain dengan titik di bagian akhir, browser akan menampilkan peringatan pada koneksi yang tidak terpercaya.

2) Otentikasi dapat rusak, karena cookie biasanya ditetapkan untuk nama domain tanpa titik di bagian akhir. Pengguna dalam hal ini akan sangat terkejut mengapa ia tidak bisa masuk. Perlu dicatat, bahwa jika Anda menetapkan cookie untuk nama domain dengan titik di bagian akhir, cookie ini tidak akan diteruskan ke nama domain tanpa titik. di akhir dan sebaliknya.

3) JavaScript pada halaman mungkin rusak.

4) Mungkin ada masalah dengan caching halaman situs web (misalnya, https://www.cloudflare.com/tidak menghapus cache halaman jika nama domain memiliki titik pada akhirnya menganggapnya sebagai nama domain yang tidak valid).

5) Jika dalam kondisi dalam konfigurasi server web Anda bergantung pada nama domain tertentu ($ http_host di Nginx,% {HTTP_HOST} di Apache) tanpa titik di bagian akhir, Anda mungkin menghadapi berbagai situasi tak terduga: pengalihan tak terduga, dasar - Masalah otorisasi, dll.

6) Jika server web tidak dikonfigurasi untuk menerima permintaan pada nama domain dengan trailing dot, setiap pengguna yang secara tidak sengaja mengetikkan nama domain dengan trailing dot akan melihat sesuatu seperti Bad Request - Hostname tidak valid.

7) Ada kemungkinan mesin pencari menemukan bahwa sumber daya Anda memiliki duplikat konten, jika seseorang secara tidak sengaja atau sengaja memposting tautan ke halaman web Anda dengan sebuah titik di akhir nama domain.

Saya juga menyadari bahwa http://webmasters.stackexchange.com./tidak 400 Bad Request. Tetapi karena nama domain yang tepat harus mengandung a .di bagian akhir, bukankah kita seharusnya mengeluarkan 400kesalahan atau 301mengarahkan ulang untuk nama host tanpa titik jejak? Apa cara yang tepat untuk menangani masalah ini secara koheren dan konsisten?

Untuk sebagian menjawab pertanyaan Anda, Anda dapat menambahkannya ke htaccess aturan penerusan kanonik. Dalam pengertian HTTP dasar, ia mencari periode sebelum URI dan membuatnya menjadi mekanisme penerusan anti-duplikat apa pun yang Anda gunakan. Berikut adalah contoh termasuk rute sub util util "addon domain":

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]

Apa yang akan dilakukan adalah meneruskan semua yang berikut ke domain HTTP www kanonik:

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

Semua meneruskan ke:

• http://www.domain.com

Ada peringatan untuk ini - seperti yang dinyatakan dalam kutipan blog asli, SSL tidak akan meneruskan dengan benar dan akan menerbangkan peringatan browser atau 400 kesalahan permintaan buruk di sebagian besar contoh server (khususnya dengan HSTS). Ini karena ia melihat "host" SSL dalam kasus penggunaan pasca-TLD. Saya tidak yakin solusinya untuk berurusan dengan peringatan SSL tuan rumah karena itu datang sebelum htaccess dan banyak hal.

Saya suka menganggap titik jejak sebagai akar "nyata" dari Internet, dan bahwa ia tinggal di Virginia, AS. Jika Anda meninggalkan titik, maka beberapa root selalu tersirat. Untuk pengguna normal, ini root yang sama, dan itulah situasi yang akan saya bahas hari ini.

Dengan cara sesat saya, saya benar-benar menemukan trailing dot cukup berguna Jika saya memeriksa situs web orang lain dan saya ingin memulai dengan yang baru, tanpa caching, tanpa cookie, dll, dan saya terlalu malas untuk menghapusnya, saya akan menggunakan browser lain atau saya akan menambahkan titik. Jika situs tidak mengarahkan saya, saya punya semua URL yang belum di-cache untuk semua halaman situs dan sumber daya lainnya.

Sebagai seorang webmaster, saya ingin semua orang dan robot melihat halaman untuk melihatnya dengan URL yang sama, dan karenanya dengan nama host yang sama. Jika nama host bukan yang saya ingin mereka gunakan, saya akan segera melakukan redirect 301 sehingga mereka akan melihat URL yang benar di browser mereka. Untuk situs berbasis PHP saya, saya menangani masalah dalam PHP dan bukan pada file .htaccess atau web.config, karena lebih portabel dan lebih mudah untuk diuji pada pengembangan dan penentuan server. Saya menangani koneksi basis data saya secara bersamaan, karena mereka juga bervariasi di antara server pengembangan / pementasan / produksi.

Ini adalah versi sederhana dari kode khas saya. Perhatikan pengalihan kanonik menjelang akhir.

    $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");
    }   

komentar saya di https://core.trac.wordpress.org/ticket/35248#comment:9 :

balasan saya ke teks dengan tautan pertama ( https://web.archive.org/web/20160604095348/http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/web-fully-qualified-domain-name.html ):

Awalnya, seperti yang didefinisikan dalam RFC 1738 (§ 3.1), bagian "host" dari URL (Skema Internet Umum) selalu dan pasti merupakan nama domain berkualifikasi penuh dan mekanisme konvensional untuk membedakan nama domain berkualifikasi penuh dari non-sepenuhnya- nama domain yang memenuhi syarat tidak berlaku. Apakah itu example.com. atau example.com, tuan rumah dimaksudkan untuk menjadi sama.

- saya pikir dia tidak benar, saya pikir "example.com" tidak diizinkan sama sekali dalam url menurut rfc 1738, dikutip dalam teks kedua, dan saya kutip:

3.1. Sintaksis Skema Internet Umum
        // <user>: <password> @ <host>: <port> / <url-path>
    tuan rumah
        Nama domain yang sepenuhnya memenuhi syarat dari host jaringan

dan "example.com" tidak dapat digunakan dalam header http pada waktu itu, karena rfc 1738 adalah tahun 1994 dan bidang host hanya muncul dengan http 1.1 pada tahun 1997 (Anda dapat memeriksa di wikipedia).

jadi, memang, hanya fqdn yang dibiarkan di url. saya pikir, ini adalah kesalahan pada rfc 1738, karena dengan cara seperti itu membuat (mencoba membuat) "domain relatif" tidak berguna. jika tidak melarangnya, secara teoritis mereka dapat digunakan dalam tag "a" hrefs di situs skrip lokal atau dokumentasi html statis di dalam perusahaan besar yang menggunakan domain relatif, jika browser dan server mendukungnya. tetapi bahkan jika rfc 1738 melarang mereka, orang tidak mematuhinya: mereka terus menggunakan domain tingkat atas dalam bentuk relatif yaitu tanpa trailing dot, jadi penolakan ini oleh rfc 1738 bukanlah masalah praktis yang besar, dan orang memiliki dan menggunakan alternatif ke domain relatif: mereka hanya membuat domain tingkat atas lokal seperti "localhost" (dan menggunakan dan menggunakannya juga tanpa trailing dot).

lalu dia berkata:

Sayangnya, dalam praktiknya browser web selalu melanggar spesifikasi itu dan meneruskan bagian "host" melalui prosedur kualifikasi nama pustaka Klien DNS mereka saat memetakan nama host ke sekumpulan alamat IP. (Misalnya, orang-orang yang menggunakan pustaka klien DNS BIND akan membiarkan set opsi RES_DNSRCH dan tidak akan menambahkan titik trailing akhir jika itu hilang.)

- Saya pikir maksudnya adalah host tanpa trailing dot harus dibuang sebagai kesalahan, dan hanya domain absolut (fqdn) yang harus diteruskan ke dns. Saya pikir mungkin browser memang memberikan semua domain ke dns karena orang menggunakan domain tingkat atas lokal kustom mereka seperti "localhost". dan lagi pula, kemudian di rfc 2396 yang diterbitkan pada tahun 1998, penggunaan domain tingkat atas dalam url tanpa titik yang tertinggal diizinkan.

kemudian penulis (Jonathan de Boyne Pollard) mengutip rfc 2396 dan menyesal tentang hal itu berubah sesuai dengan perilaku manusia yang mapan yaitu standar de facto, mengatakan bahwa akan lebih baik jika browser mematuhi rfc 1738, dan merekomendasikan kepada semua orang untuk menggunakan fqdn saja, pada semua tempat, seperti yang diperintahkan oleh rfc 1738.

- tetapi apa yang akan terjadi jika orang mematuhi rfc 1738? url seperti "http://example.com/test.html "dan"http: //localhost/test.html "semua harus ditulis ulang sebagai"http://example.com./test.html "dan"http://localhost./test.html". Peramban harus menandai host tanpa titik sebagai kesalahan, atau mengarahkan kembali mengklik mereka ke bentuk penuh / absolut dari mereka. semua orang yang mengkonfigurasi domain tingkat atas lokal seperti" localhost "harus mengkonfigurasi server mereka untuk menerima permintaan saja untuk domain seperti "localhost.", atau terima dan redirect [semua url di dalam] "localhost" ke [url yang sesuai di] "localhost.". teks seperti "localhost" akan tetap berguna hanya ketika mengetikkannya di bilah alamat browser, tetapi itu hanya akan penggunaan yang sangat tidak berguna, dan fitur domain relatif tidak diperlukan untuk itu, karena browser mencari domain pada pengetikan. penggunaan mereka dalam sumber html akan menjadi tidak berguna karena akan menyebabkan tautan seperti itu tidak akan berfungsi, atau mengklik semua tautan dengan "localhost" akan memindahkan pengguna ke "localhost."dan itu akan menjadi pengalihan ekstra pada setiap klik (pada tautan semacam itu). jadi, rfc 1738 akan membuat fitur" domain relatif "yang direncanakan sama sekali tidak berguna. jika beberapa perusahaan menggunakan fitur itu, dan menggunakan domain relatif mereka di situs lokal mereka, dan url mereka dengan domain relatif tidak dialihkan ke bentuk absolut oleh browser, sehingga situs mereka berfungsi normal, jika mereka juga mematuhi rfc 1736, mereka akan mengonfigurasi server mereka untuk hanya menerima fqdn, dan mereka harus menulis ulang semua url tersebut dengan fqdn, atau bekerja dengan pengalihan ekstra pada setiap klik pada url tersebut. jika perusahaan itu menyukai memiliki domain pendek seperti "team101" daripada "team101.microsoft.com." di bilah alamat dan sumber html, mereka harus mulai menggunakan domain tingkat atas internal khusus mereka seperti "team101." yaitu suka "localhost. "bukannya subdomain seperti" team101.microsoft.com. "(yang dapat digunakan hanya sebagai" team101 "sebelum mereka memutuskan untuk mematuhi rfc 1738).

-

dan saya telah mengetahui bahwa trailing dot, yang sangat didukung oleh rfc 1738, benar-benar muncul hanya setelah standart tanpa trailing dots! muncul dengan rfc 1034 pada tahun 1987, dikutip dalam tautan kedua, dan saya kutip:

Karena nama domain lengkap berakhir dengan label root, ini mengarah ke a
bentuk cetak yang berakhir dengan titik. Kami menggunakan properti ini untuk membedakan antara:
- string karakter yang mewakili nama domain lengkap
 (sering disebut "absolut"). Misalnya, "poneria.ISI.EDU."
- string karakter yang mewakili label awal a
 nama domain yang tidak lengkap, dan harus diisi oleh
 perangkat lunak lokal menggunakan pengetahuan tentang domain lokal (sering kali
 disebut "relatif"). Misalnya, "poneria" yang digunakan dalam
 Domain ISI.EDU.

rfc 1034 (1987) baru saja mendeklarasikan semua domain yang digunakan, sepertinya mereka semua tanpa trailing dots, menyatakan semuanya sebagai domain relatif! tetapi mereka masih bekerja seperti sebelumnya, jadi mungkin hanya sedikit orang yang tahu tentang itu, dan terus berpikir bahwa mereka secara jelas meminta situs "example.com" yang nyata ketika mereka menggunakan "example.com" tanpa tertinggal titik. sehingga telah menjadi pelanggaran keamanan tambahan dalam beberapa kasus: contoh nyata yang terkenal.com bisa dipalsukan oleh administrator subdomain bahkan jika dia tidak diberi hak untuk membuat domain lokal seperti "localhost." jadi, rfc 1034 juga tidak dirancang dengan sangat baik: sepertinya penulisnya tidak berharap bahwa mungkin itu {tidak diketahui secara luas, sehingga menciptakan pelanggaran keamanan}!

mungkin rfc 1738 (1994) mencoba akhirnya membawa gagasan perbedaan antara domain absolut dan relatif ke khalayak luas dan juga memperbaiki pelanggaran keamanan setelah 6 tahun, {tetapi dengan memperbaiki pelanggaran keamanan dengan melarang domain relatif di url itu membuat domain relatif tidak berguna , {tapi saya pikir mereka mungkin tidak digunakan secara luas, mungkin hanya di beberapa perusahaan besar}}. jadi, apa yang akan [tersisa] dalam hasil rfc 1737, jika itu akan ditaati? - 1) domain relatif yang dideklarasikan pada tahun 1987 akan menjadi akhirnya tidak berguna, jadi, trailing dot, dirancang untuk menunjukkan domain absolut, juga akan menjadi akhirnya tidak berguna dan mubazir "secara hukum" yaitu seperti yang didefinisikan oleh rfcs! (tapi mungkin mereka berencana nanti mengizinkan kembali domain relatif dalam url setelah bertahun-tahun, ketika khalayak luas (masyarakat umum) mulai tahu tentang kemungkinan domain relatif). 2) dan rfc 1737, jika dipatuhi, juga akan memperbaiki pelanggaran keamanan. - tetapi bahkan rfc 1034 tidak akan membuat pelanggaran keamanan jika mencapai massa dan secara luas dipahami bahwa menggunakan domain relatif tidak aman! - jadi, resep utama untuk memperbaikinya adalah menjangkau khalayak luas, dan menerbitkan satu lagi rfc hanyalah satu dari banyak cara untuk melakukannya.

saya pikir sekarang mungkin fitur domain relatif belum menjadi dikenal luas setelah rfc 1034 (tahun 1987) karena penggunaannya terlalu terbatas: hanya di beberapa perusahaan besar atau jaringan lokal penyedia, dan itu adalah fitur tanpa nilai praktis, karena jaringan lokal sudah dapat membuat domain lokal, sehingga fitur itu hanya untuk dirinya sendiri, itu sebenarnya hanya teks yang tidak berguna di rfc yang harus diketahui dan digunakan siapa pun tanpa memiliki manfaat tambahan! tetapi orang-orang menciptakan pelanggaran keamanan kecil dengan secara luas mengabaikan rfc, sementara browser mulai mematuhinya.

saya memeriksa fitur domain relatif kemarin, berfungsi. (tidak apa-apa, karena rfc 2396 (tahun 1998) mengizinkannya kembali setelah rfc 1034 (tahun 1987) ditolak, dan kemudian rfc 3986 (tahun 2005) masih memungkinkan mereka). saya menambahkan akhiran dns di windows 10 - panel kontrol - ... - properti perangkat jaringan - properti ipv4 - tambahan - tab dns. ketika saya menambahkan "google.com" lalu dibuka "http: // mail / "di firefox, ia membuka server google, tetapi tidak dikonfigurasikan untuk bekerja hanya dengan" mail "di header" host "http, jadi saya mendapat halaman" 404 ".

-

balasan saya ke teks dengan tautan kedua ( http://www.dns-sd.org/trailingdotsindomainnames.html ):

dia juga mengutip aturan dalam rfc 1738 dan mengatakan:

Sayangnya, orang yang mengimplementasikan klien browser web tampaknya tidak mengerti apa artinya ini. Saat Anda mengakses situs web, nilai yang paling banyak peramban web masukkan dalam bidang "Host:" adalah apa yang diketik pengguna, bukan apa yang akhirnya digunakan oleh komputer, setelah menerapkan daftar pencarian pengguna DNS untuk menyusun nama yang sepenuhnya memenuhi syarat dari nama parsial. Misalnya, berikut adalah tiga cara berbeda yang dapat digunakan pengguna untuk merujuk pada host "www.example.com." ... Saat mengirim parameter "Host:" ke server web, klien browser web memasukkan apa yang diketik pengguna ("www.example.com.", "Www.example.com", atau "www") sebagai gantinya dari apa yang sebenarnya dicari klien di DNS ("www.example.com." dalam ketiga kasus). ...

- ini tidak terlalu benar (benar), karena rfc 1738 sangat ketat dalam hal ini, dan itu melarang domain relatif di semua url, bahkan jika itu ada di bilah alamat peramban, dan url itu sendiri adalah cara [yang direkomendasikan] untuk membuat referensi apa pun ke situs, bahkan jika orang menulisnya di atas kertas, jadi itu tidak diizinkan bagi pengguna untuk merujuk ke situs itu dalam 3 cara, oleh rfc 1738, jika pengguna akan berpikir bahwa mereka menggunakan URL!

dan sepertinya penulis teks ini (Stuart Cheshire) tidak tahu tentang rfc 2396, jadi teks ini sudah usang.

-

dan bagaimana situasinya saat ini? rfc 3986 (https://tools.ietf.org/html/rfc3986#page-21 ) memungkinkan merujuk ke domain absolut tanpa trailing dot: ia mengatakan "Label domain paling kanan dari nama domain berkualifikasi lengkap dalam DNS dapat diikuti oleh satu". "" dan itu harus digunakan jika "diperlukan untuk membedakan antara nama domain lengkap dan beberapa domain lokal". Saya pikir karena standar de facto hampir tidak pernah diperlukan, jadi wordpress dapat menerima standar de facto dan mengalihkan dari alamat dengan trailing dot ke alamat tanpa itu.