Yetenek

HTTP Yönlendirme Kuralları

HTTP→HTTPS, domain değişimi, path taşıma ve hata yönlendirmelerini uygulama koduna dokunmadan yönetin.

TR7 HTTP Yönlendirme Kuralları, web trafiğinde sık kullanılan redirect akışlarını ADC katmanında merkezi olarak uygular. HTTP'den HTTPS'e geçiş, eski domainden yeni domaine taşıma, www→apex veya apex→www standardizasyonu, path bazlı yönlendirme ve hata durumlarında alternatif sayfaya gönderme tek kural modeliyle yönetilebilir. Uygulama ekiplerinin her framework içinde ayrı redirect kodu yazmasına gerek kalmaz. TR7, isteği vService üzerinde karşılar, koşulu değerlendirir ve doğru HTTP status code ile yönlendirme cevabını üretir. 301, 302, 307 ve 308 gibi farklı redirect davranışları servis ihtiyacına göre seçilebilir. Yönlendirme kuralları host, path, header, method, source IP, geo veya FX ifade motorundan gelen koşullarla birleştirilebilir. Böylece yalnız genel HTTPS zorlama değil; belirli URL ağacı, eski kampanya linkleri, bakım senaryoları veya hata kodu bazlı yönlendirmeler de merkezi hale gelir. Sonuç: TR7, HTTP redirect davranışını uygulama kodu, web sunucusu dosyası ve dağınık kural setlerinden çıkarır; denetlenebilir, sürümlenebilir ve servis bazlı bir ADC politikasına dönüştürür.

4
Redirect status code: 301, 302, 307, 308
3
Temel aksiyon tipi: redirect_scheme, req_redirect_location, error_redirect
1
Merkezi ADC politikası — uygulama kodu sıfır değişiklik

Redirect kuralları uygulama koduna dağıldığında, küçük URL değişikliği bile operasyon riskine dönüşür.

HTTP yönlendirmeleri basit görünür; fakat production ortamında domain taşıma, HTTPS zorunluluğu, eski URL uyumluluğu, SEO davranışı, method koruma ve hata durumlarıyla birlikte karmaşık hale gelir. Yanlış status code seçimi arama motoru, tarayıcı cache'i, API istemcisi veya mobil uygulama davranışını bozabilir.

Birçok kurumda redirect kuralları farklı yerlerde yaşar: uygulama kodu, web sunucusu konfigürasyonu, CDN ayarı, load balancer kuralı veya geçici bakım script'i. Aynı domain için birden fazla yerde yönlendirme varsa loop, çift redirect, query kaybı veya yanlış hedef problemi oluşabilir.

Legacy modernizasyon projelerinde bu sorun daha büyüktür. Eski domain yeni domaine taşınır, eski path yapısı yeni API yapısına çevrilir, bazı path'ler kalıcı bazıları geçici yönlendirilir. Uygulama kodunu değiştirmek hem yavaş hem risklidir; ayrıca eski uygulama çoğu zaman bu esnekliği desteklemez.

Doğru yaklaşım, redirect davranışını trafik kuralı olarak merkezi noktada yönetmektir. Scheme, host, path, query, status code ve hata koşulları ADC katmanında tanımlanmalı; uygulama yalnız gerçek iş mantığına odaklanmalıdır.

TR7 HTTP Yönlendirme Kuralları bu modeli sunar: HTTP→HTTPS, tam URL yönlendirme, domain/path taşıma ve hata kodu bazlı redirect akışlarını tek politika modelinde yönetir.

Yaklaşımımız

TR7, HTTP yönlendirmelerini scheme değişimi, tam URL hedefi, hata koşulu ve trafik bağlamı üzerinden yönetilebilir kurallara dönüştürür.

HTTP'den HTTPS'e geçiş tek redirect kuralıyla uygulanır

`redirect_scheme` aksiyonu ile HTTP trafiği HTTPS'e yönlendirilebilir. Bu, uygulama kodu veya web sunucusu ayarı değiştirilmeden güvenli bağlantı standardı oluşturur.

Tam URL yönlendirme domain ve path taşımasını sadeleştirir

`req_redirect_location` aksiyonu ile istek belirli bir URL'ye yönlendirilebilir. Eski domain, eski path veya kampanya linkleri merkezi olarak yeni adrese taşınabilir.

