Set HTTP Header

Set HTTP Header Aksiyonu Nedir?

Set HTTP Header aksiyonu, HTTP trafiğindeki bir başlığın (header) değerini belirlemek veya değiştirmek için kullanılır. Başlık mevcutsa değeri güncellenir, mevcut değilse yeni başlık eklenir.

Bu aksiyon hem istek (request) hem de yanıt (response) aşamasında çalışabilir. Execution Level seçimine göre başlık, Kurum Servisine gönderilmeden önce istekte veya istemciye döndürülmeden önce yanıtta ayarlanır.

Set HTTP Header (bu aksiyon)

Önce: X-Env: old

Sonra: X-Env: new

Mevcut değer değiştirilir (tek başlık kalır).

Add HTTP Header

Önce: X-Env: old

Sonra: X-Env: old

       X-Env: new

Aynı isimle ikinci başlık eklenir.

Add HTTP Header ile Farkı

Set HTTP Header aksiyonu, başlık zaten mevcutsa değerini değiştirir. Add HTTP Header aksiyonu ise mevcut başlığı değiştirmez, aynı isimde ikinci bir başlık ekler.

Set HTTP Header Aksiyonunun Önemi

HTTP başlıklarının doğru değerlerle ayarlanması, uygulama davranışını ve güvenliğini doğrudan etkiler. Mevcut başlıkları güncelleyebilme yeteneği, trafik manipülasyonunda büyük esneklik sağlar.

Set HTTP Header aksiyonu;

• Mevcut başlık değerlerinin güncellenmesini veya düzeltilmesini sağlar,
• Kurum Servisine giden başlıkların standartlaştırılmasını mümkün kılar,
• İstemciye dönen başlıkların kontrollü şekilde ayarlanmasını sağlar,
• Host başlığının Kurum Servisi gereksinimlerine göre düzenlenmesini mümkün kılar,
• Smart Variables ile dinamik başlık değerleri oluşturulmasını destekler.

Bu nedenle Set HTTP Header aksiyonu, başlık değerlerini tam kontrol altında tutmak için ideal bir araçtır.

Kullanılabildiği vService Tipleri

HTTP

L7 TCP

Network

Çalışma Anı

İstek Anı (On Request)

Cevap Anı (On Response)

Nasıl Eklenir?

Yeni bir Set HTTP Header Aksiyonu, TR7 web yönetim arayüzü üzerinden aşağıdaki adımlar izlenerek eklenebilir:

1. Sol altta bulunan TR7 logosuna tıklanarak Configuration Menu açılır.
2. Load Balancer → Actions → Add adımları takip edilir.
3. Aksiyon için benzersiz ve açıklayıcı bir isim girilir.
4. Action Type olarak Set HTTP Header seçilir.
5. Aksiyona ait ilgili konfigürasyonlar yapılandırılır.
6. Conditions sekmesinden aksiyonun hangi koşul/koşullarda devreye gireceği belirlenir.
7. Add butonuna tıklanarak aksiyon eklenir.

Set HTTP Header Aksiyonu Ekleme Formu

Set HTTP Header Aksiyonu Ekleme Formu

INFO

Action Name

Oluşturulacak olan aksiyona benzersiz ve açıklayıcı bir isim girilir.

INFO

Action Type

Aksiyon tipi olarak Set HTTP Header seçilir.

INFO

Execution Level

Aksiyonun hangi aşamada çalıştırılacağını belirler. Bu alan kayıttan sonra değiştirilemez; yön değişikliği gerekiyorsa yeni bir aksiyon tanımlanır.

• On Request: Aksiyon, istek ilgili Kurum Servisine iletilmeden önce uygulanır. Bu seviye, istek üzerinde değişiklik yapılması veya Kurum Servisine ek bilgi iletilmesi gereken durumlarda kullanılır.
• On Response: Aksiyon, yanıt istemciye iletilmeden önce uygulanır. Bu seviye, istemciye gönderilen yanıt üzerinde düzenleme veya ekleme yapılması gereken durumlarda kullanılır.

INFO

Hit Counter Varsayılan: Kapalı

Hit Counter, aksiyonun her çalışmasını sayar (aksiyonun kendi koşuluyla birlikte değerlendirilir; Deny gibi sonlandırıcı aksiyonlarda bile sayım kaybolmaz). Aksiyon bazlı hız ve toplamlar, vService panosundaki Action Hits sekmesinde ve canlı istatistik ekranında görüntülenir; listelerde ayrıca bir kolon olarak görünmez. Sayaç kümülatiftir; elle sıfırlama arayüzü yoktur: sayılan aksiyon kümesi değiştiğinde veya vService yeniden yüklendiğinde sıfırdan başlar, geçmiş ise panoda hız (hit/s) olarak korunur.

