HTTP Header 1.0 Compatibility

HTTP Header 1.0 Compatibility Aksiyonu Nedir?

HTTP Header 1.0 Compatibility aksiyonu, TR7'nin ilettiği HTTP başlık adlarının belirli bir büyük/küçük harf yazımıyla yazılmasını sağlar. Başlık adlarının yazımına duyarlı eski sistemlerle uyumluluk sorunlarını çözer.

HTTP standartlarında başlık isimleri büyük/küçük harf duyarsızdır (case-insensitive). Ancak bazı eski sistemler ve uygulamalar, başlıkların belirli bir formatta (örn: Content-Type vs content-type) olmasını bekleyebilir.

TR7 aldığı tüm başlık adlarını iç işleyişinde küçük harfe indirger; bu aksiyon, başlıkları karşı tarafa yazarken tanımlanan yazımı yeniden uygular. Dönüşüm, isteği gönderen istemcinin HTTP sürümüne bakılmaksızın uygulanır.

HTTP Header 1.0 Compatibility Aksiyonunun Önemi

Bazı legacy uygulamalar, HTTP başlıklarının belirli bir case formatında olmasını bekler.

HTTP Header 1.0 Compatibility aksiyonu;

• Uygulamaların başlık parsing sorunlarını çözer,
• Legacy sistemlerle entegrasyon sağlar,
• Başlık normalizasyonu ile tutarlı davranış sağlar,
• Case-sensitive başlık kontrolü yapan uygulamalarla uyumluluk sağlar.

Bu nedenle HTTP Header 1.0 Compatibility aksiyonu, heterogen ortamlarda uyumluluk için kritik bir bileşendir.

Nasıl Çalışır?

Bu aksiyon, belirtilen başlık isimlerini bir dönüşüm haritasına ekler. Harita her iki yönde de uygulanır:

1. Başlık adları TR7 içinde küçük harfe indirgenir.
2. Başlık karşı tarafa yazılırken haritada aranır.
3. Haritada bulunursa, listede yazıldığı biçimde yazılır: Kurum Servisine giden isteklerde ve istemciye dönen yanıtlarda.

Yalnızca HTTP/1.x bağlantılarında geçerlidir

HTTP/2 ve HTTP/3 protokollerinde başlık adlarının küçük harf olması standart gereğidir. Bu aksiyon yalnızca HTTP/1.x üzerinden kurulan bağlantılarda etkilidir; HTTP/2 ile bağlanan bir istemciye dönen yanıtta başlık yazımı değişmez.

content-type

→

Content-Type

accept-encoding

→

Accept-Encoding

host

→

Host

user-agent

→

User-Agent

TIP

Birden fazla başlık tanımlanabilir; her satıra bir başlık yazılır.

Kullanılabildiği vService Tipleri

HTTP

L7 TCP

Network

Çalışma Anı

İstek Anı (On Request)

Cevap Anı (On Response)

Aksiyon her iki yönde birden çalışır; formda Execution Level seçimi yer almaz. Yanıt başlıkları da (Set-Cookie, WWW-Authenticate, Location, Server) varsayılan listede yer aldığından istemciye bu yazımla iletilir.

Nasıl Eklenir?

Yeni bir HTTP Header 1.0 Compatibility 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 HTTP 1.0 header compatibility seçilir.
5. Aksiyona ait ilgili konfigürasyonlar yapılandırılır.
6. Add butonuna tıklanarak aksiyon eklenir.

HTTP Header 1.0 Compatibility Aksiyonu Ekleme Formu

HTTP Header 1.0 Compatibility Aksiyonu Ekleme Formu

INFO

Action Name

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

INFO

Action Type

Aksiyon tipi olarak HTTP 1.0 header compatibility seçilir.

Aksiyon HTTP vService'lerde ve her iki yönde birden çalıştığından formda Execution Level, Rule Protocol ve Conditions alanları bulunmaz. Sayaç da desteklenmez; Hit Counter ve Set Variable on Hit alanları yer almaz.

INFO

Headers to Fix Zorunlu

Düzeltilecek başlıkların listesidir. Her satıra bir başlık ismi yazılır. Alan boş bırakılamaz.

Alan, aşağıda listelenen 61 başlıktan oluşan hazır bir liste ile dolu olarak açılır; ihtiyaca göre satır eklenir veya çıkarılır.

Başlık, listeye yazıldığı biçimde iletilir

Başlıklar için "doğru biçim" diye bir dönüşüm tablosu yoktur: listeye ne yazılırsa karşı tarafa o yazımla iletilir.

Bu nedenle başlık adları hedeflenen yazımla girilmelidir. content-type yazılması hiçbir işe yaramaz (başlık yine küçük harfle gider); Content-Type yazılmalıdır. Aynı şekilde X-Request-ID ile X-RequestId farklı iki yazımdır ve hangisi yazıldıysa o iletilir.

