gzip 바이트를 설명하는 헤더와 함께 전달하세요

Requests가 이미 본문을 압축 해제했다면 Content-Encoding: gzip와 함께 전달하면 다음 클라이언트가 다시 압축을 해제하도록 요청하는 셈입니다. 헤더를 복사하기 전에 프록시가 어떤 페이로드 표현을 보낼지 결정하세요.

인코딩된 페이로드 바이트의 경우 이 조각은 content 디코딩 없이 urllib3의 원시 스트림을 읽습니다:

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는 기존 응답 출력입니다. 상태와 헤더는 이미 선택한 정책을 따라야 합니다. 이 조각은 완전한 프록시 서버를 구현하지 않습니다.

전송 프레이밍은 gzip content 인코딩과 별개입니다. 업스트림 HTTP 라이브러리가 청크 제거를 포함한 프레이밍을 이미 처리했으므로 Transfer-Encoding를 무작정 복사하지 마세요. 다운스트림 서버는 페이로드가 gzip으로 인코딩된 상태로 남아 있어도 자체 응답을 프레이밍합니다.

response.text 뒤에 UTF-8 인코딩을 적용하는 것도 표현을 바꾸며 임의의 이진 데이터를 보존할 수 없습니다. 모든 경로에서 업스트림 응답을 닫거나 소비하고, 프록시 계약에 따라 HTTP 오류를 처리하세요. 이 예제는 전달하는 대신 예외를 발생시킵니다.