프록시 뒤에서 Requests 응답이 깨져 보이나요? Brotli 지원을 확인하세요
복사한 Accept-Encoding:br은 호스팅된 Requests 환경의 디코더 지원을 앞지를 수 있습니다.
노트북과 호스팅 프로세스를 두 개의 서로 다른 계층에서 비교하세요:
| 계층 | 질문 |
|---|---|
| Content-Encoding | 클라이언트가 반환된 gzip/deflate/Brotli 바이트를 압축 해제할 수 있는가? |
| Charset | 압축 해제된 바이트는 어떻게 텍스트가 되는가? |
Requests는 보통 gzip/deflate를 처리합니다. Brotli는 설치된 지원 라이브러리가 필요합니다. 직접 복사한 Accept-Encoding는 이 환경이 디코딩할 수 없는데도 br를 알릴 수 있습니다. UTF-8 텍스트 선택은 Brotli를 압축 해제하지 않습니다.
협상을 의도적으로 제한할 때:
response = session.get(
url,
proxies={"https": "http://proxy.example:8080"},
headers={"Accept-Encoding": "gzip, deflate"},
timeout=30,
)
response.raise_for_status()기존 Session, HTTPS URL, 필요한 헤더/인증을 사용하세요. 두 머신에서 나가는 Accept-Encoding, 들어오는 Content-Encoding, 패키지 지원을 비교하세요. 변환하는 중간자가 오래된 메타데이터를 제공할 수도 있습니다. 별도의 공개 페이지 비교에서는 공개 중개자가 허용되는 곳에서 프록시 URL로 HTTP 프록시 목록를 사용할 수 있지만, 상속된 프록시 자격 증명, 복사한 계정 헤더, 비공개 본문 데이터는 사용하지 마세요.
그 밖에는 일반적인 클라이언트 협상을 선호하세요. Requests의 편리한 content/text 인터페이스는 지원되는 인코딩을 디코딩하므로, 헤더가 이름을 언급한다는 이유만으로 그 출력을 다시 압축 해제하지 마세요.