Ana içeriğe atla

Genel Bakış

API Gateway, istemci ile Backend API arasındaki mesaj akışında içerik sıkıştırma ve açma işlemlerini otomatik olarak yönetir. Bu sayede:
  • Politikalar her zaman açık (sıkıştırılmamış) metin üzerinde çalışır
  • İstemcinin desteklediği sıkıştırma yöntemine göre yanıt otomatik olarak sıkıştırılır
  • Backend API’nin hangi formatta yanıt verdiğinden bağımsız olarak doğru işlem yapılır
Bu sayfa, sıkıştırma/açma işleminin gateway düzeyinde nasıl çalıştığını açıklar. Politikaların mesaj akışındaki yeri ve çalışma sırası için Mesaj İşleme ve Politika Uygulama sayfasına bakabilirsiniz.

Desteklenen Sıkıştırma Yöntemleri

YöntemContent-Encoding DeğeriAçıklama
gzipgzipEn yaygın yöntem. Tüm tarayıcılar ve HTTP istemcileri destekler.
deflatedeflatezlib formatında sıkıştırma. gzip’e göre daha az yaygın.
BrotlibrGoogle tarafından geliştirilen, yüksek sıkıştırma oranına sahip yöntem.
ZstandardzstdFacebook tarafından geliştirilen, hız ve oran dengesi iyi olan yöntem.
compresscompressEski LZW tabanlı yöntem. Sadece açma (decompress) desteklenir, sıkıştırma yapılamaz.
identityidentitySıkıştırma yok. RFC 9110’a göre kullanımdan kaldırılmış (deprecated) bir değerdir.

İstek Akışı

İstemciden gelen sıkıştırılmış bir istek mesajı şu aşamalardan geçer:
İSTEMCİ                          GATEWAY                              BACKEND API
   │                                │                                      │
   │  ── İstek (CE: gzip) ──────>  │                                      │
   │                                │  1. Sıkıştırma algıla (gzip)        │
   │                                │  2. Mesajı aç                        │
   │                                │  3. Politikaları uygula (açık metin) │
   │                                │  4. Tekrar sıkıştır (gzip)          │
   │                                │  ── İstek (CE: gzip) ────────────>   │
   │                                │                                      │

Aşamalar

1

Sıkıştırma Algılama

İstek mesajındaki Content-Encoding başlığı okunur ve sıkıştırma yöntemi belirlenir. Başlık değerine ek olarak, mesaj içeriğinin ilk baytları kontrol edilerek gerçekten sıkıştırılmış olduğu doğrulanır.
2

Mesajı Açma

Belirlenen yönteme göre mesaj içeriği açılır (decompress). Açma işlemi başarısız olursa mesaj olduğu gibi bırakılır.
3

Politika Uygulama

İstek politikaları, açılmış düz metin üzerinde çalışır. Bu sayede dönüştürme, doğrulama ve filtreleme politikaları sıkıştırma yönteminden bağımsız olarak işlem yapabilir.
4

Tekrar Sıkıştırma

Politikalar uygulandıktan sonra mesaj, orijinal sıkıştırma yöntemiyle tekrar sıkıştırılarak Backend API’ye gönderilir.
İstisnalar: multipart/form-data türündeki isteklerde sıkıştırma açılmaz. Çünkü açma işlemi multipart sınır (boundary) yapısını bozar.

İç İçe (Stacked) Sıkıştırma

Bir istek mesajı birden fazla katmanlı sıkıştırma içerebilir (örneğin Content-Encoding: gzip, br). Bu durumda gateway, katmanları sağdan sola sırayla açar: önce Brotli, sonra gzip. Backend API’ye mesaj açık metin olarak gönderilir.

Yanıt Akışı

Backend API’den gelen yanıt mesajı, istemcinin Accept-Encoding başlığına göre işlenir:
BACKEND API                       GATEWAY                              İSTEMCİ
   │                                │                                      │
   │  ── Yanıt (CE: deflate) ───>   │                                      │
   │                                │  1. Sıkıştırma algıla (deflate)      │
   │                                │  2. Mesajı aç                        │
   │                                │  3. Politikaları uygula (açık metin) │
   │                                │  4. İstemci AE kontrol (gzip kabul)  │
   │                                │  5. gzip ile sıkıştır                │
   │                                │  ── Yanıt (CE: gzip) ────────────>   │
   │                                │                                      │

Encoding Seçim Sırası

İstemcinin Accept-Encoding başlığında birden fazla yöntem varsa, gateway şu sabit sırayla seçim yapar:
  1. gzip
  2. deflate
  3. br (Brotli)
  4. zstd (Zstandard)
Accept-Encoding başlığındaki q-value (kalite) değerleri şu an için dikkate alınmaz. Bu, sektördeki diğer gateway’lerle (Nginx dahil) tutarlı bir davranıştır.

Accept-Encoding: * (Wildcard)

İstemci Accept-Encoding: * gönderdiğinde, gateway bunu “tüm yöntemleri kabul ediyorum” olarak yorumlar ve yukarıdaki sıraya göre en uygun yöntemi seçer (RFC 9110 §12.5.3 uyumlu).

