キャッシュミドルウェア¶

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¶

request.META['HTTP_X_FORWARDED_FOR'] が設定されていた場合、その値に基づ いて request.META['REMOTE_ADDR'] をセットします。サーバがリバースプロキ シの向こうにあるためにリクエストの REMOTE_ADDR が 127.0.0.1 にセッ トされてしまう場合に便利です。

注意事項: このミドルウェアは HTTP_X_FORWARDED_FOR を検証 しません HTTP_X_FORWARDED_FOR を自動的に設定するリバースプロキシ を経由していない場合には、このミドルウェアを使ってはなりません。なぜなら、 HTTP_X_FORWARDED_FOR の値はだれでも簡単に偽装できるので、このミドルウェ アが REMOTE_ADDR に基づいて HTTP_X_FORWARDED_FOR を設定すると、誰も が “偽の” IP アドレスを名乗れてしまうからです。このミドルウェアを使ってよい のは、 HTTP_X_FORWARDED_FOR の値を完全に信用できる場合だけです。

ロケールミドルウェア¶

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¶

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

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

class django.middleware.transaction.TransactionMiddleware¶

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

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

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