asp.net は URL 書き換え URLReWriter を使用して第 2 レベルのドメイン名を実装します

長い間技術的な記事を書いていないので、理解できない場合は、もう少し記事を読むか、記事の最後に返信してください (これが最も効果的な方法です)。あなたの疑問に答えるために、

私はこの記事を見つけるためにここに来ました。皆さんは第 2 レベルのドメイン名が何であるかを知っているはずです。だから、私はナンセンスな話はしません。しかし、議論する前に、まずイデオロギー的な問題を理解する必要があります。
多くの友人が理解できなかった問題 (私も数日前には理解できませんでした) は、アドレスを入力した後、なぜ URL が書き換えられるのかということです。
ステップ 1: http://blog.downcodes.comなどのアドレスをブラウザに入力し、「Enter」をクリックします。
問題を単純化するために、次のように説明します。
ステップ 2: まず、入力されたアドレスが解析され、最終的に処理のために IIS に渡されます。最後に、IIS はそのようなリクエストを処理するために Web プロセッサに渡します。 Web プロセッサは処理結果をブラウザに返し、ユーザーに表示します。
この問題を無視しないでください。これらの処理が実行されると、Web プロセッサが終了時に処理結果を返しても、クライアントのブラウザ上のアドレスは変わりません。 、上記のアドレスは変更されません。
最初に入力した URL はドアをノックする役割を果たすだけで、ブラウザやサーバーなどはこのアドレスを認識することはできません。
理解する必要がある問題は、いわゆる URL 書き換えは Web 開発者だけが知っている内部の話であり、ユーザーは自分が入力したアドレスが表示されるべき結果であると考えているということです。言い換えれば、私たちは舞台裏で何が表示されるかを制御します。
次に考慮すべきことは、表示されるコンテンツをどのように制御するかということです。
上記のプロセスから、Web プロセッサの動作を操作する必要があることは明らかです。

最も単純な考慮事項の 1 つは、ユーザーがパラメーターなしで単純なアドレスhttp://blog.downcodes.comを入力し、次に We を入力することです

このアドレスを、プログラムのニーズを満たすパラメータを備えたアドレスhttp://kerry.com?lover=notusに変更し、最終的に処理します。
いわゆる URL の書き換えがこの段階で行われます。
.net 用語では、アプリケーションが特定の URL を処理できるように httpmodule を登録する必要があります。
web.configにhttpmoduleを登録し、

、当社が提供する httpmodule プログラムの

このプログラムとほぼ同等です

// httpmodule プログラムを使用して元の URL をインターセプトします
文字列 OriginalUrl=” http://blog.downcodes.com ”;
//元の URL を処理し、最後に必要な URL を取得します。値はhttp://kerry.com?lover=notusです。
文字列 FinalUrl=Rewrite(OriginalUrl);
// コンテキストは、処理のために内部的に URL を IIS に再送信します。
context.RewritePath(FinalUrl);

次に、URL の書き換えを実装します。
ステップ 1: どの URL を書き換える必要があるかを決定する、つまり書き換えルールを作成する ステップ 2: httpmodule ハンドラーを作成する ステップ 3: 作成した httpmodule を Web プログラムに統合して作業を開始する

以上が URL 書き換えの基本知識です。 . 、URL 書き換えを使用して第 2 レベルのドメイン名を実装する場合、第 2 レベルのドメイン名であっても第 3 レベルのドメイン名であっても、インターセプトする限り、プロセスは同じです。この URL アドレスを処理中に操作することはできます。

//www.microsoft.com/ の

記事を参照してください。

china/msdn/library/webservices/asp.net/URLRewriting.mspx

http://www.cnblogs.com/jzywh/archive/2005/09/29/246650.html

http://www.cnblogs.com/jzywh/ archive/2006/02/20/334004.html

この記事は終了です

実装プロセスではいくつかの問題が発生しますが、そのほとんどは上記の記事をよく読んでいないことが原因ですが、正直に言って、そのような記事を読むのは簡単ではありません。長い記事になりますので、いくつかの重要な質問を以下に記録します。最後の 2 つの質問は、要件を満たすように書き換えられたターゲット URL を処理する方法を示します。

Microsoft の URLRewriter とは何ですか? このプロジェクトはどこでダウンロードできますか?
これは URLRewriter を紹介する msdn の記事で提供されているサンプル プログラムです。ここからダウンロードできます。
http://www.microsoft.com/china/msdn/library/webservices/asp.net/URLRewriting.mspx

これらのコードの使い方は面倒ですか？
確かに、それは面倒なことではありません。
コードをマシンにダウンロードします。
インストール後、URLRewriter プロジェクトを自分のプロジェクトに追加し、上記のアドレスの方法に従い、コード構成 web.config を変更して、使用を開始します。

httpmodule とは何ですか?

簡単に理解すると、http リクエストを処理するプログラムです。詳しくは、SDK ドキュメントを参照してください。

汎解決を実装するにはどうすればよいですか?

まず、サーバー IP を指す *.kerry.com という第 2 レベルのドメイン名をドメイン名サービス プロバイダーに追加します。
次に、IIS でサイトを作成し、このサイトのホスト ヘッダーを空白のままにし、一般ポートを 80 にします。このサイトは、サーバー全体のポート 80 の既定の Web サイトです。
このサイトにワイルドカード アプリケーション マッピングを追加します ([IIS サイトのプロパティ] -> [ホーム ディレクトリ] -> [構成])。このマッピングの目的は、IIS で指定されていないセカンダリ ドメイン名サイトを asp.net ISAPI に引き継がせることです。

