Show Content for Backend Service Errors

Show Content for Backend Service Errors Aksiyonu Nedir?

Show Content for Backend Service Errors aksiyonu, Kurum Servislerinden dönen HTTP hata kodlarında önceden tanımlanmış bir içerik sayfası gösterir. Bu aksiyon, Kurum Servisi hata yanıtlarını özelleştirilmiş içeriklerle değiştirir.

Hata kodu durumunda yönlendirme yapmak için ise Redirect for Backend Service Errors aksiyonu kullanılır.

Bu aksiyon yalnızca yanıt (response) aşamasında çalışır ve koşul gerektirmez.

Kurum Servisi Hataları vs Trafik Yöneticisi Hataları

TR7'de hata yönlendirme iki farklı kaynağa göre ayrılır:

Hata Kaynağı	Aksiyon	Çalışma Zamanı
Kurum Servisi	Bu aksiyon	Response (Kurum Servisi yanıtladıktan sonra)
Trafik Yöneticisi	Show Content for Traffic Manager Errors	Request (Kurum Servisine ulaşmadan)

Kurum Servisi Hatalarına Örnekler:

• 404 Not Found
• 500 Internal Server Error
• 403 Forbidden
• 401 Unauthorized

TR7'nin kendi ürettiği hata yanıtları (ör. hiçbir Kurum Servisi erişilebilir değilken dönen 503 veya zaman aşımında dönen 504) bu aksiyonla değiştirilmez; bu yanıtlar için Show Content for Traffic Manager Errors aksiyonu kullanılır.

Kurum Servisi Hatası İçeriği Değiştirme

Kurum Servisi uygulamaları genellikle kendi hata sayfalarını döndürür. Bu sayfalar:

• Tutarsız olabilir (farklı Kurum Servisleri farklı tasarımlar)
• Güvensiz olabilir (stack trace, server bilgisi içerebilir)
• Kullanıcı dostu olmayabilir (teknik mesajlar)

Bu aksiyon ile Kurum Servisi hata yanıtları merkezi, tutarlı ve güvenli içeriklerle değiştirilir.

Show Content for Backend Service Errors Aksiyonunun Önemi

Kurum Servisi hatalarının merkezi yönetimi, tutarlı ve güvenli kullanıcı deneyimi sağlar.

Show Content for Backend Service Errors aksiyonu;

• Kurum Servisi hata sayfalarını standartlaştırır,
• Hassas hata detaylarını (stack trace vb.) gizler,
• Kurumsal kimliğe uygun hata sayfaları sunar,
• HTTP durum kodunu özelleştirme imkanı verir,
• Farklı Kurum Servisleri için tutarlı deneyim sağlar.

Bu nedenle Show Content for Backend Service Errors aksiyonu, güvenlik ve kullanıcı deneyimi için önemli 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 Show Content for Backend Service Errors 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 Show Content for Backend Service Errors seçilir.
5. Aksiyona ait ilgili konfigürasyonlar yapılandırılır.
6. Add butonuna tıklanarak aksiyon eklenir.

Show Content for Backend Service Errors Aksiyonu Ekleme Formu

Show Content for Backend Service Errors Aksiyonu Ekleme Formu

INFO

Action Name

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

INFO

Action Type

Aksiyon tipi olarak Show Content for Backend Service Errors seçilir.

INFO

Content Page

İstemciye gösterilecek olan Content Pages bu alandan seçilir.

Daha önce oluşturulmuş içerik sayfalarından seçim yapılabilir veya Add butonuna tıklanarak yeni bir içerik sayfası aksiyon ekleme adımında da oluşturulabilir.

İçerik sayfaları Load Balancer → Profiles → Content Pages bölümünden merkezi olarak yönetilir. Detaylı bilgi Content Pages sayfasında yer alır.

İçerik Sayfası Oluşturma

İçerik sayfası yoksa Default içerik sayfası profili kullanılabilir ya da açılır listedeki Add butonuna tıklanarak hızlıca yeni bir sayfa oluşturulur. İçerik sayfaları HTML, CSS ve JavaScript içerebilir.

