私は新しい仕事を始めた後、古いシステムを継承しました。以前の開発者は誰もここで働いておらず、誰もそれほど文書化していません。楽しい時間。
このシステムは古い CMS を使用しており、ルーティングがどのように機能するかを一生理解できなかったという大きな試練を終えたところです (クライアントは URL の変更を望んでいました)。以前の開発者は「Helicon ISAPI rewrite」と呼ばれる完全に別のプログラムを使用し、そこからサイトの URL 管理をすべて行っていたことが後で判明しました。
私の質問は次のとおりです: どうすればこれをより迅速に把握できたでしょうか (たとえば、使用できた外部ツールや、このルーティングがどのように機能していたかを明らかにすることのできないログはありますか?)。
答えがそこにさえなかったとき、私は10年分のコードを選んで午後を過ごしました! 今、私はそれをすぐに理解する機会がなかったと感じていますが、何かが欠けているのではないかと思っています.
そもそも書き換えを発見するために、あなたが求めていることを理解していると思います。ISAPI_Rewrite について前もって知っていれば、Tony の答えは正しいですが、後知恵は 20-20 です。私は ISAPI_Rewrite と Helicon Ape の大ファンなので、疑っていたかもしれません。ただし、書き換えが IIS7 の .NET web.config によって行われている場合、私はそこを調べませんでした (ただし、web.config は、IIS のねじれを開始する場所である必要があると思います)。従来の CMS や WordPress のようなものでは、どこから始めればよいかわからなかったので、おそらくあなたのようなコードから始めるでしょう。
本当の出発点は、要求が Web コードに到達する前の IIS の上部にあると思います。
IIS7 を見回すと、さまざまな要求をインターセプトしているハンドラー マッピングがたくさんあります。これらはすべて、リクエストが Web サイトに到達する前に「処理」を実行できます。たとえば、.NET 4.0 へのアップグレード時に破壊的変更として問題を引き起こした Microsoft の ExtensionlessUrlHandler... を見ました。何が eurl.axd を URL に入れているのか疑問に思いながら、これを掘り下げる必要がありました。
IIS6 には、Web サイトのプロパティに [ISAPI フィルター] タブがあります。私のものには ISAPI_Rewrite と ASP.NET_2.0 が含まれています。また、MIME タイプを含む HTTP ヘッダー タブもあります。これは、リクエストを迂回させる原因となる可能性があります。
これを知っていると、おそらくすべての書き換えソフトウェアのリストが便利になるでしょう。インストールされているものをシステムで検索するだけで、最初の手がかりを得る最速の方法になる可能性があります。
実際、10 年間のコードに午後を費やしたとしても、それはそれほど悪くはありません! そのため、これをすぐに理解する機会はなかったかもしれません.レガシーシステムには秘密が埋もれています.
ISAPI_Rewrite v3 の場合、次の行を追加することで、ISAPI_Rewrite インストール フォルダーの httpd.conf でログを有効にできます。
RewriteLogLevel 9
LogLevel debug
次に、いくつかのテスト要求を行った後、rewrite.log および error.log ファイルが ISAPI_Rewrite インストール フォルダーに表示されます。error.log は一般的な問題を示し、rewrite.log はルールが適用された方法と適用されたかどうか、および結果の URL が何であるかを示します。