Chuyển tiếp byte gzip cùng các tiêu đề mô tả chúng

Chọn tải trọng đã mã hóa hoặc đã giải mã trong proxy dựa trên Requests, sau đó cấp cho phản hồi hạ nguồn các tiêu đề content phù hợp và khung riêng của nó.

Nếu Requests đã giải nén một thân, việc chuyển tiếp nó với Content-Encoding: gzip yêu cầu máy khách tiếp theo giải nén lại. Quyết định biểu diễn tải trọng nào mà proxy gửi trước khi sao chép các tiêu đề của nó.

Tải trọng đã gửiTiêu đề content
Byte đã mã hóa gốcGiữ nguyên mã hóa áp dụng và độ dài tải trọng chính xác
Byte đã giải mãXóa mã hóa đã giải; xóa hoặc tính lại độ dài tương ứng

Đối với byte tải trọng đã mã hóa, đoạn này đọc luồng thô của urllib3 mà không giải mã content:

with requests.get(url, stream=True, timeout=(5, 30)) as upstream:
    upstream.raise_for_status()
    for block in upstream.raw.stream(65536, decode_content=False):
        downstream.write(block)

downstream là đầu ra phản hồi hiện có. Trạng thái và tiêu đề của nó phải tuân theo chính sách đã chọn; đoạn này không triển khai một máy chủ proxy hoàn chỉnh.

Khung truyền tách biệt với mã hóa content gzip. Thư viện HTTP thượng nguồn đã xử lý khung, bao gồm việc loại bỏ khối, vì vậy đừng sao chép Transfer-Encoding một cách mù quáng. Máy chủ hạ nguồn tự đóng khung phản hồi của mình ngay cả khi tải trọng vẫn được mã hóa gzip.

response.text theo sau là mã hóa UTF-8 cũng thay đổi biểu diễn và không thể bảo toàn dữ liệu nhị phân tùy ý. Đóng hoặc tiêu thụ phản hồi thượng nguồn trên mọi đường đi, và xử lý lỗi HTTP theo hợp đồng proxy: ví dụ này ném chúng thay vì chuyển tiếp.

Bài viết liên quan