私はDjangoバージョン1.3アルファ1（SVN-14750）を使ってDjangoサイトを構築しています。Django 1.3 alpha 1では、組み込みWebサーバーのキャッシュページ（またはデータベース結果）がこれまで以上に積極的にキャッシュされますか？
私はデータを表示し、そのデータを編集できるページをいくつか持っています。しかし、私は、更新されたデータを見るために、組み込みのDjango Webサーバーを再起動する必要があるようです。
私は前にこの問題を抱えて覚えていない：通常のブラウザでCTRL +F5リフレッシュがそれを行うだろう。明らかに、開発中の動作は非常に厄介なものです。最新のデータ読み込み速度が遅いのが陳腐化したデータ読み込みを直ちに見るのが望ましいです。
私はキャッシュを無効にしてFirefoxを使用しています（about：config、network.http.use-cache=False）。問題はDjangoであると確信しています。
Ah - 私はまだいくつかのキャッシュミドルウェアを有効にしていました。 settings.pyのMIDDLEWARE_CLASSES設定から次のものを削除しました。
'django.middleware.cache.UpdateCacheMiddleware',
'django.middleware.cache.FetchFromCacheMiddleware',
（質問およびこの回答から、おそらく明らかなように、私は非常によく、それ以外の場合は、キャッシング、Djangoのかを理解していない。）
Webサーバー自体は、キャッシングを行いません。 （サーバー側の）キャッシュの仕組みを決めるのはアプリケーション自体に任されています。 Djangoの場合、キャッシュを有効にするためのいくつかのオプションがあります。
しかし、DjangoはURLのリクエストを見て、応答してhtml文字列を生成し、その文字列をメモリ（または設定したキャッシュバックエンドに応じてデータベース）に格納します。次回同じURLに対してリクエストが来ると、Djangoはその応答がキャッシュに存在するかどうかをチェックし、そうであればその文字列を返します。そうでない場合は、プロセスが繰り返されます。
@vary_onデコレータの背後にあるアイデアは、キャッシュ内のレスポンスを見つけるためのルックアップキーを変更することです。 vary_on（user、url）の場合アルゴリズムは次のようになります。
1. request /users/3/Josh
2. key = str(user) + str(url)
3. response = get_from_cache(key)
4. if response is None: response = view_function()
5. save_to_cache(key, response)
6. return response
Webサーバーには、このタイプのキャッシュへの入力がありません。
他のタイプのキャッシュはクライアント側です。これは、静的コンテンツ（javascript、画像など）のような特定のタイプのリソースに対して特定のヘッダーを返すようにWebサーバーが構成されている場所です。ブラウザは、これらのヘッダーを分析し、コンテンツを要求するか、またはコンテンツを格納したクライアント側を使用するかを決定できます。これは、一般的に動的コンテンツには適用されません。