Werkzeug: 청크 요청은 여전히 ​​작동하지 않습니다.

이것은 min 의 단순한 버그 이상입니다. 그것을 고친 후, 문제는 읽을 것이 max_content_length 미만이면 Werkzeug 블록으로 wsgi.input.read(max_content_length) 를 영원히 수행한다는 것입니다. 또는 전체 메시지를 구문 분석하고 버퍼링하여 청크를 지원하는 Gunicorn을 사용하면 길이가 max_content_length 미만으로 나오므로 LimitedStream 는 클라이언트가 연결이 끊어진 것으로 간주합니다.

나는 장고에서 우리가 이상한 일을하지 않는지 확인하기 위해 이것을 테스트했습니다. 빈 스트림도 보입니다.

가장 간단한 방법은 environ['wsgi.input_terminated'] 를 설정하는 미들웨어를 제공하고 청크 전송을 지원하는 서버를 사용할 때 사람들에게이를 사용하도록 지시하는 것입니다.

현재 input_terminated 지원하는 wsgi는 무엇입니까? 데이터가 비어있는 이유를 디버깅하는 데 하루 종일 레코딩 한 후 스트림이 비어있는 이유는 청크 스트림 인코딩으로 인한 것임을 깨달은 후 이제 이것을 지원하는 것을 찾을 수 없습니다.

environ.get('wsgi.input_terminated') 를 확인하는 것 외에도 environ.get('HTTP_TRANSFER_ENCODING') == 'chunked' 도 확인해야 하며 이 경우 래핑되지 않은 스트림도 직접 반환해야 합니까? 빈 스트림을 반환하는 간단한 curl -H 'Transfer-Encoding: chunked' ... 와 같은 문제를 해결합니다.

RFC2616에 따라

4.4.2
Transfer-Encoding 헤더 필드 (섹션 14.41)가 있고
"identity"이외의 값이있는 경우 전송 길이는
"청크" 전송 코딩(섹션 3.6)을 사용하여 정의됩니다.
연결을 닫아 메시지가 종료되지 않는 한.

4.4.3
Content-Length 헤더 필드(섹션 14.13)가 있는 경우 해당
OCTET의 10진수 값은 엔티티 길이와
전송 길이. Content-Length 헤더 필드는 전송되어서는 안 됩니다(MUST NOT).
이 두 길이가 다른 경우(즉, Transfer-Encoding
헤더 필드가 있음). 두 가지 모두로 메시지가 수신되는 경우
Transfer-Encoding 헤더 필드 및 Content-Length 헤더 필드,
후자는 무시되어야 합니다.

... Transfer-Encoding 의 chunked Content-Length 헤더를 무시하도록 요구하므로이를 기반으로 스트림 처리를 수행해서는 안됩니다. 현재 wsgi.input_terminated 가 설정되어 있지 않은 경우입니다.

10 바이트 JSON 페이로드와 같은 정상적인 청크 인코딩이 작동하려면 wsgi.input_terminated 를 설정해야합니까?