2

フロントエンド プロキシとして nginx を使用したいのですが、応答の MIME タイプ (Content-Type ヘッダー) に応じて、条件付きで別の URL にプロキシします。

たとえば、クライアントの 1% が PNG を処理しない User-Agent を使用しているとします。その UA で、応答のタイプが image/png の場合、PNG を取得して変換する特別な URL に再度 proxy_pass したいと考えています。

理想的には、この特別な処理を必要としない 99% のユーザーのパフォーマンスとキャッシュを損なわずにこれを行います。バックエンド アプリケーションを変更できません。(それ以外の場合は、UA を検出して応答を修正するか、X-Accel-Redirect を送信して nginx に別のロケーション ブロックを実行させることができます。)

これが不可能であるか、パフォーマンスが悪い場合、目的の効果を達成するためにモジュールの作成をどこから開始しますか? たとえば、このロジックの実装に最も近いのはどの拡張ポイントですか?

編集: Lua を使用してサブリクエストを実行し、そこで応答ヘッダーを検査できるようです。しかし、それはすべてのリクエストをLuaを介して渡すことを意味しますが、これは最適ではないようです

4

2 に答える 2

1

あなたがやりたいことをする正当な理由があると確信していますが、実際のimage/png例は見た目ほど単純ではありません。ブラウザは、png が新しい時代に使用されていたようimage/pngに、 HTTP 要求ヘッダーに含まれなくなったため、非常に古いブラウザの検出テーブルとマッピング テーブル全体を用意する必要があります。Accept

さらに、アーキテクチャの観点からは、何を達成しようとしているのかが明確ではありません。

  • これが静的データである場合、静的データを nginx から直接提供するのではなく、そもそもバックエンドにプロキシするのはなぜですか? \.png$正規表現は、影響を受けるリクエスト URI と一致しませんか? バックエンドを使わずに、または最初に間違ったリクエストをバックエンドに送信せずにリクエストを書き直すことで、これを解決できませんでしたか?

  • これが本当に動的である場合、アプリの動作に関する知識に基づいて特別なケースのマッピング テーブルを用意し、バイパスする代わりに、受け入れられないタイプの応答を受信するためだけにリクエストを作成する時間を無駄にする必要があるのはなぜですか。後で破棄するのではなく、最初から不要なリクエストを削除しますか?

  • アプリが本当にブラック ボックスであり、どのアプリでも機能する汎用ソリューションが必要な場合でも、ユースケースが何であるか、なぜ余分なリクエストを行う必要があるのか​​ が不明であり、破棄するだけです。

image/png の例のように、トラフィックの 1% だけを本当に混乱させたい場合は、影響を受ける古いブラウザーの 1% からのすべての要求を別のバックエンドにリダイレクトすることが理にかなっている可能性があります。必要なことを行うためのロジック。

率直に言って、本当に古いブラウザーをターゲットにしたいのであれば、png のサポートは最後の心配事であると思います。多くの Web アプリケーションには、非常に複雑で特殊な目的の JavaScript が含まれており、png をサポートしていない古い Web ブラウザーはもちろん、新しい User-Agent 文字列を備えた新しい代替ブラウザーでも機能しません。

于 2014-03-05T14:51:31.923 に答える
0

http://wiki.nginx.org/HttpCoreModule#.24http_HEADERによると 。if ($content_type ~ 'whatever your content type') { proxy_pass 'ur_url' } の行に沿って何かを持つことができると思います

それはあなたのために働くものでしょうか？

于 2014-03-05T19:56:13.987 に答える