Requests: 스트리밍 gzip 응답

아니요, 다양한 이유로 기본적으로 설정해서는 안 됩니다. 당신이 해야 할 일은 functools.partial 를 사용하여 응답에서 read 메소드를 바꾸는 것입니다.

response.raw.read = functools.partial(response.raw.read, decode_content=True)

그런 다음 response.raw 를 파서에 전달합니다.

@sigmavirus24 감사합니다. 위에서 설명한 문제에 대한 확실한 해결책입니다!

요청 문서(예: FAQ: http://docs.python-requests.org/en/latest/community/faq/#encoded -data)에 추가하는 것이 좋습니다.
현재 "Requests automatically decompresses gzip-encoded response"라는 문구는 stream=True 경우에 올바르지 않으며 놀라움으로 이어질 수 있습니다.

내 문제에 관해서는 urllib3 문제 에서 읽었듯이 gzip 압축 해제의 urllib3 구현에는 내 코드에서 해결해야 하는 자체 작은 단점이 있지만 더 이상 요청에 대한 문제는 아닙니다.

그러나 더 이상 요청에 문제가 되지 않습니다.

이것이 닫힐 수 있다고 느끼십니까?

@sigmavirus24 현재 문서가 올바르지

그러나 그것에 동의하지 않는다면 예, 닫으십시오!

문서가 더 명확할 수 있습니다. 나에게 (그리고 이것은 전적으로 내가 핵심 개발자이기 때문에) 첫 번째 단락은 원시 응답을 절대 건드리지 않을 사용자의 90%에게 말하는 반면, 두 번째 단락은 "하지만 액세스해야 하는 경우 원시 데이터가 있습니다." 내가 말했듯이, 그것은 나에게 분명하지만 그것이 어떻게 더 명확해질 수 있는지 알 수 있습니다. 오늘 밤에 작업하겠습니다.

저에게는 "원시 데이터"를 "원시 페이로드", 즉 압축 해제된 스트림으로 해석했을 것입니다. 필요한 부분만 읽으면 됩니다. 압축 해제된 blob인 .content 와 대조적으로(페이로드도 있지만 다른 형식임).

실제 압축 해제는 나에게 HTTP 라이브러리의 관심사처럼 느껴집니다. 요청이 추상화될 것으로 예상되는 HTTP 구현 세부 정보입니다. 요청에서 페이로드를 스트림으로 읽든 미리 가져온 데이터 덩어리로 읽든 차이가 없습니다. 어느 쪽이든 요청은 구현 세부 정보 '압축'을 추상화합니다.

(이 가정은 decode_content 를 True 로 기본 설정하라는 내 원래 요청의 핵심이기도 했습니다. 물론 이것이 누출된 추상화를 보았으므로 더 이상 제안하지 않습니다.)

하지만 네, 사용자의 99%가 이 세부 사항의 영향을 받지 않을 것이라는 데 절대적으로 동의합니다.

이 문제를 닫으십시오.

그래서 이것은 실제로 한동안 내 머리 속에서 떠들썩하게 맴돌았지만 중요한 API 변경이 될 것이기 때문에 아직 제안하지 않은 것으로 이어집니다.

r.raw 는 문서화하지 않은 객체이고 urllib3 제공한 객체이기 때문에 사람들에게 r.raw 사용하도록 제안한다는 사실이 마음에 들지 않습니다. 구현 세부 사항). 이를 염두에 두고 urllib3 메서드에 프록시하는 Response 개체에 메서드를 제공하는 아이디어를 가지고 놀았습니다( read 는 raw.read 등). 이것은 주위에 우리에게 추가적인 유연성을 제공 urllib3 와 (사용자를 대신하여) 핸들의 API 변경 우리를 수 urllib3 그래서 어떤이없는, 역사적으로 거의 문제가되지 않았어요 ( 긴급).

그렇긴 하지만 내 생각에는 Response 개체에 대한 메서드가 이미 충분하고 API를 늘리는 것은 이상적이지 않습니다. 최고의 API는 제거할 것이 없는 API입니다. 그래서 나는 이것에 대해 계속 경계하고 있습니다.

이 가정은 또한 기본 decode_content를 True로 설정하라는 내 원래 요청의 핵심이었습니다. 물론 이것이 누출된 추상화를 보았으므로 더 이상 제안하지 않습니다.

이것을 발견하고 이것이 왜 사실인지 확실하지 않은 다른 사람들을 위해 설명하겠습니다.

응답 길이를 확인하거나 응답으로 다른 중요한 작업을 수행하기 위해 자동 압축 해제를 끄는 요청 사용자가 여러 명 있습니다. 전자의 소비자 중 하나는 OpenStack입니다. 많은 OpenStack 클라이언트는 클라이언트로 전송된 Content-Length 헤더와 수신된 본문의 실제 길이를 검증합니다. 그들에게 감압 처리는 유효한 응답을 수신하고 처리하고 있는지 확인하기 위한 공정한 절충안입니다.

또 다른 소비자는 Betamax(또는 실제로 Response 개체를 (재)구성하는 모든 도구)입니다. 완전히 유효한 응답을 만드는 전체 프로세스를 처리할 때 콘텐츠가 압축된 형식이어야 하기 때문입니다.

@Lukasa 나 내가 알지 못하는 다른 사람들도 이 동작에 크게 의존한다고 확신합니다.

오늘 같은 문제를 겪었고 현재로서는 응답을 스트리밍할 수 있는 다른 방법이 없기 때문에 같은 가정을 하게 되었습니다.

오히려 응답에서 여러 새로운 방법보다 왜 안 하나의 새로운 속성 예를 들어 response.stream 에 프록시의 같은 역할 연주 것이다 .raw ? 또한 stream=True 설정/매개변수를 훌륭하게 미러링하고 현재 .raw 동작이 필요한 사용자에게 영향을 주지 않습니다.

나는 과거에 이것을 했다

r = requests.get('url', stream=True)
r.raw.decode_content = True
...

@sigmavirus24에 의한 해결 방법 은 잘못된 오프셋을 반환하는 tell 메서드의 의미 체계를 깨뜨 립니다.

tell() 를 사용하여 방금 읽은 바이트 수를 파악하는 Google Cloud Storage API에 재개 가능한 업로드로 응답을 스트리밍할 때 이 문제가 발생했습니다( 여기 ).