Đọc tệp tải lên theo từng khối không cần HTTP dạng chunked
Tách việc đọc có giới hạn của ứng dụng khỏi cách đóng gói thông điệp HTTP/1.1 khi một tệp tải lên hoạt động khác đi qua forward proxy.
Không. Máy khách có thể đọc một tệp lớn trong các bộ đệm nhỏ và gửi nó với Content-Length đã biết. Việc đọc có giới hạn kiểm soát mức dùng bộ nhớ; cách đóng gói HTTP cho bên nhận biết phần thân yêu cầu kết thúc ở đâu.
Một tệp ổn định mà thư viện HTTP biết độ dài byte khác với một bộ tạo sinh ra lượng dữ liệu không xác định. Hãy dùng giao diện thân mà thư viện hỗ trợ cho cả hai nguồn. Bạn không cần ghép toàn bộ tệp thành một chuỗi chỉ để cung cấp độ dài.
Với HTTP/1.1, hãy kiểm tra cách đóng gói thực sự được gửi đi: Content-Length hoặc chunked transfer coding theo quy tắc của giao thức. Mã hóa chunked thêm các dấu kích thước bên ngoài nội dung tệp. Đừng kết hợp các trường đóng gói mâu thuẫn và đừng đoán độ dài để thuyết phục proxy chấp nhận tệp tải lên.
Nếu tải lên qua proxy thất bại, hãy ghi lại phiên bản HTTP, nguồn của thân và lần từ chối đầu tiên. Phản hồi 411 gợi ý một hướng điều tra khác với kết nối bị đóng giữa chừng thân. Nếu thay vào đó các lần thử lại xác thực thất bại, hãy kiểm tra liệu thân tải lên có thể phát lại được không. Việc thay đổi kích thước bộ đệm đọc của ứng dụng có thể để nguyên cách đóng gói yêu cầu như cũ.
Tuyến đường quan trọng với quan sát đó. Chuyển tiếp văn bản thuần phơi bày cách đóng gói HTTP của tệp tải lên cho proxy; HTTPS đầu-cuối thông thường đặt nó bên trong một đường hầm. HTTP/2 dùng cách đóng gói riêng. Vì vậy những hạn chế lịch sử của Squid giải thích một số lỗi cũ cụ thể, chứ không phải quy tắc rằng mọi proxy hiện nay đều từ chối tải lên dạng luồng.