Werkzeug: チャンクされたリクエストはまだ実際には機能しません

これは、 minの単純なバグ以上のものです。 それを修正した後、問題は、読み取るmax_content_length未満の場合、Werkzeugブロックでwsgi.input.read(max_content_length)を永久に実行することです。 または、メッセージ全体を解析してバッファリングすることでチャンクをサポートするGunicornを使用すると、長さがmax_content_length未満になるため、 LimitedStreamはクライアントが切断されたと見なします。

私はこれをDjangoでテストして、何か変なことをしていないことを確認しました。空のストリームも表示されます。

最も簡単な方法は、 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ヘッダーフィールドは送信してはならない[MUSTNOT]
これらの2つの長さが異なる場合（つまり、Transfer-Encodingの場合）
ヘッダーフィールドが存在します）。 メッセージが両方で受信された場合
Transfer-EncodingヘッダーフィールドとContent-Lengthヘッダーフィールド、
後者は無視しなければなりません。

... chunked Transfer-Encodingは、 Content-Lengthヘッダーを無視することを要求しているため、それに基づいてストリーム処理を実行しないでください。 wsgi.input_terminatedが設定されていない限り、これは現在のところ当てはまります。

10バイトのJSONペイロードなどの通常のチャンクエンコーディングを機能させるには、本当にwsgi.input_terminatedを設定する必要がありますか？