ASPサイトからASP.Netへの変換に取り組んでおり、リダイレクトとリソースの場所で問題が発生しています。私たちの問題は、私たちのセットアップの特殊性から来ています。私たちのサイトには2つの方法でアクセスできます。
- URLから直接：http ：//www.mysite.com-この場合、すべてが正常に機能します
- 次のようなURLのプロキシサーバー経由：http： //www.proxy.com/mysite_proxy/proxy/
＃2では、「mysite_proxy」は、リクエストを舞台裏でwww.mysite.comに転送するproxy.comのマッピングであり、「proxy」は、リクエストをwww.mysite.comのルートにリダイレクトするだけの仮想サブWebサイトです。 。これは基本的に、リクエストがプロキシからサイトにヒットしているかどうかを知るための便利な方法を提供することを目的としています。
この設定で2つの問題が発生しています。
- 「〜」またはプレーン相対パス（Default.aspx）のいずれかでResponse.Redirectを使用すると、「/ proxy/rest_of_the_path.aspx」の場所で302応答が生成されます。これにより、ブラウザはhttp://www.proxy.com/proxy/rest_of_the_path.aspxを要求しますが、これは何も存在せず、サーバーにもヒットしないため、事後の書き換えはできませんでした。
- リンク、画像、スタイルシートなどのページで「〜」ベースのURLを使用すると、同じ種類のパス「/proxy/path_to_resources.css」が作成されます。これらすべてのリソースに相対パスを使用することで、おそらくこれらのいくつかを解決できますが、それは多くの作業であり、フレームワークとサードパーティコンポーネントによって生成された同様のリソースリンクに対処することはできません。
理想的には、これらの問題をサイトで作業している開発者に透過的にするグローバルな修正を見つけたいと思います。この時点でいくつかのアイデアがあります。
- プロキシを取り除くことは、実際には必要ではなく、管理上の理由であり、技術的な理由ではありません。技術的に達成するのが最も簡単で、現実の世界で達成するのが最も難しい。
- プロキシを実行しているグループに問題を渡し、それを修正する必要があるのは彼らの問題であると言います。
- 応答フィルターを使用して、生のhtmlをクライアントに送信する前に変更します。これでリソースリンクが修正される可能性があることはわかっていますが、ヘッダーについては確信が持てず（テストする必要があります）、すべての応答を解析してURLを探して書き直す必要があるとパフォーマンスが低下します。
これらの解決策はすべて私の心に大きなマイナス面があり、誰かが別のアイデアを持っているかもしれないと思っていました。それで、何か考えはありますか？
余談ですが、この問題の逆を扱った投稿はすでにたくさんあります。相対URLがありますが、どうすれば絶対にできますか。しかし、他の方向の法案に適合するものは見つかりませんでした。