Web siteleri, ana bilgisayar adını sondaki nokta ile nasıl ele almalıdır?

Bu soruyu okudum URL'lerin nasıl bir noktası olabilir? sonunda, örneğin www.bla.de.? ve FQDN'nin .DNS ağacının kök etiketi için bir iz içermesi gerektiğini unutmayın :

example.com. onun yerine example.com

Ancak, bu blog makalesinde belirtildiği gibi sorunlar var :

Kullanıcının yanlışlıkla alan adını sonunda bir nokta ile girebileceğini veya bazı "iyi niyetli" kişilerden alınan bir bağlantıyı izleyebileceğini ve alan adının sonunda nokta ile sonuç beklenmedik sonuçlara yol açabilir:

1) Web sitesi HTTPS kullanıyorsa, sonunda nokta bulunan etki alanı adına giderken tarayıcı güvenilmeyen bağlantı konusunda uyarıyı görüntüler.

2) Alan adı için çerezler genellikle sonunda nokta olmadan çerezler ayarlandığından kimlik doğrulama bozulabilir. Bu durumda kullanıcı neden giriş yapamayacağına oldukça şaşıracaktır. Sonunda nokta olan bir alan adı için bir çerez ayarlarsanız, bu çerez nokta olmadan alan adına geçirilmez. sonunda ve tam tersi.

3) Sayfadaki JavaScript bozulmuş olabilir.

4) Web sitesi sayfalarının önbelleğe alınmasında sorunlar olabilir (örneğin, https://www.cloudflare.com/alan adının sonunda geçersiz bir alan adı olarak bir nokta varsa sayfa önbelleğini temizlemez).

5) Web sunucusu yapılandırmasındaki koşullarda, sonunda nokta olmadan belirli bir alan adına (Nginx'te $ http_host, Apache'de% {HTTP_HOST}) güveniyorsanız, beklenmedik durumlarla karşılaşabilirsiniz: beklenmedik yönlendirmeler, temel - yetkilendirme sorunları vb.

6) Web sunucusu, etki alanı adında sondaki nokta ile istekleri kabul edecek şekilde yapılandırılmamışsa, yanlışlıkla nokta ile bir etki alanı adı yazmış olan herhangi bir kullanıcı, Kötü İstek - Geçersiz Ana Bilgisayar Adı gibi bir şey görür.

7) Birisi yanlışlıkla veya kasıtlı olarak etki alanı adının sonunda bir nokta ile web sayfalarınıza bağlantı gönderirse, arama motorlarının kaynağınızın yinelenen bir içeriğe sahip olduğunu bulması mümkündür.

Ben de bunun http://webmasters.stackexchange.com./bir farkına varıyorum 400 Bad Request. Ancak, uygun alan adı .sonunda bir içermesi gerektiğinden , son nokta olmadan ana bilgisayar adları için 400hata vermemeli veya 301yönlendirmemeliyiz? Bu konuyu tutarlı ve tutarlı bir şekilde ele almanın doğru yolu nedir?

Sorunuzu kısmen cevaplamak için, htaccess kanonik iletici kurallarına ekleyebilirsiniz. Temel HTTP anlamda, URI'den önce bir süre arar ve kullandığınız yinelenen anti-yönlendirme mekanizmasında çalışır. Yaygın bir "addon domain" alt util rotasını içeren bir örnek:

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]

Bunun yapacağı şey aşağıdakilerin tümünü standart bir HTTP www alanına iletmektir:

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

İleriye yönelik:

• http://www.domain.com

Buna rağmen bir uyarı var - orijinal blog alıntısında belirtildiği gibi, SSL doğru şekilde yönlendirilmeyecek ve çoğu sunucu örneğinde (HSTS ile esp) bir tarayıcı uyarısı veya 400 hatalı istek hatası iletecektir. Bunun nedeni, TLD sonrası bir kullanım durumunda "ana bilgisayar" SSL'sini görmesidir. Ben htaccess ve şeyler önce geliyor çünkü ana SSL uyarı ile başa çıkmak için bir geçici çözüm emin değilim.

