組み込みミドルウェアリファレンス

revision-up-to:11321 (1.1)

このドキュメントでは、 Django に付属している全ミドルウェアコンポーネントに ついて解説しています。ミドルウェアの使い方や自作のミドルウェアの書き方はm ミドルウェアの使い方ガイド を参照してくださ い。

利用できるミドルウェア

キャッシュミドルウェア

class django.middleware.cache.UpdateCacheMiddleware
class django.middleware.cache.FetchFromCacheMiddleware

サイト全体にわたるキャッシュを有効にします。キャッシュを有効にすると、 Django の管理下にあるページは CACHE_MIDDLEWARE_SECONDS 設定に定 義した時間のキャッシュされます。 キャッシュのドキュメント を参照してください。

コモンミドルウェア

class django.middleware.common.CommonMiddleware

リクエスト処理に完全主義者むけの便宜機能を追加するミドルウェアです:

  • DISALLOWED_USER_AGENTS に設定されたユーザエージェントから のアクセスを禁止します。 DISALLOWED_USER_AGENTS には文字列 のリストを指定します。

  • APPEND_SLASH および PREPEND_WWW に基づいて URL の書き換えを行います。

    APPEND_SLASH が True の場合、リクエストの URL の末尾が スラッシュで終わっておらず、 URLconf 上でもマッチしなければ、 スラッ シュを付加した URL を作成して、 URLconf でマッチするか確かめます。マッ チすれば、スラッシュつきの URL にリダイレクトします。そうでなければ、 URL を通常の手順に従って処理します。

    例えば、 foo.com/bar に一致するパターンがなく、 foo.com/bar/ に一致するパターンが あれば 、 foo.com/bar は foo.com/bar/ にリダイレクトされます。

    Django 1.0 で変更されました: 開発版では、 APPEND_SLASH の挙動が若干変更されました。 以前のバージョンでは、リクエストの URL が URLconf とマッチするか どうかに関係なくスラッシュを付加していました。

    PREPEND_WWW が True であれば、先頭に, “www.” のない URL は先頭に”www.” を付けた URL にリダイレクトします。

    それぞれのオプションは URL を正規化するためのものです。これは、 URL (Uniform Resorce Location) がただひとつの、真にただひとつの場所 (Location) を表すべきであるという哲学に基づいています。技術的には、 foo.com/bar は foo.com/bar/ とは別物です – 例えば、検索エン ジンはこの二つの URL を別々の URL として扱うかもしれません – ですか ら、 URL を正規化しておく方が得策なのです。

  • USE_ETAGS 設定に基づいて ETag を処理します。 USE_ETAGS を True に設定すると、 Django は各リクエスト ごとにページ内容の MD-5 ハッシュを計算して ETag にし、必要なら Not Modified 応答を返します。

ビューメタデータミドルウェア

class django.middleware.doc.XViewMiddleware

INTERNAL_IPS 設定に定義されている IP アドレスから来た HEAD リク エストに対してカスタムの X-View HTTP ヘッダを送信します。このミドルウェ アはDjango の自動ドキュメントシステムで使われています。

GZIP ミドルウェア

class django.middleware.gzip.GZipMiddleware

gzip 圧縮を受け付けるブラウザ (最近のほとんどのブラウザがそうです) 向けに、 コンテンツを圧縮して送ります。

このミドルウェアは、ミドルウェアリストの先頭に置くよう勧めます。なぜなら、 コンテンツの圧縮は最後に行うべきものだからです。このミドルウェアは、 200 バ イト未満のコンテンツを圧縮しません。また、状態コード 200 以外のレスポンス内 のコンテンツ、Javascript ファイル (IE との互換性のため)、 Content-Encoding が指定されているレスポンスも圧縮しません。

条件付き GET ミドルウェア

class django.middleware.http.ConditionalGetMiddleware

条件付き GET 操作を処理します。レスポンスに ETag または Last-Modified ヘッダがあり、リクエストに If-None-Match または If-Modified-Since がある場合、レスポンスを HttpNotModified に置き換えます。

また、 Date および Content-Length ヘッダを設定します。

リバースプロキシミドルウェア

class django.middleware.http.SetRemoteAddrFromForwardedFor

This middleware was removed in Django 1.1. See the release notes for details.

ロケールミドルウェア

class django.middleware.locale.LocaleMiddleware

リクエストに基づいて言語の選択を行います。言語の選択によって、ユーザごとに 提供するコンテンツをカスタマイズできます。 国際化のドキュメント を参照してください。

セッションミドルウェア

class django.contrib.sessions.middleware.SessionMiddleware

セッションのサポートを有効にします。 セッションのドキュメント も参照してください。

認証ミドルウェア

class django.contrib.auth.middleware.AuthenticationMiddleware

入力される HttpRequest オブジェクト全てに、現在ログインしているユーザを 表す user 属性を追加します。 Web リクエストの認証 を参照してください。

CSRF 対策ミドルウェア

class django.contrib.csrf.middleware.CsrfMiddleware
Django 1.0 で新たに登場しました: Please, see the release notes

POST フォームに隠しフォームフィールドを追加し、リクエストデータに正しい値が 設定されているかチェックすることによりクロスサイトリクエストフォージェリ (CSRF) を防ぎます。詳しくは クロスサイトリクエストフォージェリからの保護 を参 照してください。

トランザクションミドルウェア

class django.middleware.transaction.TransactionMiddleware

リクエスト／レスポンス処理フェイズに commit と rollback をバインドします。 あるビュー関数の実行に成功した場合に commit を、例外を送出して失敗した場合 には rollback を行わせます。

このミドルウェアでは、スタック中の順番が重要になります。このミドルウェアの 外で動作する他のミドルウェアモジュールは、Django のデフォルトの挙動、すなわ ち commit-on-save モードで動作します。このミドルウェアの内側にある (スタッ クの後ろに位置している) ミドルウェアは、ビュー関数と同じトランザクション制 御下に置かれます。

トランザクション管理のドキュメント を参照し てください。

« 前へ | 上へ | 次へ »