Phản hồi của Requests trông bị lỗi sau proxy? Kiểm tra hỗ trợ Brotli
Accept-Encoding:br được sao chép có thể vượt qua khả năng giải mã của môi trường Requests được lưu trữ.
So sánh máy tính xách tay và tiến trình được lưu trữ ở hai tầng khác nhau:
| Tầng | Câu hỏi |
|---|---|
| Content-Encoding | Máy khách có giải nén được các byte gzip/deflate/Brotli trả về không? |
| Charset | Các byte đã giải nén trở thành văn bản như thế nào? |
Requests thường xử lý gzip/deflate; Brotli cần một thư viện đã cài đặt và được hỗ trợ. Một Accept-Encoding được sao chép thủ công có thể quảng bá br trong khi môi trường này không thể giải mã nó. Việc chọn văn bản UTF-8 không giải nén Brotli.
Khi cố ý giới hạn thương lượng:
response = session.get(
url,
proxies={"https": "http://proxy.example:8080"},
headers={"Accept-Encoding": "gzip, deflate"},
timeout=30,
)
response.raise_for_status()Dùng Session hiện có, URL HTTPS và các tiêu đề/xác thực cần thiết. So sánh Accept-Encoding gửi đi, Content-Encoding nhận vào và hỗ trợ gói trên cả hai máy; một trung gian biến đổi cũng có thể cung cấp siêu dữ liệu cũ. Một so sánh trang công khai riêng có thể dùng Danh sách proxy HTTP cho URL proxy của nó ở nơi trung gian công cộng được phép, nhưng không mang thông tin đăng nhập proxy kế thừa, tiêu đề tài khoản sao chép hay dữ liệu nội dung riêng tư.
Nếu không, hãy ưu tiên thương lượng thông thường của máy khách. Các giao diện content/text tiện lợi của Requests giải mã mã hóa được hỗ trợ, vì vậy đừng giải nén lại đầu ra của chúng chỉ vì tiêu đề nêu tên nó.