İkili (Binary) İçerik Davranışı

Resim, video, PDF gibi ikili içerikler metin içeriklerden farklı işlenir:
İndirme özelliği açık olan proxy’lerde ikili içerik doğrudan akış (streaming) ile istemciye iletilir. Bu yöntemde:
  • İçerik bellekte tutulmaz, parça parça aktarılır
  • Büyük dosyalarda bellek tüketimi minimum kalır
  • İstemcinin desteklemediği bir sıkıştırma varsa otomatik olarak açılır
  • Politikalar yanıt gövdesini değiştiremez (içerik zaten gönderilmeye başlamıştır)
İndirme özelliği kapalı olan proxy’lerde ikili içerik Base64 formatına dönüştürülerek politika hattına girer. Politikalar Base64 kodlanmış metin üzerinde çalışır. İstemciye gönderimde orijinal ikili format geri oluşturulur.

Zorla Açma (Force Decompress Download)

Zorla Açma özelliği, Backend API’nin sıkıştırılmış gönderdiği ikili içeriğin koşulsuz olarak açılmasını sağlar. Bu özellik, proxy’nin bağlantı ayarlarından etkinleştirilir.

Ne Zaman Kullanılır?

  • Backend API her zaman sıkıştırılmış yanıt veriyor ancak Content-Encoding başlığını set etmiyorsa
  • İstemcilerin sıkıştırılmış içeriği işleyemediği durumlarda
  • Sıkıştırma yönteminden bağımsız olarak her zaman açık içerik istendiğinde

Otomatik Algılama

Zorla Açma aktifken ve Backend API Content-Encoding başlığı göndermemişse, gateway mesaj içeriğinin ilk baytlarını inceleyerek sıkıştırma yöntemini otomatik olarak algılar:
YöntemAlgılanabilir mi?
gzipEvet
zstdEvet
deflateKısmi (zlib sarmalı ile)
compressEvet
BrotliHayır (ayırt edici bayt dizisi yoktur)
Brotli sıkıştırması, ayırt edici bir bayt dizisine (magic bytes) sahip olmadığından otomatik algılanamaz. Backend API Brotli kullanıyorsa Content-Encoding: br başlığını mutlaka göndermeli veya farklı bir yöntem tercih edilmelidir.

no-transform Davranışı

Backend API, yanıtında Cache-Control: no-transform başlığı gönderdiğinde, gateway içerik üzerinde hiçbir sıkıştırma veya açma dönüşümü yapmaz:
  • Backend’in sıkıştırma yöntemi ve içeriği olduğu gibi istemciye iletilir
  • Content-Encoding başlığı değiştirilmez
  • Vary ve Warning başlıkları eklenmez
Bu davranış, CDN ve önbellek katmanlarının tutarlılığını korumak için önemlidir.

Otomatik Eklenen Başlıklar

Gateway, sıkıştırma dönüşümü uyguladığında yanıta otomatik olarak iki başlık ekler:
BaşlıkDeğerAçıklama
VaryAccept-EncodingÖnbellek katmanlarına, yanıtın istemcinin encoding tercihine göre değiştiğini bildirir
Warning214 - "Transformation Applied"İçerik üzerinde dönüşüm yapıldığını belirtir (RFC 9111 §5.5)

Kısıtlar ve Bilinen Davranışlar

Gateway, istemcinin Accept-Encoding başlığındaki q-value tercihlerini dikkate almaz. Örneğin istemci br;q=1.0, gzip;q=0.5 gönderirse, gateway Brotli yerine gzip’i seçer. Bu, Nginx ve çoğu gateway ile tutarlı bir davranıştır.
Brotli sıkıştırmasının ayırt edici bayt dizisi (magic bytes) yoktur. Zorla Açma özelliği aktif olsa bile, Content-Encoding başlığı olmadan Brotli içerik algılanamaz.
İkili içeriklerde iç içe (stacked) sıkıştırma kısmen desteklenir. Metin içeriklerde tüm katmanlar sırayla açılırken, ikili streaming modunda yalnızca dış katman işlenir.
İstemci Accept-Encoding: identity;q=0 gönderirse (sıkıştırılmamış içerik istemiyorum), RFC 9110’a göre gateway 406 yanıtı verebilir. Ancak Nginx ve diğer gateway’lerle tutarlı olarak, gateway düz metin olarak yanıt verir ve 406 döndürmez.
İndirme veya Zorla Açma aktifken ikili içerik streaming ile gönderilir. Bu modda yanıt politikaları mesaj gövdesini değiştiremez çünkü içerik zaten istemciye aktarılmaya başlamıştır. İstek politikaları bu durumdan etkilenmez.

Sonraki Adımlar

Mesaj İşleme ve Politika Uygulama

Politikaların mesaj akışındaki yerini ve çalışma sırasını öğrenin

Routing ve Upstream

Backend API’ye yönlendirme ve yük dengeleme ayarlarını öğrenin

Politika Nedir?

Politika kavramını ve türlerini öğrenin

API Gateway

API Gateway bileşeninin mimarisini öğrenin