Hata durumlarında kullanıcı alternatif sayfaya gönderilir

Timeout veya response hata kodlarında redirect kuralı çalıştırılabilir. Böylece kullanıcı boş hata sayfası yerine bakım, durum veya yedek servis sayfasına yönlendirilir.

Koşullu redirect trafik bağlamına göre karar verir

Host, path, method, header, kaynak IP veya FX ifadeleri redirect kararında kullanılabilir. Aynı vService içinde farklı URL ağaçları farklı redirect davranışıyla çalışabilir.

Yetenekler

HTTP Yönlendirme Kuralları, hızlı HTTPS geçişinden hata kodu yönlendirmesine kadar farklı redirect senaryolarını tek ADC politikası altında toplar.

redirect_scheme HTTP trafiğini HTTPS'e hızlı ve merkezi taşır

HTTP→HTTPS yönlendirme çoğu uygulama için temel güvenlik gereksinimidir. TR7, scheme değişimini uygulama kodu yerine ADC kuralı olarak uygular. İstek HTTP geldiyse HTTPS hedefe yönlendirilir; HTTPS gelen isteklerde gereksiz redirect üretilmez. Bu, legacy uygulamaları güvenli yayınlama standardına taşımayı kolaylaştırır.

req_redirect_location tam URL hedefiyle domain taşımasını destekler

Eski domain yeni domaine, eski path yeni path'e veya geçici kampanya adresi kalıcı adrese yönlendirilebilir. TR7 tam hedef URL tanımını kural içinde tutar. Bu yapı migration, rebranding ve uygulama modernizasyon projelerinde kritik rol oynar. Uygulama kodu eski URL bilgisiyle uğraşmaz.

301, 302, 307 ve 308 status code seçimi yapılabilir

Her redirect aynı semantiğe sahip değildir. 301 ve 308 kalıcı taşıma için, 302 ve 307 geçici yönlendirme için kullanılabilir. 307 ve 308 method koruma ihtiyacı olan API çağrılarında daha doğru davranış sağlayabilir. TR7, status code seçimini kuralın parçası yaparak redirect davranışını açık hale getirir.

Query bilgisini koruma veya değiştirme davranışı yönetilebilir

Redirect sırasında query string'in korunup korunmayacağı servis ihtiyacına göre belirlenebilir. Eski kampanya linklerinde query parametreleri analitik veya takip için korunabilir. Güvenlik açısından riskli parametrelerin yeni hedefe taşınması istenmeyebilir. TR7 bu kararı merkezi kural içinde yönetilebilir hale getirir.

Method koruma API yönlendirmelerinde veri kaybını azaltır

API istemcileri POST, PUT veya PATCH gibi method'larla istek gönderebilir. Yanlış redirect status code seçimi istemcinin method'u GET'e çevirmesine neden olabilir. TR7, 307 veya 308 gibi method koruyan redirect davranışlarının kullanılmasını sağlar. Bu, API modernizasyon ve endpoint taşıma senaryolarında önemlidir.

www ve apex domain standardizasyonu tek noktadan uygulanır

`www.example.com` ile `example.com` arasında standart yön belirlenebilir. Bu davranış SEO, sertifika, cookie kapsamı ve kullanıcı deneyimi açısından tutarlılık sağlar. TR7, domain standardizasyonunu uygulama veya web sunucusu katmanına dağıtmadan yönetir. Tek kural tüm vService davranışını sadeleştirir.

Eski path yapısı yeni URL düzenine koşullu taşınabilir

Legacy uygulamalarda `/old/products/123` gibi path'ler yeni uygulamada farklı yapıya taşınmış olabilir. TR7 path koşullarıyla eski URL ağaçlarını yeni hedeflere yönlendirebilir. Bu, kademeli modernizasyon projelerinde kullanıcı linklerinin bozulmasını engeller. Eski uygulama ayakta kalırken yeni uygulamaya kontrollü geçiş yapılır.

Timeout ve trafik yöneticisi hatalarında redirect üretilebilir

`error_redirect_at_tm` benzeri akışlarla timeout veya trafik yönetimi kaynaklı hata durumlarında kullanıcı alternatif hedefe gönderilebilir. Örneğin bakım sayfası, durum sayfası veya yedek domain kullanılabilir. Kullanıcıya ham hata göstermek yerine kontrollü deneyim sağlanır. Operasyonel kesintiler daha düzgün yönetilir.

