リクエストデータの処理—Werkzeugドキュメント
リクエストデータの処理
Web開発に関する最も重要なルールは、「ユーザーを信頼しない」です。 これは、入力ストリームの着信要求データに特に当てはまります。 WSGIを使用すると、これは実際には予想よりも少し難しくなります。 そのため、Werkzeugはリクエストストリームをラップして、最も顕著な問題からあなたを救います。
入力ストリームにEOFマーカーがありません
入力ストリームにはファイルの終わりマーカーがありません。 wsgi.input ストリームでread()
メソッドを呼び出すと、準拠しているサーバーでアプリケーションがハングします。 これは実際には意図的ですが、苦痛です。 Werkzeugは、入力ストリームを特別なLimitedStream
でラップすることにより、この問題を解決します。 入力ストリームは、stream
としてリクエストオブジェクトに公開されます。 これは、空のストリーム(フォームデータが解析された場合)または入力ストリームの内容を含む制限されたストリームのいずれかです。
Werkzeug Parseはいつですか?
Werkzeugは、次の状況で受信データを解析します。
form
、files
、またはstream
のいずれかにアクセスし、要求方法は POST または PUT でした。parse_form_data()
を呼び出す場合。
これらの呼び出しは互換性がありません。 parse_form_data()
を呼び出す場合は、リクエストオブジェクトを使用しないでください。少なくとも、解析プロセスをトリガーする属性を使用しないでください。
これは、解析の前に wsgi.input ストリームから読み取る場合にも当てはまります。
一般的なルール: WSGI入力ストリームはそのままにしておきます。 特にWSGIミドルウェアで。 解析関数またはリクエストオブジェクトのいずれかを使用します。 フォームデータの解析や入力ストリームで機能するその他のもののために、複数のWSGIユーティリティライブラリを混在させないでください。
どのように解析しますか?
標準のWerkzeug解析動作は、次の3つのケースを処理します。
- 入力コンテンツタイプは multipart / form-data でした。 この状況では、
stream
は空になり、form
には通常の POST / PUT データが含まれ、files
にはFileStorage
オブジェクトとしてアップロードされたファイル。 - 入力コンテンツタイプは application / x-www-form-urlencoded でした。 次に、
stream
は空になり、form
には通常の POST / PUT データが含まれ、files
は空になります。 - 入力コンテンツタイプはどちらでもありませんでした。
stream
は、さらに処理するための入力データを含むLimitedStream
を指します。
get_data
メソッドに関する特記事項:これを呼び出すと、完全な要求データがメモリにロードされます。 これは、max_content_length
が設定されている場合にのみ安全です。 また、ストリームを読み取るまたはget_data()
を呼び出すこともできます。
リクエストデータの制限
DDOS攻撃の被害を回避するために、受け入れられるコンテンツの最大長とリクエストフィールドサイズを設定できます。 Request
クラスには、max_content_length
とmax_form_memory_size
の2つの属性があります。
最初のものは、コンテンツの合計の長さを制限するために使用できます。 たとえば、1024 * 1024 * 16
に設定すると、リクエストは16MBを超える送信データを受け入れません。
特定のデータ(通常の投稿データ)はハードディスクに移動できませんが、一時ファイルは移動できるため、設定できる2番目の制限があります。 max_form_memory_size
は、 POST で送信されるフォームデータのサイズを制限します。 1024 * 1024 * 2
に設定することで、メモリに保存されているすべてのフィールドのサイズが2MB以下であることを確認できます。
ただし、使用される stream_factory がメモリ内ファイルを返す場合、これははメモリ内に保存されたファイルに影響しません。
解析を拡張する方法は?
最新のWebアプリケーションは、マルチパートフォームデータやURLエンコードされたデータよりもはるかに多くのものを送信します。 機能を拡張するには、Request
またはRequest
をサブクラス化し、メソッドを追加または拡張します。