INFO

Error Codes

İçerik gösterilecek HTTP hata kodları seçilir. Birden fazla hata kodu seçilebilir.

Yaygın Kurum Servisi Hata Kodları:

Kod	Durum	Kurum Servisi Senaryosu
400	Bad Request	Uygulama parametresi hatalı
401	Unauthorized	Oturum süresi doldu
403	Forbidden	Yetki yetersiz
404	Not Found	Sayfa/API bulunamadı
500	Internal Server Error	Uygulama çöktü/hata verdi
502	Bad Gateway	Kurum Servisi önündeki bir ara sunucunun döndürdüğü hata
503	Service Unavailable	Uygulamanın kendi döndürdüğü bakım yanıtı

INFO

Status Code

İstemciye döndürülecek HTTP durum kodu seçilir. Varsayılan olarak 200 OK seçilidir.

Durum Kodu Seçimi

Kurum Servisinden gelen orijinal durum kodunun korunması ya da değiştirilmesi için bu alan kullanılır.

• Orijinal kodu korumak genellikle önerilir
• 200 döndürmek SEO sorunlarına yol açabilir
• API'ler için orijinal kodu korumak kritiktir

Yaygın Seçenekler:

Kod	Kullanım Senaryosu
200	Hata gizlenir (dikkatli kullanılır)
404	Bulunamadı (SEO uyumlu)
500	Sunucu hatası (API uyumlu)
503	Bakım modu

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

Koşul Durumu

Show Content for Backend Service Errors 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.

Güvenlik: Kurum Servisi Hatası Detaylarını Gizleme

Kurum Servisi hata yanıtları genellikle şunları içerebilir:

• Stack trace: Uygulama mimarisi hakkında bilgi verir
• Server bilgisi: Framework, versiyon vb.
• Veritabanı hataları: Tablo isimleri, SQL sorguları
• Dosya yolları: Sunucu dizin yapısı

Bu bilgiler saldırganlar için değerlidir. Bu aksiyon ile Kurum Servisi hata yanıtları tamamen değiştirilir ve hassas bilgiler kullanıcıdan gizlenir.

Davranış Ayrıntıları

• Content Page alanı Access denied page (English) hazır sayfasıyla ön seçili gelir; dokunulmazsa hata durumunda bu sayfa gösterilir.
• Listedeki Default profile seçeneği yalnızca TR7 logosu taşıyan boş bir sayfadır; hata metni içermez, kullanılması önerilmez.
• Error Codes alanı boş bırakılabilir; hiçbir kod seçilmezse aksiyon hiçbir şey yapmaz ve uyarı verilmez.
• Aksiyona bağlı içerik sayfası silinirse aksiyon sessizce devre dışı kalır; silme işlemi engellenmez.
• İçerik metninde akıllı değişkenler çözülür; istemci adresi veya zaman damgası sayfada gösterilebilir.
• Aksiyon koşul alamaz; formda Conditions alanı bulunmaz. Sayaç da desteklenmediğinden Hit Counter ve Set Variable on Hit alanları yer almaz.
• vService başına sayı sınırı yoktur; aynı hata kodu için ikinci bir tanım yapılırsa uyarı verilmez ve tanımlardan yalnızca biri geçerli olur. Aynı kod için bir yönlendirme aksiyonu da tanımlıysa hangisinin uygulanacağı aksiyon sırasına bağlıdır.
• Status Code listesinde içerik döndürülemeyen kodlar (1xx, 204, 304) yer almaz.

Yalnızca Kurum Servisinin döndürdüğü yanıtları kapsar

Bu aksiyon, Kurum Servisinden gerçekten dönen yanıtların durum kodlarını değerlendirir.

Kurum Servisine ulaşılamadığında (servis kapalı, bağlantı zaman aşımı) dönen 502/503/504 yanıtlarını TR7'nin kendisi üretir ve bu aksiyon devreye girmez. Bu durumlar için Show Content for Traffic Manager Errors aksiyonu kullanılır; iki aksiyon aynı vService'te birlikte tanımlanabilir.

