クライアントが.html拡張子を処理したいというシナリオに出くわしました。 彼らは、.html用に301を作成し、Sitecoreアプリケーションのようにいくつかのhtmlファイルを提供したいと考えています。
私が最初に考えたのは、ハンドル.html拡張子のWeb構成に.htmlハンドルを作成することでした。
そうすると、301の.html拡張子を処理できましたが、ハンドラーがあるため、IISがすべての.html拡張子をアプリケーションに送信するため、静的なhtmlファイルを提供できませんでした。
IISが静的htmlを提供しないため、「リダイレクトが多すぎる」ため、静的ファイルの同じURLにリダイレクトすることはできません。
次に、Sitecoreが提供する拡張機能を決定する場所がある場合は、パイプラインを検索しようとしました。
Sitecoreがこのタイプの拡張機能を提供するかどうかを決定する「CheckIgnoreFlag」パイプラインを見つけました。提供しない場合はfalseを返し、そうでない場合はtrueを返します。
<?xml version="1.0" encoding="utf-8"?> <configuration xmlns:patch="http://www.sitecore.net/xmlconfig/" xmlns:set="http://www.sitecore.net/xmlconfig/set/"> <pipelines> <httpRequestBegin> <processor patch:before="processor[@type='Sitecore.Pipelines.PreprocessRequest.CheckIgnoreFlag, Sitecore.Kernel']" type="[Namespace].Class, [Namespace]"/> </httpRequestBegin> </pipelines> </sitecore> </configuration>
ここでは、拡張機能を確認します。 そこで、ここで301リダイレクトを作成し、受信URLの301リダイレクトがない場合は、同じパスに物理ファイルが存在するかどうかを確認します。
Sitecoreに処理を任せます。 これで、SitecoreはこのURLを処理できないことをIISにfalseで返します。
次に、IISはその物理ファイルを見つけようとし、リダイレクトします。
同じパスに物理ファイルが見つからない場合は、404ページにリダイレクトします。
このようにして、IIS 404ページを表示する代わりに、さまざまな拡張機能の404を処理することもできます。