Son noktayı internetin "gerçek" kökü olarak düşünmeyi ve ABD'nin Virginia eyaletinde yaşadığını düşünüyorum. Noktayı dışarıda bırakırsanız, her zaman bir kök ima edilir. Normal kullanıcılar için aynı köktür ve bugün tartışacağım durum budur.

Sapık şekilde, aslında takip eden noktayı oldukça kullanışlı buluyorum. Başka birinin web sitesini kontrol edersem ve önbellekleme, çerez vb.İle yeni başlamak istersem ve bunları temizlemek için çok tembelim, farklı bir tarayıcı kullanacağım ya da noktayı ekleyeceğim. Site beni yeniden yönlendirmezse, sitenin tüm sayfaları ve diğer kaynakları için tamamen önbelleğe alınmamış URL'lerim olur.

Bir web yöneticisi olarak, bir sayfayı görüntüleyen tüm kullanıcıların ve robotların sayfayı aynı URL ile ve dolayısıyla aynı ana makine adıyla görüntülemelerini istiyorum. Ana bilgisayar adı kullanmasını istediğim kişi değilse, tarayıcılarında doğru URL'yi görmeleri için hemen 301 yönlendirmesi yapacağım. PHP tabanlı sitelerim için, sorunu daha taşınabilir ve geliştirme ve hazırlama sunucuları üzerinde test etmek daha kolay olduğu için PHP'de değil .htaccess veya web.config dosyasında değil. Veritabanı bağlantılarımı aynı anda idare ediyorum, çünkü bunlar aynı zamanda geliştirme / hazırlama / üretim sunucuları arasında da değişiyor.

İşte benim tipik kodun basitleştirilmiş bir versiyonu. Sona doğru kurallı yönlendirmeleri not edin.

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

https://core.trac.wordpress.org/ticket/35248#comment:9 adresindeki yorumum :