WAF engelleme, CAPTCHA, karantina ve Block aksiyonunun yanıtları da bu aksiyonun kapsamı dışındadır.

WARNING

Gösterilen içeriğin Content-Type bilgisi aksiyondan değil, seçilen içerik sayfasının kendi ayarından gelir. JSON yanıt döndürülecekse içerik sayfası application/json olarak tanımlanmalıdır. Yanıtta karakter kümesi bilgisi gönderilmediğinden Türkçe içerikli sayfalarda içeriğin UTF-8 olarak tanımlanmış olması önerilir.

Operasyonel ve Güvenli Kullanım Önerileri

• 500 Hatalarını Mutlaka Özelleştirin. 500 hataları stack trace içerebilir. Bu aksiyonla Kurum Servisi 500 yanıtlarını güvenli içeriklerle değiştirin.
• 404 için yardımcı içerik sunulur. 404 sayfalarında arama kutusu, popüler sayfalar ya da site haritası yer alır.
• Tek Durum Kodu Seçilir. API'ler ve SEO için orijinal HTTP durum kodunu korumak önemlidir.
• Tutarlı tasarım kullanılır. Tüm hata sayfalarında aynı tasarım dili uygulanır; bu, profesyonel bir görünüm sağlar.
• Test Ortamında Doğrulayın. Hata senaryolarını test ortamında simüle ederek içeriklerin doğru gösterildiğini doğrulayın.

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: Stack Trace ve Hassas Bilgi Gizleme (500 Internal Server Error)

Problem: Kurum Servisi application crash yaşadığında 500 Internal Server Error döndürüyor ve yanıt gövdesinde full stack trace, database connection string, framework versiyonu ve internal dosya yolları gösteriliyor. Bu bilgiler saldırganlar için değerli reconnaissance data sağlıyor ve güvenlik açığı oluşturuyor.

Çözüm: Kurum Servisinden gelen 500 hataları yakalanır ve stack trace içeren yanıtlar genel, güvenli bir hata sayfasıyla değiştirilir.

Konfigürasyon:

• Content Page: Internal Server Error - Generic
• Error Codes: 500, 502, 503
• Status Code: 500 Internal Server Error

Sonuç:

• ✅ Security hardening → Stack trace, database errors, file paths dışarı sızmaz.
• ✅ Information disclosure önleme → Framework versiyonu, technology stack gizlenir.
• ✅ Professional görünüm → Generic error message kullanıcı deneyimini korur.
• ✅ Compliance → PCI-DSS, OWASP security best practices'e uyumlu.

Gizlenen Bilgiler:

• Java/Python/PHP stack traces
• Database connection errors (table names, SQL queries)
• Internal server paths (/var/www/app/...)
• Framework versions (Django 2.1.5, Spring Boot 2.3.0)

Senaryo 2: Arama ve Navigasyon ile Özel 404 Sayfası

Problem: Kullanıcılar mevcut olmayan sayfalara erişmeye çalıştığında Kurum Servisi basit bir "404 Not Found" mesajı döndürüyor. Bu sayfalarda hiçbir yardımcı bilgi yok ve kullanıcılar siteyi terk ediyor. Bounce rate yüksek ve kullanıcı deneyimi kötü.

Çözüm: 404 hatalarını arama kutusu, popüler sayfalar ve site haritası içeren kullanıcı dostu özel sayfa ile değiştirin.

Konfigürasyon:

• Content Page: 404 - Page Not Found with Search
• Error Codes: 404
• Status Code: 404 Not Found

Sonuç:

• ✅ Bounce rate azalır → Kullanıcılar arama ile istedikleri içeriği bulabilir.
• ✅ SEO dostu → 404 durum kodu korunur, arama motorları doğru algılar.
• ✅ User engagement → Popüler sayfalar ve sitemap ile navigasyon seçenekleri sunulur.
• ✅ Brand consistency → Tüm Kurum Servisleri için tek branded 404 sayfası.

İçerik Sayfası Öğeleri:

