Làm thế nào để thực hiện một yêu cầu chunked qua nginx

Question

Có vẻ như nginx không hỗ trợ tốt các yêu cầu chunked. Nhưng tôi đang cố gắng để có được một câu trả lời dứt khoát (và hiện tại). Tôi có một khách hàng thực hiện một yêu cầu SOAP đến một máy chủ từ một máy khách Java đặt tiêu đề Transfer-Encoding: chunked. Tất cả đều hoạt động tốt khi tôi kết nối trực tiếp với ứng dụng của tôi trên Tomcat.

Nhưng khi tôi đặt nginx giữa chúng, thì mọi thứ sẽ bị hỏng.

Để thêm một vài chi tiết: Tôi đang làm việc với CloudFoundry. Tôi đang sử dụng Micro Cloud Foundry để xác nhận rằng mọi thứ hoạt động như mong đợi trong trường hợp không có nginx. Nhưng yêu cầu của tôi là sử dụng cloudfoundry.com, vì vậy tôi không có khả năng bỏ qua nginx ở đó.

This question and answer nói rằng đây có lẽ là giải pháp thay thế duy nhất của tôi: http://wiki.nginx.org/NginxHttpChunkinModule. Nhưng cách giải quyết đó không có sẵn, vì tôi không thể sửa đổi cấu hình trên cloudfoundry.com.

This question cũng giống như vậy, nhưng nó thực sự bao gồm yêu cầu này ngược lại. Nó bao gồm các câu trả lời chunked chứ không phải là yêu cầu chunked.

Vậy làm thế nào về bất kỳ thay đổi nào trên máy khách để giải quyết vấn đề này? Có thể gửi cả hai tiêu đề Transfer-Encoding: chunked và Content-Length: 123 làm tiêu đề không? Khu vực này là mới đối với tôi, nhưng có vẻ như từ các dự án như Apache HttpComponents rằng một trong những sẽ thiết lập hoặc chiều dài hoặc chunking nhưng không phải cả hai. Điểm chunking là bạn không cần biết chiều dài khi yêu cầu bắt đầu. Tôi có thể nói với khách hàng của tôi để sử dụng HTTP/1.0 và chơi tốt đẹp với nginx mà không chunking? Có những ý tưởng giải pháp khác mà tôi quên không?

Answer 1

Tôi đã thu thập câu trả lời cho tất cả các phần của câu hỏi này.

Cơ sở nginx không hỗ trợ các yêu cầu chunked (như Alexander xác nhận!). Nginx có thể hỗ trợ yêu cầu chunked bằng cách sử dụng NginXHttpCunkinModule (như câu hỏi của tôi đề cập đến). Tốt hơn: mô-đun này đã tốt nghiệp từ trạng thái beta sang chất lượng sản xuất hơn 18 tháng trước. Tốt nhất: Tôi đã nói chuyện với một số thành viên của nhóm kỹ thuật CloudFoundry tại một số meetup gần đây; họ xác nhận rằng nó được lên kế hoạch để thêm mô-đun này vào phiên bản nginx của họ. Đã giải quyết được sự cố. (Vâng, nó được giải quyết hoàn toàn trong thời gian dài. Nhưng chúng tôi không có ngày chính xác để mong đợi điều này.)

Do đó, giải pháp ngắn hạn cũng sẽ tốt đẹp. Tôi tìm thấy một.

Trả lời câu hỏi của tôi hướng đến Alexander: Không thể gửi "Nội dung dài" với các tin nhắn được chunked. Đó thực sự là điểm của các tin nhắn được chunked: bạn bắt đầu gửi chúng trước khi bạn có đầy đủ nội dung, vì vậy bạn không thể biết được độ dài nào được nêu ra. Vì vậy, ý tưởng của mình để tránh yêu cầu chunked là chính xác. Nhưng để thực tế hơn tôi sẽ nói, "Sử dụng HTTP/1.0 thay vì HTTP/1.1." Điều này có tác dụng không gửi tin nhắn chunked. Chúng tôi đã có thể vá tạm thời khách hàng của mình để kiểm tra ý tưởng này. Nó đã làm việc. Nhưng chúng tôi không có kế hoạch tung ra một bản vá công khai. Nó có vẻ phản tác dụng để làm cho tất cả mọi người sử dụng một giao thức mười tuổi (và một thư viện khách hàng không được hỗ trợ 10 năm tuổi!) Để giải quyết vấn đề cho tình huống này. Thay vào đó, tôi sẽ sử dụng ứng dụng khách bị tấn công khi cần, tôi sẽ gửi email cho những người khác thấy cần thiết, và chúng tôi sẽ đợi CloudFoundry cập nhật lên HttpChunkin và HTTP/1.1.

Answer 2

Nginx không thực sự hỗ trợ các yêu cầu chunked. Nó sẽ trả lại 411 Content Length required khi không có tiêu đề Content-Length.

Vì bạn đang kiểm soát mã khách hàng của mình, tôi đoán lựa chọn duy nhất là tránh sử dụng các yêu cầu chunked và chỉ định Content-Length một cách rõ ràng.