Aynı başlığın iki farklı yazımla (Host ve host) listeye girilmesinden kaçınılmalıdır. Satırlarda başlık adı dışında boşluk, iki nokta veya ek karakter bulunmamalıdır.

Liste değişikliği servisi yeniden başlatır

Başlık listesi yapılandırma çözümlenirken okunur ve kesintisiz yeniden yükleme sırasında tekrar okunmaz. Bu nedenle listede yapılan her değişiklik ilgili vService'in yeniden başlatılmasını gerektirir; canlı ortamlarda bakım penceresinde uygulanması önerilir.

Headers to Fix Manuel Header Bilgisi Tanımlama

Varsayılan listede kullanılan HTTP başlıkları:

Başlık	Kullanım Alanı
Accept	Kabul edilen içerik tipleri
Accept-Auth	Desteklenen kimlik doğrulama yöntemleri
Accept-Encoding	Desteklenen sıkıştırma türleri
Accept-Language	Tercih edilen diller
Authorization	Kimlik doğrulama bilgisi
Cache-Control	Önbellek davranışı
Client-Request-Id	İstek izleme kimliği
Connection	Bağlantı yönetimi
Content-Length	İçerik uzunluğu
Content-Type	İçerik medya tipi
Cookie	İstemci çerezleri
DNT	İzleme tercihi (Do Not Track)
Date	Mesaj tarihi
Depth	WebDAV istek derinliği
Expires	İçerik geçerlilik süresi
Host	Hedef sunucu adı
Location	Yönlendirme adresi
Persistent-Auth	Kalıcı kimlik doğrulama durumu
Pragma	Eski önbellek kontrolü
Purpose	İstek amacı bilgisi
Sec-Fetch-Dest	İsteğin hedef kaynağı
Sec-Fetch-Mode	İstek modu
Sec-Fetch-Site	Kaynak-site ilişkisi
Sec-Fetch-User	Kullanıcı etkileşimi bilgisi
Server	Sunucu yazılım bilgisi
Set-Cookie	Sunucu tarafından ayarlanan çerez
Transfer-Encoding	Aktarım kodlaması
Upgrade-Insecure-Requests	Güvensiz isteği yükseltme talebi
User-Agent	İstemci uygulama bilgisi
WWW-Authenticate	Kimlik doğrulama talimatı
X-Accept	Özel kabul edilen içerik bilgisi
X-AnchorMailbox	Exchange hedef posta kutusu
X-AspNet-Version	ASP.NET sürüm bilgisi
X-AutoDiscoverArchiveAsSmtp	Exchange autodiscover ayarı
X-BEServer	Backend Exchange sunucusu
X-CalculatedBETarget	Hesaplanan Kurum Servisi hedefi
X-CasErrorCode	Exchange CAS hata kodu
X-ClientApplication	İstemci uygulama adı
X-ClientInfo	İstemci ek bilgileri
X-DiagInfo	Tanılama bilgisi
X-EWS-TargetVersion	EWS hedef sürümü
X-ExpirationInfo	Süre sonu bilgisi
X-FEServer	Frontend sunucu bilgisi
X-FeatureVersion	Özellik sürümü
X-MS-Account-Type	Microsoft hesap türü
X-MS-CookieUri-Requested	Cookie URI talebi
X-MS-Negotiate	Microsoft müzakere bilgisi
X-MapiHttpCapability	MAPI HTTP yetenekleri
X-OAuth-Enabled	OAuth etkinlik durumu
X-OWA-Version	Outlook Web Access sürümü
X-PendingPeriod	Bekleme süresi bilgisi
X-Powered-By	Sunucu teknolojisi
X-RequestId	İstek benzersiz kimliği
X-RequestType	İstek türü
X-ResponseCode	Uygulama yanıt kodu
X-SOAP-Enabled	SOAP desteği durumu
X-ServerApplication	Sunucu uygulaması
X-TunnelExpirationTime	Tünel geçerlilik süresi
X-User-Identity	Kullanıcı kimlik bilgisi
X-WSSecurity-Enabled	WS-Security durumu
X-WSSecurity-For	WS-Security hedefi

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

WARNING

HTTP Header 1.0 Compatibility aksiyonu koşul gerektirmez ve tanımlandığı vService üzerinde koşulsuz (Always) olarak uygulanır.

Koşulsuz çalışan aksiyonlar, trafik içeriğine bağlı değerlendirme yapmadan, ilgili vService üzerindeki tüm trafiği veya davranışı doğrudan etkiler.

Canlı ortamlarda, bu tür aksiyonların devreye alınması öncesinde hedef servis davranışlarının ve olası etkilerin dikkatle değerlendirilmesi önerilir. Aksi durumda, beklenmeyen servis davranışları veya operasyonel sorunlar oluşabilir.