INFO

Set Variable on Hit

Aksiyon her çalıştığında değeri atanacak bir değişken adı girilebilir (isteğe bağlı; varsayılan boş). Ad; harf, rakam ve alt çizgiden oluşabilir (en fazla 32 karakter). Aksiyon tetiklendiğinde değişken 1 değerine atanır ve aynı vService'teki diğer koşul ve aksiyonlarda %TR7VAR(ad) akıllı değişkeniyle okunarak zincirleme davranışlar kurulabilir.

INFO

Header to Edit Zorunlu

Ayarlanacak HTTP başlığının adı bu alana girilir.

• Başlık mevcutsa: Mevcut değer yeni değerle değiştirilir.
• Başlık mevcut değilse: Yeni başlık eklenir.

Başlık adları büyük/küçük harf duyarsızdır.

Sıkça Ayarlanan Başlıklar

• Host: Kurum Servisinin beklediği host adı
• X-Forwarded-Proto: Orijinal protokol bilgisi
• Content-Type: İçerik türü
• Authorization: Kimlik doğrulama bilgisi

INFO

Header Content Zorunlu

Başlığın yeni değeri bu alana girilir.

TIP

Bu alan Smart Variables destekler. fx butonu ile mevcut değişkenlere erişilebilir ve dinamik içerik oluşturulabilir.

Örnek değişkenler: istemci IP adresi, istek başlığı içeriği, istek SSL SNI bilgisi ve sabit metinler. Ayrı bir "Host" değişkeni yoktur; alan adı gerekiyorsa İstek Başlık bilgisi değişkeni host başlık adıyla kullanılır.

Sunulan değişken havuzu Execution Level seçimine göre değişir: On Response seçildiğinde yanıt aşaması değişkenleri (dönen durum kodu, yanıt başlıkları, yanıt çerezleri) de listelenir.

Detaylı bilgi Variables sayfasında yer alır.

INFO

Conditions

Bu alanda, ilgili aksiyonun hangi koşul veya koşullar sağlandığında devreye gireceği tanımlanır.

Bir veya birden fazla koşul eklenerek, and/or yapısı ile davranışın hedefli ve kontrollü şekilde uygulanması sağlanabilir.

Koşullar hakkında detaylı bilgi Conditions sayfasında yer alır.

WARNING

Bu alanda herhangi bir koşul tanımlanmazsa, ilgili aksiyon koşulsuz (Always) olarak çalışır. Bu durumda aksiyon, ilgili vService'e gelen tüm trafiğe uygulanır.

Canlı ortamlarda, koşul tanımlanmadan aksiyon kullanılması beklenmeyen durumlara (servis kesintilerine) yol açabilir. Bu nedenle aksiyon oluşturulurken mutlaka en az bir koşul tanımlanması önerilir.

INFO

Form Butonları

Add

Add butonuna tıklanarak aksiyon ekleme işlemi tamamlanır.

Add & Repeat

Add & Repeat butonu ile aksiyon ekleme işlemi tamamlanır ve farklı konfigürasyonlarla ilgili pencereden çıkılmadan yeni bir aksiyon daha eklenebilir.

Aksiyon Eklendi

Davranış Ayrıntıları

• Başlık adı önerilerle birlikte sunulur; öneri listesi seçili Execution Level'a göre değişir (istek başlıkları / yanıt başlıkları). Listede olmayan adlar elle yazılabilir.
• Başlık adı için biçim denetimi yapılmaz; Content-Length ve Transfer-Encoding gibi gövde çerçevelemesini belirleyen başlıkların elle yazılması bozuk yanıtlara yol açar.
• On Response seçildiğinde aksiyon yalnızca Kurum Servisinden dönen yanıtlara uygulanır; TR7'nin kendi ürettiği yanıtlar (engelleme, yönlendirme, hata sayfaları) etkilenmez.
• Başlık adının yazıldığı büyük/küçük harf biçimi karşı tarafa aynen iletilmez; korunması gerekiyorsa Keep Header Names aksiyonu kullanılır.
• Aksiyonun vService başına sayı sınırı yoktur.

Operasyonel ve Güvenli Kullanım Önerileri

