Đây là về HTTP giữ nguyên, cho phép nhiều yêu cầu tài nguyên đi qua một phiên TCP duy nhất (và, với SSL, một phiên SSL duy nhất). Điều này có tầm quan trọng rất lớn đối với hiệu suất của một trang web SSL, vì nếu không có sự tồn tại, sẽ cần một cái bắt tay SSL cho mỗi tài nguyên được yêu cầu.
Vì vậy, mối quan tâm ở đây là một phiên duy trì lớn từ máy khách đến máy chủ phụ trợ. Đây là một điều quan trọng đối với hiệu suất và được coi là vấn đề tất nhiên đối với các máy chủ HTTP hiện đại, nhưng bản vá này cho biết nó không hỗ trợ nó. Hãy xem tại sao ..
Một phiên duy trì chỉ là nhiều yêu cầu lần lượt - một khi máy chủ kết thúc phản hồi của nó đối với một yêu cầu, máy chủ không gửi một FINgói để kết thúc phiên TCP; khách hàng có thể chỉ cần gửi một loạt các tiêu đề khác.
Để hiểu bản vá đó đang làm gì, đây là một ví dụ về cuộc trò chuyện trực tiếp:
Khách hàng:
GET / HTTP/1.1
Connection: keep-alive
Host: domain.com
...
Người phục vụ:
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Server: Apache
Content-Length: 34
.... (other headers)
<html><head>content!</head></html>
Đây là nơi một kết nối không còn tồn tại sẽ dừng lại. Nhưng, giữ cho phép khách hàng bắn ra một thứ khác:
GET /images/some/image.on.the.page.jpg HTTP/1.1
Connection: keep-alive
Host: domain.com
...
Đối với ID khách hàng trong ủy quyền, một số proxy ngược có thể thêm vào X-Forwarded-Fortiêu đề trong mỗi yêu cầu của máy khách. Điều đó cho biết máy chủ ngược dòng nơi yêu cầu đến từ (thay vì mọi yêu cầu bắt đầu từ IP của proxy ngược), cho sự tỉnh táo trong việc đăng nhập và các nhu cầu ứng dụng khác.
Các X-Forwarded-Fortiêu đề cần phải được tiêm vào mỗi và mọi yêu cầu tài nguyên khách hàng gửi thông qua kết nối giữ-sống, như tiêu đề đầy đủ được gửi mỗi lần; việc xử lý X-Forwarded-Fortiêu đề và dịch thành IP yêu cầu "thực" được thực hiện trên cơ sở mỗi yêu cầu, không phải trên mỗi TCP-keep-live-session, trên cơ sở. Và này, có thể có một số phần mềm proxy ngược tuyệt vời ngoài kia sử dụng một phiên duy nhất cho các yêu cầu dịch vụ từ nhiều khách hàng.
Đây là nơi bản vá này thất bại.
Bản vá tại trang web đó xem bộ đệm của phiên TCP cho phần cuối của bộ tiêu đề HTTP đầu tiên trong luồng và đưa tiêu đề mới vào luồng sau khi kết thúc bộ tiêu đề đầu tiên đó. Sau khi hoàn thành, nó sẽ xem xét X-Forwarded-Forcông việc đã hoàn thành và dừng quét tìm phần cuối của các tiêu đề mới. Phương pháp này không có nhận thức về tất cả các tiêu đề trong tương lai đến thông qua các yêu cầu tiếp theo.
Không thể thực sự đổ lỗi cho họ; stunnel không thực sự được xây dựng để xử lý và dịch nội dung các luồng của nó.
Hiệu quả mà điều này sẽ có trên hệ thống của bạn là yêu cầu đầu tiên của luồng phát trực tiếp sẽ được X-Forwarded-Fortiêm tiêu đề đúng cách và tất cả các yêu cầu tiếp theo sẽ hoạt động tốt - nhưng chúng sẽ không có tiêu đề.
Trừ khi có một bản vá tiêm tiêu đề khác có thể xử lý nhiều yêu cầu của khách hàng trên mỗi kết nối (hoặc điều chỉnh cái này với sự trợ giúp của bạn bè chúng tôi tại Stack Overflow), bạn có thể cần xem xét các tùy chọn khác cho việc chấm dứt SSL của mình.