12

の形式の URL がありますhttp://domain/image/⟨uuid⟩/42x42/some_name.png。Web サーバー (nginx) はファイルを探すように構成されており、ファイル/some/path/image/⟨uuid⟩/thumbnail_42x42.pngが存在しない場合は URL をバックエンド (mod_wsgi 経由の Django) に送信し、バックエンドはサムネイルを生成します。次に、バックエンドは、クライアントが要求したのとまったく同じ URL に 302 リダイレクトを送信します。この 2 番目の要求で、サーバーがサムネイル ファイルに気づき、それを直接送信するという考えに基づいています。

問題は、これがすべてのブラウザーで機能するかどうかです。これまでのテストでは問題は示されていませんが、すべてのユーザー エージェントがこれを意図したとおりに解釈すると確信できますか?

更新:意図を明確にさせてください。現在、これは次のように機能します。

  1. クライアントは画像のサムネイルを要求します。
  2. サーバーはファイルが存在しないことを認識し、リクエストをバックエンドに転送します。
  3. バックエンドはサムネイルを作成し、302 を返します。
  4. バックエンドはすべてのリソースを解放し、サーバーが新しく生成されたファイルを現在および後続のクライアントと共有できるようにします。

バックエンドに新しく作成されたイメージを提供させることは、次の 2 つの理由で悪化します。

  1. 同じデータを提供する 2 つの方法を作成する必要があります。
  2. サーバーは、静的コンテンツの提供においてはるかに優れています。クライアントのリンクが非常に遅い場合はどうなりますか? バックエンドは特に高速でもなく、メモリ効率も高くないため、クライアントにスプーン フィードしている間、バックエンドをメモリに保持するのは無駄になる可能性があります。

そのため、バックエンドを最小限の時間だけ動作させます。

Update²:いくつかの RFC リファレンスや、多くのブラウザーを使用した経験のある人の意見をいただければ幸いです。これらの肯定的な答えはすべて心地よいものですが、根拠がないように見えます。

4

2 に答える 2

3

そうでない場合、クライアントは壊れています。ほとんどのクライアントは、最大値までリダイレクト ループに従います。そうです、何らかの理由でバックエンドがサムネイルを生成しなくなるまでは問題ありません。

代わりに URL をhttp://domain/djangoapp/generate_thumbnailに変更すると、サムネイルと適切なコンテンツ タイプなどが返されます。

于 2008-09-24T10:14:01.340 に答える
0

はい、以前と同じ URI にリダイレクトしても問題ありません。

于 2008-09-24T11:00:45.037 に答える