• Set HTTP Header vs Add HTTP Header Seçimini Doğru Yapın.

  Senaryo	Önerilen Aksiyon
  Mevcut başlığı güncellemek	Set HTTP Header
  Başlık yoksa eklemek, varsa güncellemek	Set HTTP Header
  Çoklu değer eklemek (örn: birden fazla Cookie)	Add HTTP Header
  Başlık yoksa eklemek, varsa dokunmamak	Koşullu Add HTTP Header

• Host Başlığını Dikkatli Ayarlayın. Kurum Servisine gönderilen Host başlığı, uygulamanın doğru çalışması için kritiktir. Yanlış Host değeri virtual host routing'i bozabilir, SSL sertifika doğrulamasını engelleyebilir ve uygulama içi URL'lerin yanlış oluşmasına neden olabilir.

• Protokol Bilgisini İletin. TLS sonlandırması TR7'de yapılıyorsa, Kurum Servisi orijinal protokolü X-Forwarded-Proto başlığından öğrenebilir:

  Header (Key): X-Forwarded-Proto
  Value: https

• Koşullarla birlikte kullanılır. Tüm trafiğe aynı değeri atamak yerine belirli koşullarda farklı değerler atanır.

Canlı Ortamlarda Yaygın Kullanım Senaryoları

Aşağıdaki örnekler, ilgili aksiyonun gerçek sistemlerde en sık karşılaşılan kullanım senaryolarında nasıl uygulandığını göstermektedir. Bu senaryolar, canlı ortamlarda yaygın olarak tercih edilen ve sahada edinilmiş deneyimlere dayanan pratikleri temel alır.

Senaryo 1: Virtual Host Routing için Host Başlığı Ayarlama

Problem: Kurum Servisi birden fazla virtual host barındırıyor ve Host başlığına göre farklı uygulamalar sunuyor. Ancak TR7'ye gelen isteklerde Host başlığı external domain (www.example.com) iken Kurum Servisi internal domain (internal-api.example.com) bekliyor. Host başlığı yanlış olduğundan Kurum Servisi 404 veya default site dönüyor.

Çözüm: Host başlığı, Kurum Servisinin beklediği internal domain olarak ayarlanır ve virtual host routing'in doğru çalışması sağlanır.

Konfigürasyon:

• Execution Level: On Request
• Header to Edit: Host
• Header Content: internal-api.example.com
• Conditions:
  • Koşulsuz (tüm isteklere uygulanır)

Sonuç:

• ✅ Virtual host routing → Kurum Servisi doğru Host alır ve doğru uygulamayı sunar.
• ✅ Multi-tenant destek → Birden fazla uygulama aynı IP'de çalışabilir.
• ✅ SSL SNI uyumluluğu → Internal sertifika eşleşmesi sağlanır.
• ✅ Uygulama URL'leri → Kurum Servisi yanıtlarında doğru URL'ler oluşur.

Örnek Dönüşüm:

• İstemci isteği: Host: www.example.com
• TR7 ayarlaması: Host: internal-api.example.com
• Kurum Servisi bunu kabul eder ve ilgili uygulamayı döner

Senaryo 2: SSL Offloading Sonrası Protokol Bilgisi İletme

Problem: TR7'de SSL termination yapılıyor ve Kurum Servisine HTTP olarak iletiliyor. Ancak Kurum Servisi orijinal isteğin HTTPS olduğunu bilmiyor ve redirect URL'lerini http:// olarak oluşturuyor. Bu da mixed content hatalarına ve güvenlik sorunlarına yol açıyor.

Çözüm: X-Forwarded-Proto başlığı https olarak ayarlanır ve Kurum Servisinin orijinal protokolü bilmesi sağlanır.

Konfigürasyon:

• Execution Level: On Request
• Header to Edit: X-Forwarded-Proto
• Header Content: https
• Conditions:
  • SSL Terminated

Sonuç:

• ✅ Protokol farkındalığı → Kurum Servisi orijinal protokolü bilir ve doğru URL üretir.
• ✅ Redirect düzeltmesi → Location başlıkları https:// ile oluşur.
• ✅ Framework desteği → Django, Rails, Spring gibi framework'ler X-Forwarded-Proto'yu okur.
• ✅ Mixed content önleme → HTTPS sayfalarında HTTP kaynaklar engellenir.

Uygulama Davranışı:

