2017-08-21 13 views
3

Django 1.11に基づくかなり複雑なWebアプリケーションがあります。 しばらく前に、ユーザーは「他人の意見」を受け取っていると報告し始めました。memcachedは、デコレータ@cache_page(xx)によってキャッシュされたhtmlをキャッシュ猶予期間内のセッション間で区別せずに提供しました。DjangoがありませんVary:キャッシュされたビューのCookieヘッダー

さらなる調査の結果、あるケースではVary: Cookieヘッダーが見つからず、「セッション」が間違っていることが判明しました。奇妙なことに、バックエンドにcurl(セッションがなく、ユーザーなど - >バックエンドがキャッシュされたビューでログに記録されている)を照会したときだけを示しました。

残念ながら、この問題は実際には再現するのが難しく、時には発生しないこともあります。私は何か原因を確認できるかどうかを確認するために、単純なDjangoアプリケーションを最初から構築します。 @cache_pageが削除された場合、またはlogin_requiredが追加された場合に問題が発生しないことが確認されました。

ビューからすべての@cache_pageデコレータを削除してしまいました。問題はプロダクションでは発生していませんでしたが、回避策であり、原因を知りたいと思います。

誰かが何らかの原因が考えられる場合は、大変感謝しています。

答えて

1

おそらく、このopen bugに実行している:ビューのデコレータは、最初の発信応答で実行しているので言及した応答ミドルウェアのいずれかにチャンスがある前に、応答ミドルウェアの前に、cache_pageデコレータは応答をキャッシュ

Varyヘッダーを追加します。これは2つのことを意味します:1)使用されるキャッシュキーに応答が変わるべきヘッダーは含まれず、Djangoはそれを実際に取得すべきでないユーザーに応答することができます.2)ユーザーに配信された場合でも、それには含まれるべきであるVaryヘッダーが含まれないため、上流のHTTPキャッシュによって誤ってキャッシュされる可能性があります。言い換えれば

、一度応答がキャッシュされていることをSessionMiddlewareはまだので、すべてのセッションが同じキャッシュ・キーを共有する、Vary: Cookieヘッダーを設定する機会がありませんでした。

Varyヘッダーを明示的に指定することで回避できます。例:

from django.views.decorators.cache import cache_page 
from django.views.decorators.vary import vary_on_cookie 

@cache_page() 
@vary_on_cookie() 
def my_view(): 
    pass 
+0

これは可能性があります。洞察力ありがとうございます。 – Brachacz

関連する問題