Response hata kodlarında alternatif hedefe yönlendirme yapılabilir

`error_redirect_at_res` yaklaşımıyla kurum servisinden dönen belirli hata kodları redirect davranışı tetikleyebilir. 500, 502, 503 veya 504 gibi durumlarda kullanıcı farklı bir sayfaya gönderilebilir. Bu, özellikle bakım ve geçici servis bozulması senaryolarında değerlidir. Hata yönetimi uygulamadan bağımsız hale gelir.

Trafik koşulları redirect kararını bağlama duyarlı yapar

Host, path, method, header, source IP veya farklı FX ifadeleri redirect koşulu olarak kullanılabilir. Örneğin yalnız mobil path'ler, yalnız eski API sürümü veya yalnız belirli ülke trafiği yönlendirilebilir. Böylece redirect kuralı kör bir global davranış olmaktan çıkar. Trafik bağlamına göre kontrollü karar verilir.

Redirect loop riskini merkezi politika ile azaltır

Redirect kuralları farklı sistemlere dağıldığında loop riski artar. TR7 kuralları merkezi noktada tutulduğu için scheme, host ve path koşulları daha net görülebilir. Operatör HTTPS'e zaten gelmiş isteği tekrar HTTPS'e yönlendirme veya yeni domain'den eski domain'e dönüş gibi hataları daha kolay yakalar. Bu, production değişikliklerinde kritik güvenlik sağlar.

Audit ve versiyonlama redirect değişikliklerini denetlenebilir yapar

Redirect kuralları trafik kuralları motorunun parçası olarak yönetildiğinde değişiklik geçmişi izlenebilir. Kim hangi domain'i, hangi status code ile nereye yönlendirdi sorusu audit üzerinden cevaplanabilir. Yanlış redirect hızlıca geri alınabilir. Bu, SEO, güvenlik ve operasyon ekipleri için ortak denetim zemini oluşturur.

Operasyonel derinlik

HTTP yönlendirme kuralları; status code seçimi, query davranışı, method koruma, hata koşulu, loop kontrolü ve bakım senaryolarıyla birlikte işletilir.

01

Status code seçimi

301 ve 308 kalıcı yönlendirme davranışları için, 302 ve 307 geçici yönlendirme davranışları için kullanılabilir. API çağrılarında method koruma gerekiyorsa 307 veya 308 daha uygun olabilir. Yanlış status code tarayıcı veya istemci cache davranışını etkileyebilir.

02

Query davranışı

Redirect sırasında query parametrelerinin korunması veya hedefte yeniden oluşturulması gerekir. Takip parametreleri korunmak istenebilir; hassas parametreler taşınmamalıdır. Bu karar güvenlik ve analitik ihtiyacına göre verilmelidir.

03

Method koruma

Bazı redirect status code'ları istemci method'unu değiştirebilir. Form gönderimi veya API yazma işlemlerinde bu veri kaybı veya yanlış işlem riski oluşturabilir. Method koruma gerektiren senaryolarda uygun status code seçilmelidir.

04

Hata koşulu

Timeout veya response hata kodu redirect davranışını tetikleyebilir. Bu kurallar, bakım sayfası veya durum sayfasına kontrollü yönlendirme için kullanılabilir. Hata redirect'i gerçek problemi gizlememeli; log ve monitoring ile birlikte kullanılmalıdır.

05

Loop kontrolü

Redirect kuralı yazılırken hedef URL'nin aynı koşulu tekrar tetikleyip tetiklemediği kontrol edilmelidir. Scheme, host ve path koşulları net sınırlandırılmalıdır. Merkezi kural yönetimi loop riskini azaltır.

06

Bakım yönlendirmesi

Planlı bakımda belirli path veya tüm host geçici bakım sayfasına yönlendirilebilir. Bu durumda 302 veya 307 gibi geçici status code'lar daha uygun olabilir. Bakım sonrası kural kapatılarak trafik normal akışına döner.

Hangi senaryolarda kullanılır

HTTP trafiğini HTTPS'e merkezi olarak taşıma

Eski uygulama HTTP üzerinden yayınlanıyor olabilir. TR7, uygulama kodu değişmeden HTTP isteklerini HTTPS hedefe yönlendirerek güvenli bağlantı standardı oluşturur.

