- Konu sahibi
- #1
WWW sürümüne yönlendirme,
Yönlendirmeden önce hem kaynak hem hedef alan adının doğru sunucuya ulaştığını doğrulayın. HTTPS ile gelen kaynak istekte de TLS bağlantısı yönlendirmeden önce kurulur; bu yüzden yalnız hedefin değil, ziyaret edilecek kaynak HTTPS adının da geçerli sertifikası bulunmalıdır.
Aşağıdaki örnek Apache 2.4, etkin mod_rewrite ve ilgili dizinde izin verilmiş FileInfo kuralları içindir. HTTPS bağlantısının Apache üzerinde sonlandığını varsayar. CDN veya yük dengeleyici HTTPS'yi önce sonlandırıyorsa bu kodu doğrudan kullanmayın: origin tarafında
Bu durumda dış isteğin protokolü, yalnız denetlediğiniz ve ilgili başlığı her istekte yeniden yazan güvenilir proxy üzerinden belirlenmelidir. İnternetten gelen herhangi bir
Belge kökündeki mevcut dosyayı koruyarak, CMS'nin dahili yönlendirme kurallarından önce uygulanacak konumu belirleyin. Alan adı değerlerini kendi sitenize göre değiştirin. İlk denemelerde geçici 302 kullanın:
İlk koşul yalnız tanımlanan iki ana makine adını kabul eder. Sonraki iki koşul, ana makine adının WWW olmaması veya bağlantının HTTPS olmaması durumlarını birleştirir. Böylece uygun kaynaktan gelen istek doğrudan sabit HTTPS+WWW hedefine gider. İstek zaten
Tablo yalnız bu kuralın davranışını gösterir. CDN, uygulama veya başka bir .htaccess kuralı ek yönlendirme üretirse gerçek zincir daha uzun olabilir. Hedefte sayfanın başarılı yanıt verdiğini ayrıca inceleyin.
Kaynak ve hedefi aynı koşula yakalayıp sürekli yönlendirmek, HTTPS bilgisini proxy arkasında yanlış yorumlamak ve hedefi denetlenmemiş Host başlığından üretmek başlıca sorunlardır. Ayrıca
302 ve 301 bazı istemcilerde POST'u GET'e çevirebilir. Form ve API uç noktalarında yöntem/gövde korunması gerekiyorsa 307 veya 308 gibi uygun durum kodu ve uygulama davranışı ayrıca değerlendirilmelidir. Gezinme adresini doğrulamak bu istekleri test etmiş sayılmaz.
Kaynak sunucu yönlendirme yanıtı verebilir, fakat istemci hedef WWW adını çözümleyemiyorsa sayfa açılmaz. Yönlendirme kuralı DNS kaydı oluşturmaz; hedef adın DNS ve sunucu karşılığı önceden hazır olmalıdır.
example.com isteklerini tercih edilen www.example.com adresine taşıyan dış HTTP yönlendirmesidir. Apache'de bu işlem belge kökündeki .htaccess ile yapılabilir. Hedef sabit tutulmalı, yol ve sorgu parametreleri korunmalı, zaten doğru adresteki istek tekrar yönlendirilmemelidir.Yönlendirmeden önce hem kaynak hem hedef alan adının doğru sunucuya ulaştığını doğrulayın. HTTPS ile gelen kaynak istekte de TLS bağlantısı yönlendirmeden önce kurulur; bu yüzden yalnız hedefin değil, ziyaret edilecek kaynak HTTPS adının da geçerli sertifikası bulunmalıdır.
Örneğin çalışma koşulları
Aşağıdaki örnek Apache 2.4, etkin mod_rewrite ve ilgili dizinde izin verilmiş FileInfo kuralları içindir. HTTPS bağlantısının Apache üzerinde sonlandığını varsayar. CDN veya yük dengeleyici HTTPS'yi önce sonlandırıyorsa bu kodu doğrudan kullanmayın: origin tarafında
%{HTTPS} sürekli off görünerek döngü üretebilir.Bu durumda dış isteğin protokolü, yalnız denetlediğiniz ve ilgili başlığı her istekte yeniden yazan güvenilir proxy üzerinden belirlenmelidir. İnternetten gelen herhangi bir
X-Forwarded-Proto değerine güvenmek aynı şey değildir. Ana sunucu yapılandırmasına erişiminiz varsa yönlendirmeyi uygun sanal host düzeyinde yönetebilirsiniz.WWW ve HTTPS için tek hedef
Belge kökündeki mevcut dosyayı koruyarak, CMS'nin dahili yönlendirme kurallarından önce uygulanacak konumu belirleyin. Alan adı değerlerini kendi sitenize göre değiştirin. İlk denemelerde geçici 302 kullanın:
Kod:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^(?:www.)?example.com(?::d+)?$ [NC]
RewriteCond %{HTTP_HOST} !^www.example.com$ [NC,OR]
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://www.example.com%{REQUEST_URI} [R=302,L]İlk koşul yalnız tanımlanan iki ana makine adını kabul eder. Sonraki iki koşul, ana makine adının WWW olmaması veya bağlantının HTTPS olmaması durumlarını birleştirir. Böylece uygun kaynaktan gelen istek doğrudan sabit HTTPS+WWW hedefine gider. İstek zaten
https://www.example.com üzerindeyse koşullar sağlanmaz ve bu kural yönlendirme yapmaz.REQUEST_URI yol bölümünü taşır. Hedefe yeni sorgu dizesi eklenmediği için Apache mevcut sorguyu varsayılan olarak korur; bunun için QSA eklemek gerekmez. Rastgele NE gibi bayraklar eklemeyin; özel karakterlerin kaçış davranışı farklılaşabilir.Beklenen yönlendirme sonucu
| Başlangıç | Beklenen hedef | Bu kuralın yanıtı |
|---|---|---|
Yükleniyor…
example.com
|
Yükleniyor…
www.example.com
| Tek yönlendirme |
Yükleniyor…
example.com
|
Yükleniyor…
www.example.com
| Tek yönlendirme |
Yükleniyor…
www.example.com
|
Yükleniyor…
www.example.com
| Tek yönlendirme |
Yükleniyor…
www.example.com
| Aynı adres | Yönlendirme yok |
Tablo yalnız bu kuralın davranışını gösterir. CDN, uygulama veya başka bir .htaccess kuralı ek yönlendirme üretirse gerçek zincir daha uzun olabilir. Hedefte sayfanın başarılı yanıt verdiğini ayrıca inceleyin.
Uygulama ve kontrol sırası
- Gerçek DocumentRoot konumunu, mod_rewrite desteğini ve mevcut yönlendirme politikasını belirleyin. Alt klasördeki dosya bütün siteyi kapsamayabilir.
- WWW DNS kaydını, sanal hostu ve iki HTTPS adı için sertifika kapsamını kontrol edin.
- Geçici kuralla tablodaki dört başlangıcı, gerçek bir alt sayfayı ve sorgu parametreli isteği deneyin.
- CSS, JavaScript ve görsel URL'lerinin hedef WWW üzerinde erişilebilir kaldığını kontrol edin. Statik dosyalar da alan adı değişikliğini izlemelidir.
- Sitenizde kullanılıyorsa boşluk, Türkçe karakter veya kodlanmış karakter içeren gerçek yolları da sınayın. Konum başlığının ve sorgunun beklenen URL'yi verdiğini inceleyin.
- Yönlendirme döngüsü, HTTP'ye geri dönüş veya ek sıçrama varsa Apache, CDN ve uygulama kurallarını birlikte düzeltin. Beklenen sonuç doğrulanınca kalıcı gezinme politikası için 301 değerlendirilebilir.
Sık yapılan hatalar
Kaynak ve hedefi aynı koşula yakalayıp sürekli yönlendirmek, HTTPS bilgisini proxy arkasında yanlış yorumlamak ve hedefi denetlenmemiş Host başlığından üretmek başlıca sorunlardır. Ayrıca
.htaccess kuralları Nginx tarafından okunmaz; kullanılan gerçek sunucuya uygun yapılandırma gerekir.Sık sorulan sorular
Bu kural form ve API istekleri için de aynı şekilde kullanılmalı mı?
302 ve 301 bazı istemcilerde POST'u GET'e çevirebilir. Form ve API uç noktalarında yöntem/gövde korunması gerekiyorsa 307 veya 308 gibi uygun durum kodu ve uygulama davranışı ayrıca değerlendirilmelidir. Gezinme adresini doğrulamak bu istekleri test etmiş sayılmaz.
WWW DNS kaydı yokken yönlendirme yanıtı alınabilir mi?
Kaynak sunucu yönlendirme yanıtı verebilir, fakat istemci hedef WWW adını çözümleyemiyorsa sayfa açılmaz. Yönlendirme kuralı DNS kaydı oluşturmaz; hedef adın DNS ve sunucu karşılığı önceden hazır olmalıdır.