Operasyonel ve Güvenli Kullanım Önerileri

• Yalnızca gerekli başlıklar eklenir. Tüm başlıklar yerine yalnızca Kurum Servisinin beklediği ve sorun yaşanan başlıklar eklenir; gereksiz dönüşümler performansı etkileyebilir.
• Backend Gereksinimlerini Belirleyin. Hangi başlıkların hangi formatta beklendiğini Kurum Servisi dokümantasyonundan veya geliştirici ekibinden öğrenin.
• Test ortamında doğrulanır. Değişiklik önce test ortamında uygulanır ve Kurum Servisinin doğru biçimde yanıt verdiği doğrulanır.
• Modern Uygulamalarda Genellikle Gerekmez. Bu aksiyon özellikle legacy sistemler için tasarlanmıştır. Modern HTTP/1.1+ uygulamaları genellikle case-insensitive başlık işleme yapar.

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.

TIP

HTTP Header 1.0 Compatibility aksiyonu koşul gerektirmez ve vService üzerinde koşulsuz (Always) olarak uygulanır. Aşağıdaki senaryolar, farklı kullanım amaçlarını göstermektedir.

Senaryo 1: Legacy Java Application Server: Case-Sensitive Header Parsing

Problem: Eski Tomcat 5.x ve JBoss 4.x sunucularında çalışan legacy Java servlet'ler, HTTP başlıklarını case-sensitive olarak okuyorlar. Modern HTTP client'lar lowercase başlıklar gönderiyor (content-type, authorization) ancak servlet getHeader("Content-Type") ile büyük harfle arıyor ve başlığı bulamıyor. Bu durum authentication ve content-type parsing hatalarına neden oluyor.

Çözüm: HTTP Header 1.0 Compatibility aksiyonu ile lowercase başlıkları listede tanımlanan yazımla ileterek legacy servlet'lerin doğru çalışmasını sağlamak.

Konfigürasyon:

• Headers to Fix: Content-Type, Authorization, Accept, Accept-Encoding, Host, User-Agent, Connection

Sonuç:

• ✅ content-type: application/json → Kurum Servisine Content-Type: application/json iletilir.
• ✅ authorization: Bearer xyz → Kurum Servisine Authorization: Bearer xyz iletilir.
• ✅ Legacy servlet'ler getHeader("Content-Type") ile başlığı doğru okur, authentication ve content parsing başarılı olur.
• ✅ Backend kod değişikliği gerekmez, HTTP/1.0 client uyumluluğu sağlanır.

Senaryo 2: IoT Device Firmware: HTTP/1.0 Minimal Client

Problem: Saha ekipmanında çalışan IoT cihazlar eski firmware kullanıyor ve HTTP/1.0 protokolü ile minimal HTTP client implement'i var. Bu cihazlar tüm başlıkları lowercase gönderiyor (host, content-length, connection). Backend API modern HTTP library kullanıyor ve başlıkları case-insensitive parse ediyor ama bazı middleware'ler ve legacy integration'lar büyük/küçük harf duyarlı çalışıyor. IoT cihazların firmware'i güncellenemez durumda (saha ekipmanı, erişim yok).

Çözüm: HTTP Header 1.0 Compatibility ile IoT cihazlardan gelen lowercase başlıkları normalize ederek backend ve middleware uyumluluğu sağlamak.

Konfigürasyon:

• Headers to Fix: Host, Content-Length, Content-Type, Connection, User-Agent, Date, Accept

Sonuç:

• ✅ IoT device: host: api.example.com → Kurum Servisine Host: api.example.com iletilir.
• ✅ IoT device: content-length: 256 → Kurum Servisine Content-Length: 256 iletilir.
• ✅ Backend API ve middleware tüm başlıkları doğru parse eder, device tanıma ve routing başarılı olur.
• ✅ Firmware update gerekmez, IoT cihazlar sorunsuz çalışmaya devam eder.

Senaryo 3: Microsoft Exchange: Legacy Outlook Client Custom Headers

Problem: Eski Outlook 2007/2010 versiyonları ve legacy OWA (Outlook Web Access) client'ları, Exchange-specific custom başlıkları lowercase gönderiyor. Exchange Kurum Servisi (CAS - Client Access Server) bu başlıkları (x-anchorMailbox, x-owa-version, x-requesttype) case-sensitive parse ediyor. Başlıklar yanlış format nedeniyle okunamadığında mailbox routing başarısız oluyor ve kullanıcı mailbox'ına erişemiyor.

Çözüm: HTTP Header 1.0 Compatibility ile Exchange-specific başlıkları listede tanımlanan yazımla ileterek CAS'in doğru mailbox routing yapmasını sağlamak.

Konfigürasyon:

• Headers to Fix: X-AnchorMailbox, X-OWA-Version, X-ClientApplication, X-RequestType, X-EWS-TargetVersion, X-ClientInfo, X-BEServer, X-MapiHttpCapability

Sonuç:

• ✅ Legacy Outlook: x-anchormailbox: user@example.com → Exchange'e X-AnchorMailbox: user@example.com iletilir.
• ✅ OWA client: x-owa-version: 15.0.847 → Exchange'e X-OWA-Version: 15.0.847 iletilir.
• ✅ Exchange CAS mailbox routing başlıkları doğru parse eder, kullanıcı mailbox'ına erişim sağlanır.
• ✅ Legacy Outlook client'lar upgrade edilmeden çalışmaya devam eder.

Senaryo 4: Multi-Tier Reverse Proxy: Header Case Preservation

Problem: Network architecture'da birden fazla reverse proxy layer var (CDN → TR7 → Internal Proxy → Backend). Upstream legacy proxy'lerden bazıları (X-Forwarded-For, X-Real-IP, X-Forwarded-Proto) başlıklarını lowercase'e çeviriyor. Backend uygulama bu başlıkları büyük harfle arıyor ve bulamadığında client IP ve protocol bilgilerini kaybediyor. Bu durum logging, security audit ve rate limiting'i etkiliyor.

Çözüm: HTTP Header 1.0 Compatibility ile X-Forwarded-* başlıklarını normalize ederek backend'in client bilgilerini doğru almasını sağlamak.

Konfigürasyon:

• Headers to Fix: X-Forwarded-For, X-Real-IP, X-Forwarded-Proto, X-Forwarded-Host, X-Original-URL, X-Request-ID

Sonuç:

• ✅ Upstream proxy: x-forwarded-for: 203.0.113.45 → Kurum Servisine X-Forwarded-For: 203.0.113.45 iletilir.
• ✅ Upstream proxy: x-real-ip: 203.0.113.45 → Kurum Servisine X-Real-IP: 203.0.113.45 iletilir.
• ✅ Backend uygulama client IP ve protocol bilgilerini doğru okur, logging ve audit trail eksiksiz çalışır.
• ✅ Rate limiting ve security policy'ler doğru client IP'ye göre uygulanır.

Senaryo 5: Legacy ASP.NET: Custom X-Headers Dependency

Problem: Eski ASP.NET 2.0/3.5 uygulaması, custom X- başlıklarını (X-AspNet-Version, X-Powered-By, X-User-Identity) case-sensitive okuyorlar. Frontend load balancer bu başlıkları lowercase gönderiyor. ASP.NET Request.Headers["X-User-Identity"] ile büyük harfle arıyor, başlığı bulamıyor ve authentication context oluşturamıyor. Kullanıcı login olmasına rağmen uygulama anonymous session açıyor.

Çözüm: HTTP Header 1.0 Compatibility ile ASP.NET-specific X-headers'ları normalize ederek authentication context'in doğru oluşmasını sağlamak.

Konfigürasyon:

• Headers to Fix: X-AspNet-Version, X-Powered-By, X-User-Identity, X-ClientInfo, X-RequestId, X-SessionId

Sonuç:

• ✅ Frontend LB: x-user-identity: john.doe@example.com → ASP.NET'e X-User-Identity: john.doe@example.com iletilir.
• ✅ ASP.NET Request.Headers["X-User-Identity"] ile başlığı doğru okur, authentication context oluşturulur.
• ✅ Kullanıcı authenticated session alır, anonymous session problemi çözülür.
• ✅ Legacy ASP.NET kod değişikliği gerekmez.

Senaryo 6: SOAP Web Services: WS-Security Header Normalization

Problem: Legacy SOAP web service'i WS-Security başlıklarını (X-WSSecurity-Enabled, X-WSSecurity-For) case-sensitive parse ediyor. SOAP client'ların bazıları bu başlıkları lowercase gönderiyor. Web service başlıkları bulamadığında WS-Security validation başarısız oluyor ve SOAP fault dönüyor. Bu durum critical B2B integration'ları kesiyor.

Çözüm: HTTP Header 1.0 Compatibility ile WS-Security başlıklarını normalize ederek SOAP service'in doğru validation yapmasını sağlamak.

Konfigürasyon:

• Headers to Fix: X-WSSecurity-Enabled, X-WSSecurity-For, X-SOAP-Enabled, SOAPAction, Content-Type

Sonuç:

• ✅ SOAP client: x-wssecurity-enabled: true → Web service'e X-WSSecurity-Enabled: true iletilir.
• ✅ SOAP client: soapaction: "urn:example:method" → Web service'e SOAPAction: "urn:example:method" iletilir.
• ✅ Web service WS-Security validation başarılı olur, SOAP response dönülür.
• ✅ B2B integration kesintisiz çalışır, SOAP fault'lar ortadan kalkar.