Eski domaini yeni kurumsal domaine yönlendirme

Rebranding veya domain değişiminde eski domain trafiği yeni domaine taşınabilir. 301 veya 308 ile kalıcı taşıma davranışı açıkça belirlenir.

Legacy path yapısını yeni uygulama düzenine taşıma

Eski URL ağaçları yeni uygulama path'lerine yönlendirilebilir. Kullanıcıların bookmark'ları ve eski entegrasyon linkleri bozulmadan migration yapılır.

503 hata durumunda bakım sayfasına yönlendirme

Kurum servisi geçici olarak cevap veremediğinde kullanıcı ham hata yerine bakım sayfasına gönderilebilir. Operasyon kesintisi daha kontrollü kullanıcı deneyimine dönüşür.

API endpoint taşımasında method koruyan redirect kullanma

POST veya PUT çağrıları yeni API endpoint'ine taşınırken 307 veya 308 kullanılabilir. Böylece istemci method'u ve request davranışı korunur.

Sık sorulanlar

301, 302, 307 ve 308 arasındaki fark nedir, hangisini seçmeliyim?
301 ve 308 kalıcı taşıma için kullanılır; arama motorları bu kodlarla hedef URL'yi index'e alır. 302 ve 307 geçici yönlendirme için tercih edilir. 307 ve 308 request method'u korur; POST veya PUT gibi method'larla gelen API çağrılarının GET'e dönüşmesini engeller. Kampanya veya bakım yönlendirmelerinde 307, SEO açısından kalıcı domain taşımada 301 veya 308 genellikle tercih edilir.
redirect_scheme aksiyonu nasıl çalışır?
redirect_scheme, gelen isteğin scheme'ini kontrol eder. HTTP olarak gelen istek HTTPS hedefe yönlendirilir; zaten HTTPS olarak gelen isteklerde kural tetiklenmez ve gereksiz redirect üretilmez. Bu, uygulama kodu veya web sunucusu konfigürasyonu değiştirilmeden tüm vService için güvenli bağlantı standardının merkezi olarak uygulanmasını sağlar.
Hata kodu bazlı redirect nasıl kurulur?
error_redirect_at_tm, timeout veya trafik yöneticisi kaynaklı hatalarda; error_redirect_at_res ise kurum servisinden dönen belirli HTTP hata kodlarında (500, 502, 503, 504 gibi) redirect tetikler. Her iki aksiyon da hedef URL ve status code ile konfigüre edilir. Bu kurallar log ve monitoring ile birlikte kullanılmalı; gerçek problemi gizlememek için hata kaynağı ayrıca izlenmelidir.
Redirect sırasında query string korunur mu?
Query string koruma davranışı kural konfigürasyonunun parçasıdır. Analitik veya kampanya takibi için query parametrelerini yeni hedefe taşımak gerekebilir. Güvenlik açısından hassas veya gereksiz parametrelerin yeni hedefe iletilmesi istenmeyebilir. TR7, bu kararı merkezi kural içinde açıkça yönetilebilir hale getirir.
Redirect loop oluşmaması için ne yapılmalıdır?
Kural yazılırken hedef URL'nin aynı redirect koşulunu tekrar tetikleyip tetiklemediği kontrol edilmelidir. Örneğin HTTPS'e zaten gelmiş isteği tekrar HTTPS'e yönlendirmek veya yeni domain'den eski domain'e dönmek loop oluşturur. TR7, tüm kuralları merkezi noktada tuttuğu için scheme, host ve path koşulları daha net görülebilir ve loop riski daha kolay yönetilir.
www ile apex domain arasında standardizasyon nasıl sağlanır?
req_redirect_location aksiyonu ve host koşuluyla www.example.com gelen trafik example.com'a veya tersi yönlendirilebilir. Bu kuralın SEO, sertifika kapsamı ve cookie davranışı açısından tutarlı uygulanması gerekir. Yanlış yönde redirect hem SEO'ya zarar verebilir hem de HTTPS sertifika kapsamını etkileyebilir.

HTTP redirect akışlarınızı ADC katmanında merkezileştirin

HTTPS geçişi, domain taşıma, path yönlendirme ve hata redirect'lerini uygulama kodu sıfır değişikliğiyle yönetin. Kendi servislerinizle canlı bir kurulumda gezdirelim.