5

IIS 7 では着信要求を別のアプリケーション プールに書き換えることができないというトピックが多数あります (そのような投稿の 1 つにhttps://serverfault.com/questions/220007/iis-7-5-multiple- application-pools-and-url-rewriting-403-18-forbidden )。リダイレクトは機能しますが、このプロジェクトの要件は、リダイレクトされた URL をユーザーが表示したり、検索エンジンがインデックスに登録したりできないようにすることです。

問題は、ローカル サーバーに、IIS が要求処理を開始する前に要求をインターセプトできるメカニズムが他にあるかどうかです。古い ISAPI フィルタが行っていたものと似ています。多くの記事では、何らかの形式の HTTP プロキシまたはソフトウェア ロード バランサーを使用することを提案しています。どちらのオプションも有効ですが、物理リソースと仮想リソースでオーバーヘッドが発生する可能性があります。要約すると、主な目標は、www.domain.com/(.*) からのリクエストを www.domain.com/{currentversion}/{R:1} に書き換えて、ルート Webサイトとバージョン管理された Web アプリケーションは互いに分離されています。

4

1 に答える 1

0

私はあなたを誤解しているかもしれません。しかし、本質的にリバースプロキシが必要ですか? 検索を回避するために URL を書き換える方法。クライアントは、サーバーから来たかのようにページ リソースを生成します。から利用できますIIS Rewrite Module。

ただし、完全に別個の 2 つのサイトを作成することもできます。例:

  • http://www.foo.com
  • http://www.foo.com/en
  • https://www.foo.com/en<-- に遷移するかのように入力しますhttps。

そう<sites>すれば、 が別々のディレクトリを指し、両方が別々のエンティティとして処理されるため、その 1 つのページでブロックされた応答を作成して、検索エンジン内で見つからないようにすることができます。

私の答えがオフの場合。私に知らせて、私はそれを削除します。しかし、それはうまくいくはずだと思います。とにかく理論上。また、Squid と Varnish は、リバース プロキシの作成に使用されるアプリケーションです。

于 2012-12-12T22:44:30.010 に答える