<h1>Sayfa Bulunamadı</h1>
<input type="search" placeholder="Arama...">
<h3>Popüler Sayfalar:</h3>
<ul>
  <li><a href="/">Ana Sayfa</a></li>
  <li><a href="/products">Ürünler</a></li>
</ul>

Senaryo 3: Multi-Backend Error Standardizasyonu

Problem: Microservice mimarisi kullanılıyor ve farklı Kurum Servisleri farklı teknolojilerle yazılmış (Java Spring, Python Flask, Node.js Express). Her servis kendi error page formatını döndürdüğünden kullanıcı deneyimi tutarsız. Bir serviste modern tasarım, diğerinde HTML 1.0 stili sayfa görünüyor.

Çözüm: Tüm Kurum Servisi hataları tek bir kurumsal, profesyonel hata sayfasıyla standartlaştırılır.

Konfigürasyon:

• Content Page: Service Error - Corporate Branded
• Error Codes: 400, 401, 403, 404, 500, 502, 503
• Status Code: 500

Sonuç:

• ✅ Tutarlı deneyim → Java, Python, Node.js servisleri aynı error page döner.
• ✅ Corporate branding → Tüm hata sayfaları kurumsal kimliğe uygun.
• ✅ Merkezi yönetim → Error page güncellenmesi tek noktadan yapılır.
• ✅ API uyumluluğu → Orijinal durum kodu korunur, client'lar doğru algılar.

Mimari Avantajı:

• Legacy Java app: 500 → TR7 branded error page (500)
• Modern Python API: 404 → TR7 branded error page (404)
• Node.js microservice: 503 → TR7 branded error page (503)

Senaryo 4: Kurum Servisi Bakım Modu Bildirimi

Problem: Kurum Servisi deployment veya database migration sırasında 503 Service Unavailable döndürüyor. Kullanıcılar generic browser error görüyor ve bakımın ne zaman biteceğini, neden bakımda olduğunu bilmiyorlar. Support ekibine çok sayıda ticket açılıyor.

Çözüm: 503 hatalarını tahmini bitiş zamanı (ETA), bakım nedeni ve alternatif iletişim bilgileri içeren profesyonel bakım sayfası ile değiştirin.

Konfigürasyon:

• Content Page: Scheduled Maintenance with ETA
• Error Codes: 503
• Status Code: 503 Service Unavailable

Sonuç:

• ✅ Kullanıcı bilgilendirme → Bakım nedeni, tahmini süre, alternatif kanallar gösterilir.
• ✅ Support yükü azalır → Proactive communication, ticket sayısını düşürür.
• ✅ SEO korunur → 503 kodu arama motorlarına temporary olduğunu bildirir.
• ✅ Professional görünüm → Generic error yerine branded maintenance page.

İçerik Örneği:

<h1>Planlı Bakım</h1>
<p>Veritabanı migration işlemi devam ediyor.</p>
<p>Tahmini Bitiş: 14:30 (30 dakika)</p>
<p>Destek: support@example.com</p>

Senaryo 5: API Gateway Error Dönüşümü (HTML to JSON)

Problem: REST API Kurum Servisi hata verdiğinde HTML formatted error page döndürüyor. API client'ları (mobile app, SPA, third-party integrations) JSON response bekliyor ve HTML parse edemediğinden crash oluyor. API contract bozuluyor ve entegrasyonlar başarısız oluyor.

Çözüm: Kurum Servisi HTML error'larını standardized JSON API response formatına çevirin.

Konfigürasyon:

• Content Page: API Error Response - JSON Format
• Error Codes: 500, 502, 503, 504
• Status Code: 500

Sonuç:

• ✅ API contract korunur → Client'lar her zaman JSON response alır.
• ✅ Client crash önleme → HTML parse error'ları ortadan kalkar.
• ✅ Standardization → Tüm error response'lar tutarlı JSON formatında.
• ✅ Third-party uyumluluk → API integration'lar stabil çalışır.

JSON Error Response Formatı:

{
  "error": {
    "code": 500,
    "message": "Internal Server Error",
    "timestamp": "2025-01-31T10:30:00Z"
  }
}

Content-Type: application/json