32

公式ドキュメントは少し面倒です。「before」と「after」はミドルウェアをタプルで注文するために使用されますが、「before」と「after」が要求/応答フェーズを指す場合もあります。また、「最初/最後である必要があります」が混在しており、どちらを「最初」として使用するかが明確ではありません。

私は違いを理解しています..しかし、Djangoの初心者にとっては複雑なようです。

組み込みのミドルウェアクラスの正しい順序を提案できますか（すべてを有効にすると仮定します）、そして最も重要なこととして、あるクラスが他のクラスの前後にある理由を説明できますか？

これが私が見つけたドキュメントからの情報を含むリストです：

  1. UpdateCacheMiddleware
    • 'Vary：'を変更するものの前SessionMiddlewareにGZipMiddleware、、LocaleMiddleware
  2. GZipMiddleware
    • 応答本体を変更または使用する可能性のあるMWの前
    • 変更後UpdateCacheMiddleware：「変更：」を変更
  3. ConditionalGetMiddleware
    • Before CommonMiddleware：は、次の場合に「Etag：」ヘッダーを使用しますUSE_ETAGS=True
  4. SessionMiddleware
    • 変更後UpdateCacheMiddleware：「変更：」を変更
    • 以前TransactionMiddleware：ここではトランザクションは必要ありません
  5. LocaleMiddleware、SessionMiddleware、CacheMiddlewareの後の最上位の1つ
    • 変更後UpdateCacheMiddleware：「変更：」を変更
    • 変更後SessionMiddleware：セッションデータを使用
  6. CommonMiddleware
    • 応答を変更する可能性のあるMWの前（ETagを計算します）
    • その後GZipMiddleware、gzip圧縮されたコンテンツのEタグは計算されません
    • 上部に近い：APPEND_SLASHまたはPREPEND_WWW
  7. CsrfViewMiddleware
    • CSRF攻撃が処理されたと想定するビューミドルウェアの前
  8. AuthenticationMiddleware
    • 後SessionMiddleware：セッションストレージを使用
  9. MessageMiddleware
    • 後SessionMiddleware：セッションベースのストレージを使用できます
  10. XViewMiddleware
  11. TransactionMiddleware
    • DBを使用するMWの後: SessionMiddleware(DBを使用するように構成可能）
    • すべて*CacheMiddleWareが影響を受けることはありません（例外として：独自のDBカーソルを使用します）
  12. FetchFromCacheMiddleware
    • 'Vary：'を変更するものの後、それらを使用してキャッシュハッシュキーの値を選択する場合
    • その後AuthenticationMiddleware、使用することが可能ですCACHE_MIDDLEWARE_ANONYMOUS_ONLY
  13. FlatpageFallbackMiddleware
    • 下：最後の手段
    • ただし、DBを使用することは問題ではありませんTransactionMiddleware （はい？）
  14. RedirectFallbackMiddleware
    • 下：最後の手段
    • ただし、DBを使用することは問題ではありませんTransactionMiddleware （はい？）

（このリストに提案を追加して、すべてを1か所に集めます）

4

2 に答える 2

4

最も難しいのは、順序を設定するときに両方の方向を同時に考慮する必要があることです。これは設計上の欠陥であり、私は個人的に別requestのミドルウェアの注文を選択します（したがって、やresponseのようなハックは必要ありません）。FetchFromCacheMiddlewareUpdateCacheMiddleware

しかし...残念ながら、今はこのようになっています。

process_requestいずれにせよ、すべての考え方は、リクエストがとのトップダウン順にミドルウェアのリストを通過することですprocess_view。process_responseそして、それはあなたの応答をprocess_exception逆の順序で通過させます。

これは、HTTPリクエストUpdateCacheMiddlewareのヘッダーを変更するミドルウェアがその前に来る必要があることを意味します。Varyここで順序を変更すると、一部のユーザーが他のユーザーのキャッシュページを取得できるようになります。

Varyヘッダーがミドルウェアによって変更されているかどうかをどのように確認できますか？利用可能なドキュメントがあることを期待するか、単にソースを見ることができます。それは通常非常に明白です:)

于 2011-01-08T04:42:41.463 に答える
2

髪の毛を節約できるヒントの1つは、TransactionMiddlewareをリストのそのような場所に配置することです。この場合、他のミドルウェアによってデータベースにコミットされた変更をロールバックできません。ビューで例外が発生したかどうかに関係なく、変更はコミットする必要があります。 。

于 2011-03-10T20:21:27.520 に答える