Йдеться про підтримку HTTP-режиму, який дозволяє декілька запитів на ресурси надходити через один сеанс TCP (і, з SSL, один сеанс SSL). Це має велике значення для продуктивності веб-сайту SSL, оскільки без збереження інформації потрібне рукостискання SSL для кожного запитуваного ресурсу.
Отож, проблема тут - одна велика неперервна сесія від клієнта аж до бек-сервера. Це важлива річ для продуктивності і звичайно сприймається для сучасних серверів HTTP, але цей патч говорить, що він не підтримує його. Давайте розберемося, чому ..
Сеанс збереження в живому режимі - це просто більше запитів один за одним - як тільки сервер закінчує свою відповідь на один запит, сервер не надсилає FINпакет для завершення сеансу TCP; клієнт може просто надіслати ще одну партію заголовків.
Щоб зрозуміти, що робить цей патч, ось приклад тривалої розмови:
Клієнт:
GET / HTTP/1.1
Connection: keep-alive
Host: domain.com
...
Сервер:
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Server: Apache
Content-Length: 34
.... (other headers)
<html><head>content!</head></html>
Ось де зупиниться неживе з'єднання. Але, Keep-Live дозволяє клієнту просто звільнити інше:
GET /images/some/image.on.the.page.jpg HTTP/1.1
Connection: keep-alive
Host: domain.com
...
Для клієнтського ідентифікатора, який здійснює проксі, деякі зворотні проксі можуть додавати в X-Forwarded-Forзаголовок у кожному запиті клієнта. Це повідомляє серверу висхідного потоку, звідки надходить запит (замість кожного запиту, що починається з IP-адреси зворотного проксі-сервера), для розумності в журналі та інших потреб програми.
X-Forwarded-ForЗаголовок повинен бути введений в кожен і кожен запит клієнта ресурсів відправленого через Keep-Alive з'єднання, так як повні заголовки посилаються кожен раз; обробка X-Forwarded-Forзаголовка і переклад у нього, як "справжній" IP-запит, здійснюються на основі запиту, а не за TCP-підтримкою "живого сеансу". І ей, можливо, там є якесь дивовижне програмне забезпечення для зворотного проксі-сервера, яке використовує один сеанс збереження в живому режимі для обслуговування запитів від декількох клієнтів.
Ось тут ця латка виходить з ладу.
Патч на цьому сайті спостерігає за буфером сеансу TCP для кінця першого набору заголовків HTTP у потоці та вводить новий заголовок у потік після закінчення цього першого набору заголовків. Після цього він вважає X-Forwarded-Forвиконану роботу і припиняє сканувати кінець нових наборів заголовків. Цей метод не обізнаний про всі майбутні заголовки, що надходять через наступні запити.
Не можу насправді звинуватити їх; stunnel насправді не був створений для обробки та перекладу вмісту своїх потоків.
Ефект, який це матиме у вашій системі, полягає в тому, що при першому запиті потокового потоку буде X-Forwarded-Forвведено заголовок належним чином, і всі наступні запити спрацюють нормально - але вони не матимуть заголовка.
Якщо немає іншого патча для введення заголовка, який може обробляти декілька запитів клієнтів на з'єднання (або отримати цей засіб за допомогою наших друзів у "Переповнення стека"), можливо, вам доведеться переглянути інші варіанти припинення SSL.