第 2 レベルのドメイン名を入力するとどうなりますか?
IIS は、受信 URL が第 2 レベル ドメイン名であることを検出すると、まず IIS 上にこの第 2 レベル ドメイン名で登録されているサイトがあるかどうかを確認し、存在する場合はそのサイトに転送します。そうでない場合は、そのサイトに転送します。したがって、ポートには空のホスト ヘッダーを持つサイトが 1 つだけ存在できます。
私たちは、これらのホームレスの子供たちを引き継ぐための asp.net ISAPI をセットアップし、受信 URL を分析して書き換えを実行するプログラムを作成しました。

なぜですか?

その理由は、httpmodule プログラムを Web プログラムに登録していないためです。 web.config で完了しました。
<システム.ウェブ>
<httpモジュール>
<add type="URLRewriter.ModuleRewriter, URLRewriter" name="ModuleRewriter" />
</httpモジュール>
</system.web>

「不明な構成セクション RewriterConfig エラー」が常に表示されるのはなぜですか?

これは、Web プログラムに RewriterConfig 構成セクションを登録していないためです。この作業は web.config で完了する必要があります。
<configセクション>
<section name="RewriterConfig" type="URLRewriter.Config.RewriterConfigSerializerSectionHandler、URLRewriter" />
</configセクション>
その後、<configuration> の RewriterConfig セクションを使用してルールを構成できます。

URL は httpmodule のどの部分で処理されますか?

ほとんどの作業は ModuleRewriter() メソッドで行われます。
if (re.IsMatch(requestedPath))
明らかに、これによって受信 URL が書き換えたい URL かどうかが決まります。見てみましょう。
String sendToUrl = RewriterUtils.ResolveUrl(app.Context.Request.ApplicationPath, re.Replace(requestedPath, rules[i].SendTo));
ここでは、web.config で設定されたターゲット URL を受け取ります。
RewriterUtils.RewriteUrl(app.Context, sendToUrl);
URLを内部的に書き換えます。

たとえば、このようなニーズがある場合、web.config で第 2 レベルのドメイン名をハードコーディングしたくなく、書き換えたいターゲット URL をハードコーディングすることはできません。
blog.downcodes.com の実際の処理ページは kerry.com/action.aspx?id=1 です。
call.kerryl.com の実際の処理ページは kerry.com/action.aspx?id=2 です。
walkwith.kerry.com の実際の処理ページは kerry.com/walk.aspx です。
どうやって対処すればいいのでしょうか？

この時点で、上記のコードにいくつかの操作を行う必要があります。
if (re.IsMatch(requestedPath))
{

// URL 内の第 2 レベルのドメイン名を検索します
string [] UserHost = app.Request.Url.Host.Split ( new Char [] { '.' } );
string domain2=UserHost [0]

//必要に応じて書き換え対象の URL を設定します
文字列 sendToUrl;
if(ドメイン2==”愛”)
sendToUrl =”/action.aspx?id=1”;
else if(domain2==”呼び出し”)
sendToUrl =”/action.aspx?id=2”;
else if(domain2==”walkwith”)
sendToUrl =”/walk.aspx”;

RewriterUtils.RewriteUrl(app.Context, sendToUrl);

web.config でルールを構成する場合、これを行う必要があり

ます

<リライタールール>
<LookFor>http://(w+).kerry.com</LookFor>
<SendTo>/test.aspx</SendTo>
</リライタールール>
(w+) は任意の文字列と一致するために使用されます。これはまったく使用しないため、ここでは test.aspx に他のものを記述できます。

第 2 レベル ドメイン名が不明なサイトが多数ありますが、各サイトのページは実際には異なる ID に基づいてデータベースから取得されます。
状況はこんな感じです
http://localhost/kerry/action.aspx?id=1 blog.downcodes.com/walk.aspx

http://localhost/kerry/action.aspx?id=14 like.kerry.com/walk.aspx

今すぐパス上に進むと、id パラメータが表示されず、第 2 レベルのドメイン名に変更されます。この場合、

まずルールを設定します。
<リライタールール>
<LookFor>http://(w+).kerry .com walk.aspx</LookFor>
<SendTo>/action.aspx</SendTo>
</リライタールール>
次に、プログラム内で次のように処理します
//セカンドレベルドメイン名を取得する
string [] UserHost = app.Request.Url.Host.Split ( new Char [] { '.' } );
文字列ドメイン2=ユーザーホスト[0];
ドメイン名に基づいて異なる番号を取得する
int id=getIDfromDomain(domain2);
// リダイレクト先の基本 URL を取得します
string sendToUrl = RewriterUtils.ResolveUrl(app.Context.Request.ApplicationPath, re.Replace(requestedPath, rules[i].SendTo));
//idパラメータを追加
if(id>0)
sendToUrl=string.Format ( "{0}?id={1}" , sendToUrl , id );
それ以外
sendToUrl=”error.aspx”;
//リライト
RewriterUtils.RewriteUrl(app.Context, sendToUrl);

オンラインで検索したところ、別の解決策がありました...

おそらくこの記事を参照しています

http://blog.csdn.net/mengyao/archive/2007/01/25/ 1493537 .aspx

ご覧のとおり、基本的な方法は同じです。これが上部にリストされていないのは、このアプローチが少し難しく、最初は理解するのが難しいためです。この記事をもう一度読むと、きっとあなたも思わず笑ってしまうでしょう
楽しいプログラミング

最後に追記: この記事は数日以内に公開する予定でしたが、たった今、ここ数日で作成したプログラムをすべて VSS から削除してしまいました。もう一度言いますが、私はこのゴミを大嫌いです。 Microsoft 製のソース コード マネージャー-_ -

http://www.cnblogs.com/notus/archive/2007/03/13/673222.html