ilk bağlantıdan metne cevabım ( https://web.archive.org/web/20160604095348/http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/web-fully-qualified-domain-name.html ):

Başlangıçta, RFC 1738'de (§ 3.1) tanımlandığı gibi, (Ortak İnternet Şeması) URL'sinin "ana bilgisayar" kısmı her zaman ve açık bir şekilde tam nitelikli bir alan adı ve tam nitelikli alan adlarını tam olmayan alan adlarından tamamen ayırmak için geleneksel mekanizmadır. nitelikli alan adları geçerli değildi. Example.com olup olmadığı. veya example.com, ana bilgisayarın aynı olması amaçlanmıştır.

- Bence doğru değil, bence "example.com" rfc 1738'e göre URL'lerde hiç izin verilmedi, ikinci metinde alıntılandı ve alıntı yapıyorum:

3.1. Ortak İnternet Şeması Sözdizimi
        // <kullanıcı>: <parola> @ <konak>: <port> / <url_yolu>
    evsahibi
        Bir ağ ana bilgisayarının tam etki alanı adı

ve "example.com" şu anda http başlıklarında kullanılamadı, çünkü rfc 1738 1994'tür ve ana bilgisayar alanı yalnızca 1997'de http 1.1 ile birlikte görünür (wikipedia'da kontrol edebilirsiniz).

yani, url'lerde sadece fqdn'a izin verildi. Bence, bu rfc 1738'de bir hataydı, çünkü bu şekilde "göreli alanlar" özelliğini işe yaramaz hale getirmeye çalıştı. izin vermediyse, teorik olarak, tarayıcılar ve sunucular destekliyorsa, yerel komut dosyası verilen sitelerde "a" etiketi href'lerinde veya göreli alan kullanan büyük şirketlerin içindeki statik html belgelerinde teorik olarak kullanılabilirler. ancak rfc 1738 onlara izin vermese bile, insanlar buna uymadı: göreceli formda üst düzey etki alanlarını kullanmaya devam ettiler, yani izleyen nokta olmadan, bu yüzden rfc 1738'in bu izinsizleşmesi büyük bir pratik sorun değildi ve insanlar bir alternatifi vardı ve kullandılar göreceli alan adlarına: "localhost" gibi yerel üst düzey alan adları oluşturdular (ve bunları son nokta olmadan da kullandılar ve kullandılar).

sonra diyor ki:

Ne yazık ki, uygulamada web tarayıcıları her zaman bu belirtimi ihlal etmiş ve ana makine adını bir IP adresleri kümesiyle eşlerken DNS İstemci kitaplıklarının ad yeterlilik yordamlarından "ana bilgisayar" bölümünü geçirmiştir. (Örneğin, BIND DNS İstemcisi kitaplığını kullananlar RES_DNSRCH seçeneğini ayarlanmış olarak bırakır ve eksikse son son noktayı eklemez.)

- Bence o nokta olmayan ana bilgisayar sadece hata olarak atılması gerektiğini ve sadece mutlak etki alanları (fqdn) dns geçirilmesi anlamına geliyordu. insanlar "localhost" gibi özel yerel üst düzey etki alanlarını kullandıkları için muhtemelen tarayıcılar dns için tüm etki alanlarını geçti düşünüyorum. ve yine de, daha sonra 1998'de yayınlanan rfc 2396'da, son noktaların bulunmadığı URL'lerde üst düzey alanların kullanımına izin verildi.

daha sonra yazar (Jonathan de Boyne Pollard) rfc 2396'dan alıntı yapıyor ve bunun hakkında kurulan insan davranışına göre değiştiğinden pişmanlık duyuyor, yani fiili standartlar, tarayıcılar 17fc 1738'e itaat ederse ve tüm insanlara sadece fqdn kullanmasını önerir tüm yerler, rfc 1738 tarafından komuta edildiği gibi.

- ama insanlar 17f rfc 1738'e uysaydı ne olurdu? URL'ler "http://example.com/test.html "ve"http: //localhost/test.html "hepsi yeniden yazılmak zorundaydı"http://example.com./test.html "ve"http://localhost./test.htmlmsgstr "tarayıcı, noktaları barındırmayan ana bilgisayarları hata olarak işaretlemeli veya tam / mutlak formuna tıklamaya yönlendirmelidir." localhost "gibi yerel üst düzey alan adlarını yapılandıran tüm kişilerin, sunucularını yalnızca istekleri kabul edecek şekilde yapılandırması gerekir. "localhost" gibi etki alanları için veya [yerel içindeki tüm URL'ler] "localhost" u kabul edin ve "localhost" içindeki ilgili URL'lere yönlendirin. "localhost" gibi metinler yalnızca tarayıcı adres çubuğuna yazılırken yararlı olur, ancak yalnızca çok işe yaramaz bir kullanım olurdu ve bunun için göreli alan özelliği gerekli değildir, çünkü tarayıcılar yazarken alan adlarını arar. html kaynağında bunların kullanımı işe yaramaz, çünkü bu tür bağlantıların çalışmamasına veya tümünü tıklamasına neden olur "localhost" ile olan bağlantılar kullanıcıyı "localhost" a taşır."ve her tıklamada (bu tür bağlantılarda) fazladan yönlendirme olur. bu nedenle, rfc 1738 planlanan" göreli alan "özelliğini tamamen işe yaramaz hale getirecektir. bazı şirketler bu özelliği kullandı ve göreli alanlarını yerel sitelerinde kullandıysa, ve göreli alanlara sahip URL'leri tarayıcılar tarafından mutlak forma yönlendirilmedi, bu yüzden siteleri normal şekilde çalıştı, eğer 17fc'ye uyuyorlarsa, sunucularını sadece fqdn'yi kabul edecek şekilde yapılandıracaklar ve bu tür tüm URL'lerini yeniden yazmak zorunda kalacaklardı. fqdn veya bu tür URL'lerin her tıklanmasında fazladan yönlendirme ile çalışın. eğer şirketler adres çubuklarında ve html kaynaklarında "team101.microsoft.com" yerine "team101" gibi kısa etki alanına sahip olmayı sevdiyse, kullanmaya başlamak zorunda kalacaklardı. "team101" gibi özel dahili üst düzey alan adları."team101.microsoft.com" gibi alt alan adları yerine "rfc 1738'e uymaya karar vermeden önce yalnızca" team101 "olarak kullanılabilir).

-

ve ben rfc 1738 tarafından çok güçlü bir şekilde desteklenen son nokta, gerçekten sadece son nokta olmadan standart sonra ortaya çıktı öğrendim! 1987'de rfc 1034 ile ortaya çıktı, ikinci linkte alıntılandı ve alıntı yapıyorum:

Tam bir alan adı kök etiketiyle sona erdiğinden,
nokta ile biten basılı form. Bu özelliği aşağıdakileri ayırt etmek için kullanırız:
- tam bir alan adını temsil eden bir karakter dizesi
 (genellikle "mutlak" olarak adlandırılır). Örneğin, "poneria.ISI.EDU."
- a'nın başlangıç ​​etiketlerini temsil eden bir karakter dizesi
 tamamlanmamış ve tamamlaması gereken alan adı
 yerel etki alanı bilgisini kullanan yerel yazılımlar (genellikle
 "göreli" olarak adlandırılır). Örneğin, "poneria"
 ISI.EDU etki alanı.

rfc 1034 (1987) sadece kullanılan tüm alan adlarını açıkladı, hepsinin sonunda nokta yok gibi göründü, hepsini göreli alan adı olarak ilan etti! ancak yine de daha önce olduğu gibi çalıştılar, bu yüzden muhtemelen birkaç kişi bunu biliyordu ve "example.com" sitesini izleyen nokta kullanmadan açıkça benzersiz bir gerçek "example.com" sitesi talep ettiklerini düşünmeye devam etti. bu yüzden bazı durumlarda ek bir güvenlik ihlali haline gelmiştir: ünlü real example.com, "localhost" gibi herhangi bir yerel etki alanı yapma hakkı verilmemiş olsa bile bir alt etki alanı yöneticisi tarafından aldatılabilir. yani, rfc 1034 de çok iyi tasarlanmamıştı: yazarları belki de {yaygın olarak bilinmeyecek, bu yüzden güvenlik ihlali yaratacağını} beklemiyorlardı!

muhtemelen rfc 1738 (1994) nihayet mutlak ve göreli alanlar arasındaki ayrım fikrini geniş kitleye getirmeye ve aynı zamanda 6 yıl sonra bu güvenlik ihlalini düzeltmeye çalıştı, ancak URL'lerde göreceli alanlara izin vermeyerek güvenlik ihlalini düzeltti , {ancak bence muhtemelen yaygın olarak kullanılmadılar, muhtemelen sadece bazı büyük şirketlerde}}. öyleyse, 1737 rfc sonucunda uyulursa [sol] ne olurdu? - 1) 1987'de beyan edilen göreceli alanlar nihayet işe yaramaz hale gelir, bu nedenle mutlak alan göstermek için tasarlanan son nokta da nihayet işe yaramaz ve "yasal olarak" gereksiz olur, yani rfcs tarafından tanımlandığı gibi! (ancak daha sonra geniş kitlelerin (genel halk) göreli alanların olasılığını öğrenmeye başladığı yıllar sonra URL'lerde göreli alanlara yeniden izin vermeyi planladılar). 2) ve rfc 1737, uyulması halinde güvenlik ihlalini de giderir. - ancak rfc 1034 bile kitlelere ulaşırsa güvenlik ihlalini oluşturmaz ve göreceli alan adı kullanmanın güvenli olmadığı yaygın olarak anlaşılmıştır! - Yani, düzeltmek için ana tarif geniş kitleye ulaşıyordu ve bir rfc daha yayınlamak bunu yapmanın birçok yolundan sadece biriydi.

şimdi muhtemelen göreceli etki alanı özelliğinin rfc 1034'ten (1987) sonra yaygın olarak bilinmediğini düşünüyorum çünkü çok sınırlı kullanımdaydı: sadece bazı büyük şirketlerin veya sağlayıcıların yerel ağlarında ve pratik değeri olmayan bir özellikti, Yerel ağlar zaten herhangi bir yerel etki alanı yapabildiğinden, bu özellik sadece kendisi içindi, aslında herhangi bir ek faydası olmadan herkesin bilmesi ve kullanması gereken rfc'de sadece işe yaramaz bir metindi! ancak tarayıcılar buna uymaya başlarken, insanlar rfc'yi görmezden gelerek küçük güvenlik ihlalini yarattılar.

dün göreli etki alanları özelliğini kontrol etti, çalışıyor. (tamam, çünkü rfc 2396 (1998) rfc 1034 (1987) reddedildikten sonra yeniden izin verdi ve daha sonra rfc 3986 (2005) hala izin veriyor). Windows 10'da dns soneki ekledim - kontrol paneli - ... - ağ cihazı özellikleri - ipv4 özellikleri - ek - dns sekmesi. "google.com" i eklediğimde açtım "http: // mail / "firefox'ta, google'ın sunucusunu açtı, ancak http" host "başlığında yalnızca" mail "ile çalışmak üzere yapılandırılmadı, bu yüzden" 404 "sayfası gibi bir şey aldım.

-

metnin cevabını ikinci linkten ( http://www.dns-sd.org/trailingdotsindomainnames.html ):

ayrıca 17fc 1738'de kuralı belirtiyor ve şöyle diyor:

Ne yazık ki, web tarayıcı istemcilerini uygulayan insanlar bunun ne anlama geldiğini anlamıyorlardı. Bir web sitesine eriştiğinizde, çoğu web tarayıcısının "Ana Bilgisayar:" alanına koyduğu değer, DNS kullanıcı arama listesini uygulandıktan sonra DNS kullanıcı arama listesini uyguladıktan sonra bilgisayarın gerçekte kullandığı şey değildir. kısmi ad. Örneğin, kullanıcının "www.example.com" ana bilgisayarına başvurabilmesinin üç farklı yolu vardır. ... "Host:" parametresini web sunucusuna gönderirken, web tarayıcı istemcisi kullanıcının yazdıklarını ("www.example.com.", "Www.example.com" veya "www") koyar. müşterinin aslında DNS'de aradığı şeyin (üç durumda da "www.example.com") olduğunu gösterir. ...

- bu çok doğru değil (doğru), çünkü rfc 1738 bu konuda çok katıydı ve tarayıcının adres çubuğunda olsa bile URL'nin göreli alan adlarına izin vermiyordu ve URL'nin kendisi [önerilen] yöntemdir insanlar kağıda yazsa bile sitelere yapılan göndermeler, bu yüzden kullanıcıların URL'yi kullandıklarını düşünecek olsaydı, bu siteye rfc 1738 tarafından 3 şekilde başvurmasına izin verilmedi!

ve bu metnin yazarı (Stuart Cheshire) rfc 2396 hakkında bilmiyordu, bu yüzden bu metin eski.

-

ve bugünlerde durum nedir? rfc 3986 (https://tools.ietf.org/html/rfc3986#page-21 ) son nokta olmadan mutlak etki alanına göndermeye izin verir: "DNS'de tam nitelikli bir etki alanı adının en sağdaki etki alanı etiketini tek bir izleyebilir" yazıyor. "" ise ve "tam alan adı ile bazı yerel alan adlarını birbirinden ayırmak" gerekiyorsa kullanılmalıdır. Ben de facto standartları nedeniyle neredeyse hiç gerekli olmadığını düşünüyorum, bu yüzden wordpress de facto standardını kabul edebilir ve sondaki noktadan adres olmadan adrese yönlendirebilir.