• Kurum Servisi framework'ü X-Forwarded-Proto: https okur
• url_for(), redirect_to() gibi fonksiyonlar HTTPS URL üretir
• Absolute URL'ler doğru protokol ile oluşur

Senaryo 3: API Yanıtlarında Content-Type Düzeltme

Problem: Legacy API Kurum Servisi JSON döndüğü halde Content-Type'ı yanlış (text/plain veya text/html) gönderiyor. İstemci tarafındaki JavaScript uygulaması Content-Type'a güveniyor ve JSON parse etmek yerine text olarak işliyor. Bu da API entegrasyonunun bozulmasına neden oluyor.

Çözüm: API path'lerinde Content-Type başlığı doğru değere (application/json) ayarlanır ve istemci tarafındaki parsing düzeltilir.

Konfigürasyon:

• Execution Level: On Response
• Header to Edit: Content-Type
• Header Content: application/json; charset=utf-8
• Conditions:
  • Path /api/ ile başlar

Sonuç:

• ✅ JSON parsing → JavaScript response.json() otomatik çalışır.
• ✅ Tarayıcı davranışı → Browser JSON olarak render eder, syntax highlighting yapar.
• ✅ Charset belirtimi → UTF-8 encoding açıkça belirtilir, karakter bozulması önlenir.
• ✅ RESTful uyumluluk → API best practice'lerine uygun header döner.

Örnek Dönüşüm:

• Kurum Servisi: Content-Type: text/plain
• TR7 ayarlaması: Content-Type: application/json; charset=utf-8
• İstemci doğru şekilde JSON parse eder

Senaryo 4: Statik Token ile Authorization Ekleme

Problem: Internal microservice'ler arası iletişimde her servis mutual authentication bekliyor. Ancak bazı legacy client'lar Authorization başlığı gönderemiyor. Bu client'lar için sabit bir service token eklemek gerekiyor ama uygulama kodunu değiştirmek mümkün değil.

Çözüm: Belirli path'lere giden isteklerde Authorization başlığı statik token ile ayarlanır ve service-to-service authentication sağlanır.

Konfigürasyon:

• Execution Level: On Request
• Header to Edit: Authorization
• Header Content: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
• Conditions:
  • Path /internal-api/ ile başlar
  • AND HTTP Header Authorization yok

Sonuç:

• ✅ Service auth → Legacy client'lar microservice'lere erişebilir.
• ✅ Koşullu ekleme → Sadece Authorization olmayan isteklere eklenir, mevcut token korunur.
• ✅ Zero-code change → Uygulama değişikliği gerekmez, TR7 seviyesinde çözüm.
• ✅ Internal API güvenliği → Sadece internal path'lerde devreye girer, public API'yi etkilemez.

Örnek Dönüşüm:

• Legacy client isteği: GET /internal-api/status (Authorization yok)
• TR7 ayarlaması: Authorization: Bearer eyJhbGci... eklenir
• Microservice isteği kabul eder ve yanıt döner

Senaryo 5: Static İçerik için Cache-Control Ayarlama

Problem: Kurum Servisi static dosyalarda (CSS, JS, resimler) Cache-Control başlığı gönderiyor ama değer çok kısa (max-age=300) veya hiç göndermiyor. Bu da her sayfa yüklemesinde static dosyaların tekrar indirilmesine, bandwidth israfına ve yavaş sayfa yüklemesine neden oluyor.

Çözüm: Statik dosya path'lerinde Cache-Control başlığı uzun süreli önbellekleme için ayarlanır ve tarayıcı önbelleklemesi iyileştirilir.

Konfigürasyon:

• Execution Level: On Response
• Header to Edit: Cache-Control
• Header Content: public, max-age=31536000, immutable
• Conditions:
  • Path /static/ içerir
  • OR Path .css ile biter
  • OR Path .js ile biter
  • OR Path .png ile biter

Sonuç:

• ✅ Long-term caching → Static dosyalar 1 yıl boyunca cache'lenir.
• ✅ Bandwidth tasarrufu → Tekrar eden ziyaretlerde dosyalar indirilmez.
• ✅ Sayfa performansı → Sayfa yüklenme süresi %50+ azalır.
• ✅ Immutable flag → Modern tarayıcılarda revalidation bile yapılmaz.

Cache Davranışı:

• İlk ziyaret: Static dosyalar indirilir ve cache'lenir
• Sonraki ziyaretler: Tarayıcı disk cache'ten okur, HTTP isteği atmaz
• max-age=31536000 → 1 yıl = 365 gün caching