0

マーケティングサイトに代わる新しいSitefinityサイトがあります。先週の金曜日に切り替えが発生し、今日問題が見つかりました。古いサイトにアクセスできなくなったコンテンツ（pdf、jpg）があり、コンテンツ移行計画に含まれていませんでした。その上、経営陣はオプションとしてロールバックを削除しました。

したがって、私が思いついた解決策は、IIS 7のURL書き換えモジュールを使用して、コンテンツにアクセスできるように古いサイトをホストする新しいURLを指すことです。これは私が思いついたweb.configのxmlです：

<rewrite>
        <rules>
            <rule name="RedirectFileNotFound" stopProcessing="true">
                <match url=".*" />
                <conditions logicalGrouping="MatchAll">
                    <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
                    <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />                    
                    <add input="{URL}" negate="false" pattern="/\.*$" />
                </conditions>
                <action type="Redirect" url="http://www.oldsite.com{REQUEST_URI}" appendQueryString="true" />
            </rule>
        </rules>
    </rewrite>

URLがファイルまたはフォルダーに解決されるかどうかをテストし、拡張子が付いたものを要求していることを確認します。ルールに合格すると、古いサイトの同じ場所にリダイレクトされます。理想的には、これは、以前に古いサイトにリンクしていたものはすべてそのままにしておくことができることを意味します。

問題は、何もリダイレクトされないことです。

ルールをいじることで、モジュールが動作していることを確認しました。つまり、すべてを書き換えるように設定でき、動作します。しかし、これらのルールは機能しません。

私の理論では、Sitefinityはデータベースストレージを使用しているため、「IsFile」マッチタイプを何らかの形で短絡させます。完全な推測ですが、私はこの時点で少し途方に暮れています。

この方法でurlrewritingを使用して404をリダイレクトするにはどうすればよいですか？

4

3 に答える 3

0

リライターがどのように実装されているかはわかりませんが、これらのルールは一般的すぎるようです。Sitefinityはルーティングエンジンを使用して、処理する一連のルートを登録します。定義上、これらのルートは順番に解釈されるため、より一般的なルールがより具体的なルールの前に存在する場合、後者は機能しません。

何が起こっているのかは、リライタがリダイレクトする機会を得る前に、Sitefinityルールがすでにリクエストを処理していることだと思います。私がアドバイスできるのは、より具体的な書き換え/リダイレクトルールを実装するか、別のアプローチを使用して問題全体を処理することです。移行後に古いファイルにアクセスできなくなった理由は何ですか？シナリオを処理できるように、ファイルを返さない特定のURLを指定できますか？

于 2012-10-03T11:25:58.567 に答える
0

これは暗闇の中でのショットですが、ライブラリのsitefinity詳細設定で「ファイルシステムフォールバック」を有効にしていますか？おそらく、モジュールは要求をインターセプトしていて、ファイルシステムに処理させていません...

于 2012-10-03T15:22:57.160 に答える
0

皆さんの助けに感謝しますが、それは一般的にダイナミックサーブドコンテンツの問題であることが判明しました。

すべてのリクエストが実際にはDefault.aspxページによって処理されると想定します。これはSitefinityが機能する方法ではありませんが、DotNetNukeが機能する方法であり、問​​題をうまく示しています。

URLリライトisfileおよびisdirectoryフラグは、ファイルの物理的な存在をチェックします。この場合、Default.aspxのみが実際に物理的に存在します。他のすべての動的に提供されるコンテンツは、要求サイクルの後半で生成され、物理的な存在はまったくありません。

そのため、isfileフラグは常に失敗し、リダイレクトルールは常に実行されます。

私が行った解決策は、IISと.NETが404自体を処理できるようにすることでした。これにより、生成されたコンテンツが適切に尊重されます。それをカスタムエラーページ404redirection.aspxにルーティングします。そのページには、そのコンテンツがホストされている可能性が高い古いサイトにリダイレクトするコードがあります。そのサイトには、404NotFound.aspxページに戻る404処理が追加されているため、どちらのシステムにも存在しないファイルのリクエストは往復し、どこにも行かなかったように見えます。これには、古いサーバーにないページが新しいサーバーに新しい、きれいな、ブランド変更された404を表示するという素晴らしい副作用もあります。

簡単に言えば、コンテンツの生成とエラー処理を先取りしようとするのではなく、より「フローに沿って」アプローチを取り、より適切なタイミングでフローを迂回させました。

于 2012-10-05T18:18:33.907 に答える