Show Menu
トピック×

Dispatcher の設定

Dispatcher のバージョンは AEM とは無関係です。以前のバージョンの AEM のドキュメントに組み込まれている Dispatcher のドキュメントへのリンクをたどると、このページにリダイレクトされる可能性があります。
以下の節では、Dispatcher の様々な設定について説明します。

IPv4 と IPv6 のサポート

AEM と Dispatcher のすべての要素は、IPv4 と IPv6 の両方のネットワークにインストールできます。 IPv4 と IPv6 を参照してください。

Dispatcher の設定ファイル

デフォルトでは、Dispatcher の設定は dispatcher.any テキストファイルに格納されますが、インストール時にこのファイルの名前と場所を変更することができます。
設定ファイルには、Dispatcher の動作を制御する一連の単一値または複数値プロパティが含まれます。
  • プロパティ名の前にはフォワードスラッシュ(「 / 」)が付きます。
  • 複数値プロパティは、中括弧(「 { } 」)を使用して子アイテムを囲みます。
設定例を次に示します。
# name of the dispatcher
/name "internet-server"

# each farm configures a set off (loadbalanced) renders
/farms
 {
  # first farm entry (label is not important, just for your convenience)
   /website 
     {  
     /clientheaders
       {
       # List of headers that are passed on
       }
     /virtualhosts
       {
       # List of URLs for this Web site
       }
     /sessionmanagement 
       {
       # settings for user authentification
       }
     /renders
       {
       # List of AEM instances that render the documents
       }
     /filter
       {
       # List of filters
       }
     /vanity_urls
       {
       # List of vanity URLs
       }
     /cache
       {
       # Cache configuration
       /rules
         {
         # List of cachable documents
         }
       /invalidate
         {
         # List of auto-invalidated documents
         }
       }
     /statistics
       {
       /categories
         {
         # The document categories that are used for load balancing estimates
         }
       }
     /stickyConnectionsFor "/myFolder"
     /health_check
       {
       # Page gets contacted when an instance returns a 500
       }
     /retryDelay "1"
     /numberOfRetries "5"
     /unavailablePenalty "1"
     /failover "1"
     }
 }

設定に影響を与える他のファイルを含めることができます。
  • 設定ファイルのサイズが大きい場合、このファイルを管理しやすくするために分割した複数のファイル。
  • 自動生成されたファイル。
例えば、myFarm.any ファイルを /farms の設定に含めるには、次のコードを使用します。
/farms
  {
  $include "myFarm.any"
  }

含めるファイルの範囲を指定するには、アスタリスク(「*」)をワイルドカードとして使用します。
例えば、 farm_1.any farm_5.any のファイルにファーム 1 ~ 5 が設定されている場合、これらのファイルを次のように含めることができます。
/farms
  {
  $include "farm_*.any"
  }

環境変数の使用

値を直接記述する代わりに、dispatcher.any ファイルの単一値プロパティに環境変数を使用できます。環境変数の値を含めるには、 ${variable_name} という形式を使用します。
例えば、dispatcher.any ファイルがキャッシュディレクトリと同じディレクトリに配置されている場合は、 docroot プロパティに次の値を使用できます。
/docroot "${PWD}/cache"

もう 1 つの例として、AEM パブリッシュインスタンスのホスト名を格納する PUBLISH_IP という環境変数を作成した場合は、 /renders プロパティの次の設定を使用できます。
/renders {
  /0001 {
    /hostname "${PUBLISH_IP}"
    /port "8443"
  }
}

Dispatcher インスタンスの命名

Dispatcher インスタンスを識別する一意の名前を指定するには、 /name プロパティを使用します。 /name プロパティは、設定構造の最上位プロパティです。

ファームの定義

/farms プロパティは、1 つまたは複数の Dispatcher の動作セットを定義します。各セットは、異なる Web サイトまたは URL に関連付けられます。 /farms プロパティには、1 つまたは複数のファームを含めることができます。
  • Dispatcher ですべての Web ページまたは Web サイトを同じ方法で処理する場合は、単一のファームを使用します。
  • Web サイトの異なる領域または異なる Web サイトに異なる Dispatcher 動作が必要な場合は、複数のファームを作成します。
/farms プロパティは、設定構造の最上位プロパティです。ファームを定義するには、 /farms プロパティに子プロパティを追加します。Dispatcher インスタンス内でファームを一意に識別するプロパティ名を使用してください。
/farmname プロパティは複数値で、次のような Dispatcher 動作を定義する他のプロパティを含みます。
  • ファームを適用するページの URL。
  • ドキュメントのレンダリングに使用する 1 つまたは複数のサービス URL(一般的には AEM パブリッシュインスタンスの URL)。
  • 複数のドキュメントレンダラーのロードバランシングに使用する統計。
  • キャッシュするファイルおよびその場所など、その他の動作。
値には、任意の英数字(a ~ z、0 ~ 9)を含めることができます。 /daycom および /docsdaycom という 2 つのファームのスケルトン定義の例を次に示します。
#name of dispatcher
/name "day sites"

#farms section defines a list of farms or sites
/farms
{
   /daycom
   {
       ...
   }
   /docdaycom
   {
      ...
   }
}

レンダーファームを複数使用する場合、リストは下から順に評価されます。この順序は、Web サイトの 仮想ホスト を定義する場合に特に重要です。
各ファームプロパティには、以下の子プロパティを含めることができます。
プロパティ名
説明
デフォルトのホームページ(オプション)(IIS のみ)
通過させるクライアント HTTP 要求のヘッダー。
このファームの仮想ホスト。
セッション管理および認証のサポート。
レンダリングされたページを提供するサーバー(一般的には AEM パブリッシュインスタンス)。
Dispatcher がアクセスできる URL を定義します。
バニティー URL へのアクセスを設定します。
シンジケーション要求の転送のサポート。
キャッシュ動作を設定します。
ロードバランシング計算用の統計カテゴリの定義。
スティッキードキュメントを格納するフォルダー。
サーバーの可用性を判断するために使用する URL。
失敗した接続を再試行するまでの遅延。
ロードバランシング計算用の統計に影響を与えるペナルティ。
元の要求が失敗した場合に異なるレンダーに要求を再送信します。
For permission-sensitive caching, see Caching Secured Content .

デフォルトページの指定(IIS のみ) - /homepage

/homepage パラメーター(IISのみ)は機能しなくなりました。Instead, you should use the IIS URL Rewrite Module .
Apache を使用している場合は mod_rewrite モジュールを使用する必要があります。See the Apache web site documentation for information about mod_rewrite (for example, Apache 2.4 ). When using mod_rewrite , it is advisable to use the flag 'passthrough|PT' (pass through to next handler) ​to force the rewrite engine to set the uri field of the internal request_rec structure to the value of the filename field.

通過させる HTTP ヘッダーの指定

/clientheaders プロパティでは、Dispatcher がクライアント HTTP 要求からレンダラー(AEM インスタンス)に渡す HTTP ヘッダーのリストを定義します。
デフォルトでは、Dispatcher から AEM インスタンスに標準の HTTP ヘッダーが転送されます。インスタンスによっては、追加のヘッダーを転送したり、特定のヘッダーを削除したりできます。
  • AEM インスタンスが HTTP 要求で予期するヘッダー(カスタムヘッダーなど)を追加します。
  • ヘッダー(Web サーバーに対してのみ重要な認証ヘッダーなど)を削除します。
通過させる一連のヘッダーをカスタマイズした場合は、ヘッダーの完全なリスト(通常はデフォルトで含まれるヘッダーを含む)を指定する必要があります。
例えば、パブリッシュインスタンス向けのページアクティベーション要求を処理する Dispatcher インスタンスには、 PATH セクションに /clientheaders ヘッダーが必要です。 PATH ヘッダーは、レプリケーションエージェントと Dispatcher 間の通信を可能にします。
次のコードは、 /clientheaders の設定例です。
/clientheaders
  {
  "CSRF-Token"
  "X-Forwarded-Proto"
  "referer"
  "user-agent"
  "authorization"
  "from"
  "content-type"
  "content-length"
  "accept-charset"
  "accept-encoding"
  "accept-language"
  "accept"
  "host"
  "if-match"
  "if-none-match"
  "if-range"
  "if-unmodified-since"
  "max-forwards"
  "proxy-authorization"
  "proxy-connection"
  "range"
  "cookie"
  "cq-action"
  "cq-handle"
  "handle"
  "action"
  "cqstats"
  "depth"
  "translate"
  "expires"
  "date"
  "dav"
  "ms-author-via"
  "if"
  "lock-token"
  "x-expected-entity-length"
  "destination"
  "PATH"
  }

仮想ホストの識別

/virtualhosts プロパティは、Dispatcher がこのファームに受け入れるすべてのホスト名と URI の組み合わせのリストを定義します。ワイルドカードとしてアスタリスク(「*」)文字を使用できます。/ virtualhosts プロパティの値には、次の形式を使用します。
[scheme]host[uri][*]

次の設定例では、myCompany の .com ドメインと .ch ドメイン、さらに mySubDivision のすべてのドメインに対する要求を処理します。
   /virtualhosts
    {
    "www.myCompany.com"
    "www.myCompany.ch"
    "www.mySubDivison.*"
    }

次の設定は、 すべての ​要求を処理します。
   /virtualhosts
    {
    "*"
    }

仮想ホストの解決

HTTP 要求または HTTPS 要求を受信すると host, uri および scheme ヘッダーに最適な仮想ホスト値を探します。Dispatcher は、次の順序で virtualhosts プロパティの値を評価します。
  • dispatcher.any ファイル内の一番下のファームから始め、上方向へ進みます。
  • ファームごとに、 virtualhosts プロパティの最上位の値から始め、値のリストの下方向へ進みます。
Dispatcher は、以下の方法で最良一致の仮想ホスト値を探します。
  • 要求の host scheme uri の 3 つすべてに一致する、最初に見つかった仮想ホストを使用します。
  • 要求の virtualhosts scheme の両方に一致する uri 部と scheme 部を持つ uri 値がない場合は、要求の host に一致する、最初に見つかった仮想ホストを使用します。
  • 要求の host に一致する host 部を持つ virtualhosts 値がない場合は、最上位ファームの最上位の仮想ホストを使用します。
したがって、デフォルトの仮想ホストは dispatcher.any ファイルの最上位ファームの virtualhosts プロパティの一番上に配置する必要があります。

仮想ホストの解決の例

以下に示す dispatcher.any ファイルのスニペットの例では、2 つの Dispatcher ファームを定義し、各ファームは virtualhosts プロパティを定義しています。
/farms
  {
  /myProducts 
    { 
    /virtualhosts
      {
      "www.mycompany.com"
      }
    /renders
      {
      /hostname "server1.myCompany.com"
      /port "80"
      }
    }
  /myCompany 
    { 
    /virtualhosts
      {
      "www.mycompany.com/products/*"
      }
    /renders
      {
      /hostname "server2.myCompany.com"
      /port "80"
      }
    }
  }

以下の表は、この例の場合に、指定された HTTP 要求がどの仮想ホストへと解決されるかを示しています。
要求 URL
解決される仮想ホスト
https://www.mycompany.com/products/gloves.html
www.mycompany.com/products/
https://www.mycompany.com/about.html
www.mycompany.com

セキュアセッションの有効化 - /sessionmanagement

この機能を有効にするには、 /cache セクションで /allowAuthorized 必ず "0" に設定してください。
レンダーファームにアクセスするためのセキュアセッションを作成して、このファーム内のページにユーザーがアクセスする際にログインが必要になるようにします。ログイン後、ユーザーはファーム内のページにアクセスできます。閉じられたユーザーグループ(CUG)でのこの機能の使用については、 閉じられたユーザーグループの作成 を参照してください。また、運用を開始する前に、Dispatcher の セキュリティチェックリスト を参照してください。
/sessionmanagement プロパティは /farms のサブプロパティです。
Web サイトのセクションによってアクセス要件が異なる場合は、複数のファームを定義する必要があります。
/sessionmanagement には、いくつかのサブパラメーターがあります。
/directory (必須)
セッション情報を格納するディレクトリ。ディレクトリが存在しない場合は自動的に作成されます。
ディレクトリサブパラメーターを設定する場合は、重大な問題が発生する可能性があるので、ルートフォルダー( /directory "/" )を指定​ しないでください 。セッション情報を格納したフォルダーのパスを必ず指定してください。次に例を示します。
/sessionmanagement 
  { 
  /directory "/usr/local/apache/.sessions"
  }

/encode (オプション)
セッション情報のエンコード方法。md5 アルゴリズムを使用した暗号化には "md5" を、16 進エンコーディングには "hex" を使用します。セッションデータを暗号化すると、ファイルシステムにアクセスできるユーザーでも、セッション内容を読み取れなくなります。デフォルトは "md5" です。
/header (オプション)
認証情報を格納する HTTP ヘッダーまたは cookie の名前。ヘッダーに情報を格納する場合は、 HTTP:<*header-name*> を適用します。cookie に情報を格納する場合は、 Cookie:<header-name> を適用します。値を指定しない場合、 HTTP:authorization が適用されます。
/timeout (オプション)
最後の使用から、セッションのタイムアウトまでの秒数。指定がない場合は "800" が適用され、ユーザーからの最後の要求から約 13 分でセッションがタイムアウトします。
設定例を次に示します。
/sessionmanagement 
  { 
  /directory "/usr/local/apache/.sessions" 
  /encode "md5" 
  /header "HTTP:authorization" 
  /timeout "800" 
  }

ページレンダラーの定義

/renders プロパティは、ドキュメントをレンダリングするために Dispatcher が要求を送信する URL を定義します。次の /renders セクションの例では、レンダリングのために単一の AEM インスタンスを識別しています。
/renders
  {
    /myRenderer
      {
      # hostname or IP of the renderer
      /hostname "aem.myCompany.com"
      # port of the renderer
      /port "4503"
      # connection timeout in milliseconds, "0" (default) waits indefinitely
      /timeout "0"
      }
  }

次の例の/rendersセクションは、ディスパッチャーと同じコンピューター上で実行されるAEMインスタンスを識別します。
/renders
  {
    /myRenderer
     {
     /hostname "127.0.0.1"
     /port "4503"
     }
  }

次の /renders セクションの例では、2 つの AEM インスタンス間で平等にレンダリング要求を分配しています。
/renders
  {
    /myFirstRenderer
      {
      /hostname "aem.myCompany.com"
      /port "4503"
      }
    /mySecondRenderer
      {
      /hostname "127.0.0.1"
      /port "4503"
      }
  }

レンダーのオプション

/timeout
AEM インスタンスにアクセスする接続タイムアウトをミリ秒単位で指定します。デフォルトは "0" で、Dispatcher は無制限に待機します。
/receiveTimeout
応答が返るまでに許容される時間をミリ秒単位で指定します。デフォルトは "600000" で、Dispatcher は 10 分間待機します。"0" に設定すると、タイムアウトが完全になくなります。 応答ヘッダーの解析中にタイムアウトに達した場合は、HTTP ステータス 504(Bad Gateway)が返されます。応答本文の読み取り中にタイムアウトに達した場合は、Dispatcher は不完全な応答をクライアントに返しますが、作成されたキャッシュファイルがあれば削除します。
/ipv4
レンダーの IP アドレスを取得するために Dispatcher が getaddrinfo 関数(IPv6 用)を使用するか gethostbyname 関数(IPv4 用)を使用するかを指定します。値 0 を指定すると、 getaddrinfo が使用されます。値 1 を指定すると、 gethostbyname が使用されます。デフォルト値は 0 です。
getaddrinfo 関数は、IP アドレスのリストを返します。Dispatcher は、TCP/IP 接続を確立するまで、そのアドレスのリストを繰り返します。したがって、常に同じ順序で IP アドレスのリストを返す getaddrinfo 関数に応じてレンダーホスト名が複数の IP アドレスおよびホストと関連付けられている場合は、ipv4 プロパティが重要になります。このような状況では、Dispatcher が接続する IP アドレスがランダムになるように、gethostbyname 関数を使用してください。
Amazon Elastic Load Balancing(ELB)は、同じ順序になる可能性がある IP アドレスのリストを使用して、getaddrinfo に応答するサービスです。
/secure
/secure プロパティの値が 1 の場合、Dispatcher は HTTPS を使用して AEM インスタンスと通信します。詳しくは、 Using SSL with Dispatcher を参照してください。
/always-resolve
Dispatcher バージョン 4.1.6 では、次のように /always-resolve プロパティを設定できます。
  • 「1」に設定すると、リクエストごとにホスト名が解決されます(Dispatcher はIP アドレスをキャッシュしません)。リクエストごとにホスト情報を取得するために追加の呼び出しが必要となるため、パフォーマンスが多少低下する可能性があります。
  • プロパティが設定されていない場合、IP アドレスはデフォルトでキャッシュされます。
また、次の例に示すように、このプロパティは動的な IP 解決の問題が発生した場合にも使用できます。
/renders {
  /0001 {
     /hostname "host-name-here"
     /port "4502"
     /ipv4 "1"
     /always-resolve "1"
     }
  }

コンテンツへのアクセスの設定

Dispatcher が受け入れる HTTP 要求を指定するには、 /filter セクションを使用します。それ以外のすべての要求は、エラーコード 404(ページが見つかりません)で Web サーバーに返送されます。 /filter セクションが存在しない場合は、すべての要求が受け入れられます。
注意: statfile に対する要求は常に拒否されます。
Dispatcher を使用してアクセスを制限する場合の詳しい考慮事項については、 Dispatcher セキュリティチェックリスト を参照してください。また、AEMのインストールに関するその他の セキュリティの詳細については 、AEMセキュリティチェックリストを参照してください。
/filter セクションは、HTTP 要求の要求行部分のパターンに応じてコンテンツへのアクセスを拒否または許可する一連のルールで構成されます。/filter セクションに対しては、ホワイトリスト戦略を使用してください。
  • まず、すべての要素へのアクセスを拒否します。
  • 必要に応じて、コンテンツへのアクセスを許可します。

フィルターの定義

/filter の各アイテムには、要求行の特定の要素または要求行全体と照合するタイプとパターンが含まれます。各フィルターには、次のアイテムを含めることができます。
  • タイプ /type は、パターンに一致する要求へのアクセスを許可するか、拒否するかを示します。値は、 allow または deny のどちらかです。
  • 要求行の要素: /query /method /url または /protocol と、HTTP 要求の要求行の特定部分に応じて要求をフィルタリングするためのパターンを含めます。要求行全体ではなく、要求行の要素に対してフィルタリングすることをお勧めします。
  • 要求行の高度な要素: Dispatcher 4.2.0 から 4 つの新しいフィルター要素を使用できます。 /path /selectors /extension /suffix の各要素です。これらを 1 つ以上含めると、URL パターンをさらに制御することができます。
要求行のうち、これらの各要素が参照する部分について詳しくは、 Sling の URL の分解 Wiki ページを参照してください。
  • glob プロパティ: HTTP 要求の要求行全体と照合するには、 /glob プロパティを使用します。
Dispatcher では、glob を使用したフィルタリングは廃止されました。そのため、セキュリティ上の問題につながる可能性があるので、 /filter セクションで glob を使用しないようにしてください。つまり、次の代わりに、
/glob "* *.css *"
以下を使用してください。
/url "*.css"

HTTP 要求の要求行部分

HTTP/1.1 defines the request-line as follows:
Method Request-URI HTTP-Version <CRLF>
<CRLF> 文字は、キャリッジリターンとそれに続くラインフィードを表します。次の例は、クライアントが Geometrixx-Outdoors サイトの英語ページを要求したときに受信する要求行です。
GET /content/geometrixx-outdoors/en.html HTTP.1.1<CRLF>
パターンは、要求行の空白文字と <CRLF> 文字を考慮する必要があります。

二重引用符と一重引用符

フィルタールールを作成する場合、単純なパターンには二重引用符を使用します(例: "pattern" )。Dispatcher 4.2.0 以降を使用しており、パターンに正規表現が含まれている場合は、正規表現パターンを一重引用符で囲む必要があります(例: '(pattern1|pattern2)' )。

正規表現

Dispatcher 4.2.0 以降は、フィルターパターンに POSIX 拡張正規表現を含めることができます。

フィルターのトラブルシューティング

フィルターが想定どおりにトリガーされない場合は、Dispatcher で トレースログ を有効にして、要求を傍受しているフィルターを確認できるようにします。

サンプルフィルター:すべて拒否

次のサンプルのフィルターセクションによって、Dispatcher がすべてのファイルに対する要求を拒否します。すべてのファイルへのアクセスを拒否してから、特定の領域へのアクセスを許可してください。
  /0001  { /glob "*" /type "deny" }

明示的に拒否された領域への要求に対して、「404 error code (page not found)」が返されます。

サンプルフィルター:特定の領域へのアクセスを拒否

フィルターを使用して、サンプルの ASP ページの各種要素と、パブリッシュインスタンス内の機密領域へのアクセスを拒否することもできます。次のフィルターは、ASP ページへのアクセスを拒否するものです。
/0002  { /type "deny" /url "*.asp"  }

サンプルフィルター:POST 要求の有効化

次のサンプルフィルターを使用して、POST メソッドでフォームデータを送信できます。
/filter {
    /0001  { /glob "*" /type "deny" }
    /0002 { /type "allow" /method "POST" /url "/content/[.]*.form.html" }
}

サンプルフィルター:ワークフローコンソールへのアクセスを許可

次の例は、Workflow コンソールへの外部アクセスを拒否するためのフィルターです。
/filter {
    /0001  { /glob "*" /type "deny" }
    /0002  {  /type "allow"  /url "/libs/cq/workflow/content/console*"  }
}

パブリッシュインスタンスで Web アプリケーションコンテキスト(例えば publish)を使用する場合は、このコンテキストをフィルター定義に追加できます。
/0003   { /type "deny"  /url "/publish/libs/cq/workflow/content/console/archive*"  }

制限された領域内の単独のページにアクセスする必要がある場合は、そのページへのアクセスを許可できます。例えば、ワークフローコンソール内の「アーカイブ」タブへのアクセスを許可する場合は、次のセクションを追加します。
/0004  { /type "allow"  /url "/libs/cq/workflow/content/console/archive*"   }

複数のフィルターパターンを 1 つの要求に適用した場合は、最後に適用されたフィルターパターンが有効になります。

サンプルフィルター:正規表現の使用

このフィルターは、ここで単一引用符の間に定義されている正規表現を使用して、非公開のコンテンツディレクトリで拡張子を有効にします。
/005  {  /type "allow" /extension '(css|gif|ico|js|png|swf|jpe?g)' }

サンプルフィルター:要求 URL の追加要素のフィルタリング

それぞれ path、selector および extensions に対するフィルターを使用して、 /content パスからのコンテンツの取得をブロックするルールのサンプルを以下に示します。
/006 {
        /type "deny"
        /path "/content/*"
        /selectors '(feed|rss|pages|languages|blueprint|infinity|tidy)'
        /extension '(json|xml|html)'
        }

サンプルの /filter セクション

Dispatcher を設定する際は、できる限り外部アクセスを制限してください。次の例では、外部の訪問者に最小限のアクセス権を付与します。
  • /content
  • デザインなどのその他のコンテンツおよびクライアントライブラリ。次のようなものがあります。
    • /etc/designs/default*
    • /etc/designs/mydesign*
フィルターを作成したら、 ページアクセスをテスト して、AEM インスタンスがセキュアであることを確認します。
以下の dispatcher.any ファイルの /filter セクションは、 Dispatcher 設定 ファイルで基礎として使用できます。
このサンプルは、Dispatcher に付属するデフォルトの設定ファイルをベースとしており、実稼動環境での使用例の役割を果たすことを目的としています。先頭に # が付いているアイテムは、非アクティブ化された(コメントアウトされた)アイテムです。これらのアイテムをアクティブ化する(該当する行の # を削除する)と、セキュリティに影響を与える可能性があるので、注意してください。
すべてに対するアクセスを拒否してから、特定の(限られた)要素へのアクセスを許可してください。
  /filter
      {
      # Deny everything first and then allow specific entries
      /0001 { /type "deny" /glob "*" }
      
      # Open consoles
#     /0011 { /type "allow" /url "/admin/*"  }  # allow servlet engine admin
#     /0012 { /type "allow" /url "/crx/*"    }  # allow content repository
#     /0013 { /type "allow" /url "/system/*" }  # allow OSGi console
        
      # Allow non-public content directories
#     /0021 { /type "allow" /url "/apps/*"   }  # allow apps access
#     /0022 { /type "allow" /url "/bin/*"    }
      /0023 { /type "allow" /url "/content*" }  # disable this rule to allow mapped content only
      
#     /0024 { /type "allow" /url "/libs/*"   }
#     /0025 { /type "deny"  /url "/libs/shindig/proxy*" } # if you enable /libs close access to proxy

#     /0026 { /type "allow" /url "/home/*"   }
#     /0027 { /type "allow" /url "/tmp/*"    }
#     /0028 { /type "allow" /url "/var/*"    }

      # Enable extensions in non-public content directories, using a regular expression
      /0041
        {
        /type "allow"
        /extension '(css|gif|ico|js|png|swf|jpe?g)'
        }

      # Enable features 
      /0062 { /type "allow" /url "/libs/cq/personalization/*"  }  # enable personalization

      # Deny content grabbing, on all accessible pages, using regular expressions
      /0081
        {
        /type "deny"
        /selectors '((sys|doc)view|query|[0-9-]+)'
        /extension '(json|xml)'
        }
      # Deny content grabbing for /content and its subtree
      /0082
        {
        /type "deny"
        /path "/content/*"
        /selectors '(feed|rss|pages|languages|blueprint|infinity|tidy)'
        /extension '(json|xml|html)'
        }

#     /0087 { /type "allow" /method "GET" /extension 'json' "*.1.json" }  # allow one-level json requests
}

Apache と共に使用する場合は、Dispatcher モジュールの DispatcherUseProcessedURL プロパティに応じてフィルター URL パターンをデザインしてください(「 Apache Web サーバー - Dispatcher 用の Apache Web サーバーの設定 」を参照。)
ダイナミックメディアに関するフィルター 0030 および 0031 は、AEM 6.0 以上に適用できます。
アクセスを拡張する場合は、以下の推奨事項について検討します。
  • CQ バージョン 5.4 以前を使用している場合は、 /admin への外部アクセスを常に完全に​**​無効にしてください。
  • /libs 内にあるファイルへのアクセスを許可する場合は、注意が必要です。アクセスは、個別に許可する必要があります。
  • レプリケーション複製の設定が表示されないよう、この設定へのアクセスを拒否してください。
    • /etc/replication.xml*
    • /etc/replication.infinity.json*
  • Google Gadgets のリバースプロキシへのアクセスを拒否します。
    • /libs/opensocial/proxy*
インストールによっては、 /apps /libs またはその他の場所(使用可能にする必要があります)の下に、追加のリソースが存在する場合があります。外部からアクセスされるリソースを判別するための方法として、 access.log ファイルを使用することができます。
コンソールおよびディレクトリへのアクセスによって、実稼動環境でセキュリティのリスクが発生する可能性があります。このようなアクセスに関する正当な理由が明確でない場合は、これらのエントリを非アクティブ化(コメントアウト)のままにしておいてください。
If you are using reports in a publish environment you should configure Dispatcher to deny access to /etc/reports for external visitors.

クエリ文字列の制約

Dispatcher バージョン 4.1.5 以降では、 /filter セクションを使用してクエリ文字列を制約します。 allow フィルター要素を使用して、クエリ文字列を明示的に許可し、一般的な許可を除外することを強くお勧めします。
1 つのエントリに glob 、または method url query version の組み合わせを含めることができますが、両方を含めることはできません。以下の例では、 a=* ノードに解決される URL に対してクエリ文字列 /etc を許可し、その他すべてのクエリ文字列を拒否しています。
/filter {
 /0001 { /type "deny" /method "POST" /url "/etc/*" }
 /0002 { /type "allow" /method "GET" /url "/etc/*" /query "a=*" }
}

ルールに /query が含まれる場合は、クエリ文字列を含む要求だけでなく、指定されたクエリパターンも照合します。
上記の例で、クエリ文字列を持たない /etc への要求も許可する場合は、以下のルールが必要になります。
/filter {  
>/0001 { /type "deny" /method “*" /url "/path/*" }  
>/0002 { /type "allow" /method "GET" /url "/path/*" }  
>/0003 { /type “deny" /method "GET" /url "/path/*" /query "*" }  
>/0004 { /type "allow" /method "GET" /url "/path/*" /query "a=*" }  
}  

Dispatcher のセキュリティのテスト

Dispatcher のフィルターは、AEM パブリッシュインスタンス上の以下のページおよびスクリプトへのアクセスをブロックする必要があります。Web ブラウザーを使用して、サイト訪問者として以下のページを開こうと試み、コード 404 が返されることを確認してください。それ以外の結果が得られた場合は、フィルターを調整してください。
/content/add_valid_page.html?debug=layout に対しては、通常のページレンダリングが表示されます。
  • /admin
  • /system/console
  • /dav/crx.default
  • /crx
  • /bin/crxde/logs
  • /jcr:system/jcr:versionStorage.json
  • /_jcr_system/_jcr_versionStorage.json
  • /libs/wcm/core/content/siteadmin.html
  • /libs/collab/core/content/admin.html
  • /libs/cq/ui/content/dumplibs.html
  • /var/linkchecker.html
  • /etc/linkchecker.html
  • /home/users/a/admin/profile.json
  • /home/users/a/admin/profile.xml
  • /libs/cq/core/content/login.json
  • /content/../libs/foundation/components/text/text.jsp
  • /content/.{.}/libs/foundation/components/text/text.jsp
  • /apps/sling/config/org.apache.felix.webconsole.internal.servlet.OsgiManager.config/jcr%3acontent/jcr%3adata
  • /libs/foundation/components/primary/cq/workflow/components/participants/json.GET.servlet
  • /content.pages.json
  • /content.languages.json
  • /content.blueprint.json
  • /content.-1.json
  • /content.10.json
  • /content.infinity.json
  • /content.tidy.json
  • /content.tidy.-1.blubber.json
  • /content/dam.tidy.-100.json
  • /content/content/geometrixx.sitemap.txt
  • /content/add_valid_page.query.json?statement=//*
  • /content/add_valid_page.qu%65ry.js%6Fn?statement=//*
  • /content/add_valid_page.query.json?statement=//* # /(@transportPassword%20|%20@transportUri%20|%20@transportUser)
  • /content/add_valid_path_to_a_page/_jcr_content.json
  • /content/add_valid_path_to_a_page/jcr:content.json
  • /content/add_valid_path_to_a_page/_jcr_content.feed
  • /content/add_valid_path_to_a_page/jcr:content.feed
  • /content/add_valid_path_to_a_page/pagename._jcr_content.feed
  • /content/add_valid_path_to_a_page/pagename.jcr:content.feed
  • /content/add_valid_path_to_a_page/pagename.docview.xml
  • /content/add_valid_path_to_a_page/pagename.docview.json
  • /content/add_valid_path_to_a_page/pagename.sysview.xml
  • /etc.xml
  • /content.feed.xml
  • /content.rss.xml
  • /content.feed.html
  • /content/add_valid_page.html?debug=layout
  • /projects
  • /tagging
  • /etc/replication.html
  • /etc/cloudservices.html
  • /ようこそ
端末またはコマンドプロンプトで次のコマンドを発行して、匿名での書き込みアクセスが可能かどうかを判断します。ノードにはデータを書き込みできません。
curl -X POST "https://anonymous:anonymous@hostname:port/content/usergenerated/mytestnode"
端末またはコマンドプロンプトで次のコマンドを発行して、Dispatcher キャッシュの無効化を試み、コード 404 の応答を受信することを確認します。
curl -H "CQ-Handle: /content" -H "CQ-Path: /content" https://yourhostname/dispatcher/invalidate.cache

バニティー URL へのアクセスの有効化

CQ または AEM ページ用に設定されているバニティー URL へのアクセスを有効にするように Dispatcher を設定します。
バニティー URL へのアクセスが有効になると、レンダーインスタンス上で実行されているサービスを Dispatcher が定期的に呼び出して、バニティー URL のリストを取得します。Dispatcher がこのリストをローカルファイルに保存します。ページの要求が /filter セクションのフィルターによって拒否されると、Dispatcher はバニティー URL のリストを調べます。拒否された URL がリストにある場合、Dispatcher はバニティー URL へのアクセスを許可します。
バニティー URL へのアクセスを有効にするには、以下の例のような /vanity_urls セクションを /farms セクションに追加します。
 /vanity_urls {
      /url "/libs/granite/dispatcher/content/vanityUrls.html"
      /file "/tmp/vanity_urls"
      /delay 300
 }

/vanity_urls セクションには、以下のプロパティが含まれます。
  • /url :レンダーインスタンス上で実行されているバニティー URL サービスへのパス。このプロパティの値は、 "/libs/granite/dispatcher/content/vanityUrls.html" である必要があります。
  • /file :Dispatcher がバニティー URL のリストを保存するローカルファイルへのパス。Dispatcher がこのファイルに対する書き込みアクセス権を持っていることを確認してください。
  • /delay :バニティー URL サービスの呼び出し間隔(秒単位)。
If your render is an instance of AEM you must install the VanityURLS-Components package to install the vanity URL service. (See Signing In to Package Share .)
バニティー URL へのアクセスを有効にするには、以下の手順を実行します。
  1. 使用するレンダーサービスが AEM インスタンスである場合は、パブリッシュインスタンス上に com.adobe.granite.dispatcher.vanityurl.content パッケージをインストールします。
  2. AEM または CQ ページ向けに設定したバニティー URL ごとに、 [/filter](dispatcher-configuration.md#main-pars_134_32_0009) 設定がその URL を拒否していることを確認します。必要に応じて、この URL を拒否するフィルターを追加します。
  3. /farms の下に /vanity_urls セクションを追加します。
  4. Apache Web サーバーを再起動します。

シンジケーション要求の転送 - /propagateSyndPost

シンジケーション要求は、通常、Dispatcher のみを対象としているので、デフォルトではレンダラー(AEM インスタンスなど)に送信されません。
必要に応じて、シンジケーション要求を Dispatcher に転送するために、/propagateSyndPost プロパティを "1" に設定します。設定する場合、フィルターセクションで POST 要求が拒否されていないことを確認する必要があります。

Dispatcher キャッシュの設定 - /cache

/cache セクションは、Dispatcher によるドキュメントのキャッシュ方法を制御します。次のいくつかのサブプロパティを設定して、キャッシュ戦略を実装します。
  • /docroot
  • /statfile
  • /serveStaleOnError
  • /allowAuthorized
  • /rules
  • /statfileslevel
  • /invalidate
  • /invalidateHandler
  • /allowedClients
  • /ignoreUrlParams
  • /headers
  • /mode
  • /gracePeriod
  • /enableTTL
キャッシュセクションの例を次に示します。
/cache
  {
  /docroot "/opt/dispatcher/cache"
  /statfile  "/tmp/dispatcher-website.stat"          
  /allowAuthorized "0"
      
  /rules
    {
    # List of files that are cached
    }

  /invalidate
    {
    # List of files that are auto-invalidated
    }
  }
  

権限を区別するキャッシュについては、 セキュリティ保護されたコンテンツのキャッシュ をお読みください。

キャッシュディレクトリの指定

/docroot プロパティは、キャッシュされたファイルを保存するディレクトリを識別します。
Dispatcher と Web サーバーが同じファイルを処理できるよう、この値は Web サーバーのドキュメントルートとまったく同じパスの必要があります。 Dispatcher のキャッシュファイルが使用されると、Web サーバーは適切なステータスコードを配信します。そのため、キャッシュファイルを見つけられることが重要になります。
複数のファームを使用する場合は、ファームごとに異なるドキュメントルートを使用する必要があります。

statfile の命名

/statfile プロパティは、statfile として使用するファイルを識別します。Dispatcher は、このファイルを使用して、最も新しいコンテンツ更新時刻を登録します。statfile には、Web サーバー上の任意のファイルを指定できます。
statfile にはコンテンツがありません。コンテンツが更新されると、Dispatcher がタイムスタンプを更新します。デフォルトの statfile 名は .stat で、ドキュメントルートに保存されます。Dispatcher は、statfile へのアクセスをブロックします。
/statfileslevel が設定されている場合、Dispatcher は /statfile プロパティを無視し、名前として .stat を使用します。

エラー発生時の古くなったドキュメントの返送

/serveStaleOnError プロパティは、レンダーサーバーがエラーを返した場合に Dispatcher が無効になったドキュメントを返すかどうかを制御します。デフォルトでは、statfile にアクセスし、キャッシュされたコンテンツが無効になると、Dispatcher は次回要求時にキャッシュされたコンテンツを削除します。
/serveStaleOnError が 「1」 に設定されている場合は、レンダーサーバーが成功応答を返さない限り、Dispatcher は無効になったコンテンツをキャッシュから削除しません。AEM からの応答 5xx または接続タイムアウトによって、Dispatcher は期限切れのコンテンツを返し、HTTP ステータス 111(再検証失敗)で応答します。

認証使用時のキャッシュ

/allowAuthorized プロパティは、以下のいずれかの認証情報を含む要求をキャッシュするかどうかを制御します。
  • authorization ヘッダー。
  • authorization という cookie。
  • login-token という cookie。
デフォルトでは、この認証情報を含む要求はキャッシュされません。キャッシュされたドキュメントをクライアントに返す場合、認証は実行されないからです。この設定によって、Dispatcher は、必要な権限を持たないユーザーにキャッシュされたドキュメントを返さなくなります。
ただし、認証済みドキュメントのキャッシュを要件によって承認する場合は、/allowAuthorized を "1" に設定します。
/allowAuthorized "1"
セッション管理( /sessionmanagement プロパティを使用)を有効にするには、 /allowAuthorized プロパティを "0" に設定する必要があります。

キャッシュするドキュメントの指定

/rules プロパティは、ドキュメントパスに応じてキャッシュされるドキュメントを制御します。/rules プロパティにかかわらず、Dispatcher は以下の状況にあるドキュメントをキャッシュしません。
  • 要求 URI に疑問符(「?」)が含まれている場合。 疑問符は通常、キャッシュの必要がない、検索結果などの動的ページを指します。
  • ファイル拡張子が不明の場合。 Web サーバーでドキュメントのタイプ(MIME タイプ)を判別するために、拡張子が必要です。
  • 認証ヘッダー(設定可)が設定されている場合。
  • AEM インスタンスが以下のヘッダーで応答する場合。
    • no-cache
    • no-store
    • must-revalidate
(HTTP ヘッダー用の)GET または HEAD メソッドは、Dispatcher によってキャッシュ可能です。応答ヘッダーのキャッシュについて詳しくは、 HTTP 応答ヘッダーのキャッシュ セクションを参照してください。
/rules プロパティの各アイテムには、 glob パターンとタイプが含まれます。
  • glob パターンは、ドキュメントのパスの照合に使用されます。
  • タイプは、glob パターンに一致するドキュメントをキャッシュするかどうかを示します。値は、allow(ドキュメントをキャッシュする)または deny(ドキュメントを常にレンダリングする)のどちらかです。
以上のルールで除外されるもの以外にも動的ページがない場合、Dispatcher ですべてのドキュメントをキャッシュできます。この場合、ルールセクションは次のようになります。
/rules
  { 
    /0000  {  /glob "*"   /type "allow" }
  }

glob プロパティについて詳しくは、 glob プロパティのパターンのデザイン を参照してください。
ページ内に動的なセクション(ニュースアプリケーションなど)や、非公開のユーザーグループで使用するセクションがある場合は、以下のように例外を定義できます。
キャッシュされたページでユーザー権限をチェックできないので、非公開のユーザーグループはキャッシュできません。
/rules
  {
   /0000  { /glob "*" /type "allow" }
   /0001  { /glob "/en/news/*" /type "deny" }
   /0002  { /glob "*/private/*" /type "deny"  }   
  }

圧縮
Apache Web サーバーでは、キャッシュされたドキュメントを圧縮することができます。クライアントから要求された場合は、Apache から圧縮形式のドキュメントを返すことができます。例えば、Apache モジュールの mod_deflate を有効にすることで、圧縮は自動的に行われます。
AddOutputFilterByType DEFLATE text/plain

このモジュールは Apache 2.x にデフォルトでインストールされています。

フォルダーレベルでのファイルの無効化

/statfileslevel プロパティを使用して、キャッシュされたファイルをパスに応じて選択的に無効化します。
  • Dispatcher は、ドキュメントルートフォルダーから指定したレベルまでの各フォルダーに .stat ファイルを作成します。ドキュメントルートはレベル 0 です。
  • .stat ファイルが更新されると、ファイルは無効化されます。 .stat ファイルの最終変更日と、キャッシュされたドキュメントの最終変更日を比較します。 .stat ファイルのほうが新しい場合は、ドキュメントを再取得します。
  • 特定のレベルにあるファイルが無効化されると、docroot から ​無効化されたファイルのレベルまたは設定された statsfilevel まで(いずれか小さい方)の​ すべての .stat ファイルが touch されます。
    • 例えば、 statfileslevel プロパティを 6 に設定し、レベル 5 でファイルが無効化されると、docroot から 5 までのすべての .stat ファイルが touch されます。この例では、ファイルがレベル 7 で無効化されると、docroot から 6 までのすべての . stat ファイルが touch されます( /statfileslevel = "6" なので)。
Only resources along the path to the invalidated file are affected. 次の例を考えて見ましょう。Web サイトで /content/myWebsite/xx/. 構造を使用していて、 statfileslevel を 3 に設定している場合、 .stat ファイルは次のように作成されます。
  • docroot
  • /content
  • /content/myWebsite
  • /content/myWebsite/*xx*
ファイル /content/myWebsite/xx が無効化された場合、docroot から /content/myWebsite/xx までのすべての .stat ファイルが touch されます。これは、 /content/myWebsite/xx のみに当てはまり、 /content/myWebsite/yy /content/anotherWebSite などには当てはまりません。
無効化は、追加のヘッダー CQ-Action-Scope:ResourceOnly を送信することで防止できます。これを使用することで、キャッシュの他の部分を無効化せずに、特定のリソースをフラッシュできます。See this page and Manually Invalidating the Dispatcher Cache for additional details.
注意: /statfileslevel プロパティの値を指定した場合、 /statfile プロパティは無視されます。

キャッシュされたファイルの自動無効化

/invalidate プロパティは、コンテンツが更新されたときに自動的に無効化されるドキュメントを定義します。
自動無効化を使用する場合、Dispatcher はキャッシュされたファイルをコンテンツの更新後に削除しませんが、次回要求されたときにその有効性を確認します。自動無効化されない、キャッシュ内のドキュメントは、コンテンツの更新によって明示的に削除されるまでキャッシュに残ります。
自動無効化は通常、HTML ページに対して使用されます。多くの場合、HTML ページには他のページへのリンクが含まれるので、コンテンツの更新がページに影響を与えるかどうかを判断することが困難です。コンテンツの更新時にすべての関連ページが無効化されるようにするには、すべての HTML ページを自動的に無効化します。以下の設定は、すべての HTML ページを無効化します。
  /invalidate
  {
   /0000  { /glob "*" /type "deny" }
   /0001  { /glob "*.html" /type "allow" }
  }

glob プロパティについて詳しくは、 glob プロパティのパターンのデザイン を参照してください。
この設定によって、/content/geometrixx/en.html ファイルがアクティベートされると、以下のアクティビティが発生します。
  • パターン en.* を持つすべてのファイルが /content/geometrixx/ フォルダーから削除されます。
  • /content/geometrixx/jp/_jcr_content フォルダーが削除されます。
  • /invalidate 設定に一致するその他すべてのファイルは、即座には削除されません。これらのファイルは、次回の要求が発生すると削除されます。この例では、/content/geometrixx.html は削除されません。/content/geometrixx.html が要求されると、削除されます。
自動生成した PDF や ZIP ファイルをダウンロード用に提供する場合は、これらのファイルも自動的に無効化する必要があります。この場合の設定例を次に示します。
/invalidate
  {
   /0000 { /glob "*" /type "deny" }
   /0001 { /glob "*.html" /type "allow" }
   /0002 { /glob "*.zip" /type "allow" }
   /0003 { /glob "*.pdf" /type "allow" }
  }

Adobe Analytics との AEM 統合によって、Web サイトの analytics.sitecatalyst.js ファイルに設定データが提供されます。Dispatcher に付属のサンプルの dispatcher.any ファイルには、このファイル用として次の無効化ルールが含まれています。
{
   /glob "*/analytics.sitecatalyst.js"  /type "allow"
}

カスタム無効化スクリプトの使用

/invalidateHandler プロパティを使用して、Dispatcher が無効化要求を受信するたびに呼び出されるスクリプトを定義できます。
このスクリプトは、以下の引数と共に呼び出されます。
  • 取り扱い 無効化するコンテンツのパス
  • アクション レプリケーションアクション(Activate、Deactivate)
  • Action Scope レプリケーションアクションの範囲(ヘッダー CQ-Action-Scope: ResourceOnly が送信されない限りは空です。詳しくは、「 AEM からキャッシュされたページの無効化 」を参照してください)。
このスクリプトは、他のアプリケーションに固有のキャッシュの無効化など、多種多様なユースケースを扱ったり、外部化されたページの URL とドキュメントルート内のその場所がコンテンツパスと一致しないケースを扱ったりするのに利用できます。
以下のサンプルスクリプトは、各無効化要求をファイルに記録します。
/invalidateHandler "/opt/dispatcher/scripts/invalidate.sh"

サンプルの無効化ハンドラースクリプト

#!/bin/bash

printf "%-15s: %s %s" $1 $2 $3>> /opt/dispatcher/logs/invalidate.log

キャッシュをフラッシュできるクライアントの制限

/allowedClients プロパティは、キャッシュのフラッシュを許可する特定のクライアントを定義されます。このグロビングパターンが、IP と照合されます。
以下の例の内容は次のとおりです。
  1. 任意のクライアントへのアクセスを拒否
  2. localhost へのアクセスを明示的に許可
/allowedClients
  {
   /0001 { /glob "*.*.*.*"  /type "deny" }
   /0002 { /glob "127.0.0.1" /type "allow" }
  }

glob プロパティについて詳しくは、 glob プロパティのパターンのデザイン を参照してください。
/allowedClients を定義することをお勧めします。
定義しない場合は、任意のクライアントからキャッシュ消去を呼び出せますが、繰り返しおこなうとサイトのパフォーマンスに深刻な影響を及ぼす場合があります。

URL パラメーターの無視

ignoreUrlParams セクションでは、ページをキャッシュするかキャッシュから提供するかを判断するときにどの URL パラメーターを無視するかを定義します。
  • 要求 URL に含まれるすべてのパラメーターを無視する場合は、ページがキャッシュされます。
  • 要求 URL に含まれる 1 つ以上のパラメーターを無視しない場合は、ページはキャッシュされません。
あるページに対してパラメーターを無視する場合は、そのページが初めて要求されたときにページがキャッシュされます。そのページに対する以降の要求には、要求内のパラメーターの値にかかわらず、キャッシュされたページが返されます。
無視するパラメーターを指定するには、 ignoreUrlParams プロパティに glob ルールを追加します。
  • パラメーターを無視するには、そのパラメーターを許可する glob プロパティを作成します。
  • ページがキャッシュされないようにするには、そのパラメーターを拒否する glob プロパティを作成します。
次の例では、Dispatcher が "q" パラメーターを無視するので、q パラメーターを含む要求 URL はキャッシュされます。
/ignoreUrlParams
{
    /0001 { /glob "*" /type "deny" }
    /0002 { /glob "q" /type "allow" }
}

例の ignoreUrlParams 値を使用すると、 q パラメーターは無視されるので、次の HTTP 要求によってページがキャッシュされます。
GET /mypage.html?q=5

例の ignoreUrlParams 値を使用すると、 p パラメーターは無視されないので、次の HTTP 要求によってページがキャッシュされません。
GET /mypage.html?q=5&p=4

glob プロパティについて詳しくは、 glob プロパティのパターンのデザイン を参照してください。

HTTP 応答ヘッダーのキャッシュ

この機能は、Dispatcher のバージョン 4.1.11 で利用できます。
/headers プロパティを使用して、Dispatcher がキャッシュする HTTP ヘッダータイプを定義できます。キャッシュされていないリソースへの最初のリクエストでは、設定済みの値(以下の設定サンプルを参照)のいずれかに一致するすべてのヘッダーが、キャッシュファイルの隣の別ファイルに格納されます。キャッシュされたリソースに対する後続のリクエストでは、保存されたヘッダーが応答に追加されます。
以下に、デフォルト設定のサンプルを示します。
/cache {
  ...
  /headers {
    "Cache-Control"
    "Content-Disposition"
    "Content-Type"
    "Expires"
    "Last-Modified"
    "X-Content-Type-Options"
    "Last-Modified"
  }
}

また、ファイルのグロビング文字は使用できません。詳しくは、 glob プロパティのパターンのデザイン を参照してください。
Dispatcher を使用して AEMから ETag 応答ヘッダーを保存および配信する必要がある場合は、以下の手順を実行します。
  • /cache/headers セクションにヘッダー名を追加します。
  • Add the following Apache directive in the Dispatcher related section:
FileETag none

Dispatcher キャッシュファイルの権限

mode プロパティは、新しいディレクトリおよびキャッシュ内のファイルに適用されるファイル権限を指定します。この設定は、呼び出し元のプロセスの umask によって制限されます。これは、次の値のうち 1 つまたは複数の合計から構成される 8 進数です。
  • 0400 所有者による読み取りを許可します。
  • 0200 所有者による書き込みを許可します。
  • 0100 所有者によるディレクトリ内の検索を許可します。
  • 0040 グループメンバーによる読み取りを許可します。
  • 0020 グループメンバーによる書き込みを許可します。
  • 0010 グループメンバーによるディレクトリ内の検索を許可します。
  • 0004 その他のユーザーによる読み取りを許可します。
  • 0002 その他のユーザーによる書き込みを許可します。
  • 0001 その他のユーザーによるディレクトリ内の検索を許可します。
デフォルト値は 0755 で、所有者は読み取り、書き込みまたは検索をおこない、グループおよびその他のユーザーは読み取りまたは検索をおこなうことができます。

. stat ファイルの更新のスロットリング

デフォルトの /invalidate のプロパティでは、アクティベーションごとに、すべての .html ファイルが無効化されます(パスが /invalidate セクションに一致する場合)。トラフィック量が多い Web サイトでは、複数回のアクティベーションによってバックエンドの CPU 負荷が増加します。このようなシナリオでは、Web サイトをレスポンシブに維持するために、「スロットル」 .stat ファイルを使用することをお勧めします。これを行うには、 /gracePeriod プロパティを使用します。
/gracePeriod プロパティは、自動的に無効化された古いリソースを、前回のアクティベーション後にキャッシュから引き続き使用できる秒数を定義します。このプロパティは、アクティベートのバッチによってキャッシュ全体が繰り返し無効化されるような設定で使用できます。推奨される値は 2 秒です。
詳細については、上記の /invalidate および /statfileslevel セクションも参照してください。

時間に基づくキャッシュの無効化の設定 - /enableTTL

設定した場合、 /enableTTL プロパティはバックエンドからの応答ヘッダーを評価し、 Cache-Control max-age または Expires 日付が含まれる場合は、有効期限と同じ変更時刻を持つ予備の空のファイルがキャッシュファイルの隣に作成されます。変更時刻以降にキャッシュされたファイルが要求されると、自動的にバックエンドから再要求されます。
この機能は、Dispatcherのバージ ョン4.1.11 以降で使用できます。

ロードバランシングの設定 - /statistics

/statistics セクションは、Dispatcher が各レンダーの応答性のスコアを付けるファイルのカテゴリを定義します。Dispatcher は、このスコアを使用して、要求を送信するレンダーを決定します。
作成したカテゴリごとに glob パターンを定義します。Dispatcher は、要求されたコンテンツの URI とこれらのパターンを比較して、要求されたコンテンツのカテゴリを決定します。
  • カテゴリの順序によって、URI と比較する順序が決まります。
  • URI と一致する最初のカテゴリパターンがファイルのカテゴリになります。それ以上のカテゴリパターンは評価されません。
Dispatcher は、最大 8 個の統計カテゴリをサポートします。9 個以上のカテゴリを定義した場合は、最初の 8 個のカテゴリのみが使用されます。
レンダーの選択
レンダリングされたページを要求するたびに、Dispatcher は以下のアルゴリズムを使用してレンダーを選択します。
  1. 要求の renderid cookie にレンダー名が格納されている場合、Dispatcher はそのレンダーを使用します。
  2. 要求に renderid cookie が含まれていない場合、Dispatcher はレンダー統計を比較します。
    1. Dispatcher は、要求 URI のカテゴリを判断します。
    2. Dispatcher は、そのカテゴリで最も応答スコアが低いレンダーを判断して、そのレンダーを選択します。
  3. まだレンダーが選択されていない場合は、リストの先頭のレンダーを使用します。
レンダーのカテゴリのスコアは、以前の応答時間と Dispatcher が以前試みた接続の失敗および成功に基づきます。試行ごとに、要求された URI のカテゴリのスコアが更新されます。
ロードバランシングを使用しない場合は、このセクションを省略できます。

統計カテゴリの定義

レンダーを選択するための統計を保持するドキュメントのタイプごとにカテゴリを定義します。/statistics セクションには、/categories セクションが含まれます。カテゴリを定義するには、/categories セクションの下に次の形式の行を追加します。
/name { /glob "pattern"}
カテゴリ name は、ファームに対して一意である必要があります。 pattern については、 glob プロパティのパターンのデザイン のセクションで説明します。
URI のカテゴリを判断するために、Dispatcher は一致が見つかるまで URI と各カテゴリのパターンを比較します。Dispatcher は、リストの先頭のカテゴリから始め、順序に従って比較を続けます。したがって、より具体的なパターンを持つカテゴリを先頭に配置してください。
例えば、Dispatcher のデフォルトの dispatcher.any ファイルには、1 つの HTML カテゴリと 1 つの others カテゴリが定義されています。HTML カテゴリのほうが具体的なので、先頭に配置されています。
/statistics
  {
  /categories
    {
      /html { /glob "*.html" }
      /others  { /glob "*" }
    }
  }

以下の例には、検索ページ用のカテゴリも含まれています。
/statistics
  {
  /categories
    {
      /search { /glob "*search.html" }
      /html { /glob "*.html" }
      /others  { /glob "*" }
    }
  }

Dispatcher 統計へのサーバー使用不可能状態の反映

/unavailablePenalty プロパティは、レンダーへの接続が失敗した場合にレンダー統計に適用される時間(0.1 秒単位)を設定します。Dispatcher は、要求された URI に一致する統計カテゴリにこの時間を追加します。
例えば、AEM が実行されていない(したがってリッスンしていない)か、ネットワーク関連の問題が発生したので、指定したホスト名およびポートへの TCP/IP 接続を確立できない場合にペナルティが適用されます。
/unavailablePenalty プロパティは、 /farm セクション( /statistics セクションの兄弟)の直接の子です。
/unavailablePenalty プロパティが存在しない場合は、値 "1" が使用されます。
/unavailablePenalty "1"

スティッキー接続フォルダーの識別 - /stickyConnectionsFor

/stickyConnectionsFor プロパティは、スティッキードキュメントを格納する 1 つのフォルダーを定義します。このフォルダーには、URL を使用してアクセスします。Dispatcher によって、このフォルダーにある、単一のユーザーからのすべての要求が同一のレンダーインスタンスに送信されます。スティッキー接続は、すべてのドキュメントに必ず一貫したセッションデータが存在することを保証します。このメカニズムは、 renderid cookie を利用しています。
次の例は、/products フォルダーへのスティッキー接続を定義しています。
/stickyConnectionsFor "/products"

ページが複数のコンテンツノードのコンテンツで組み立てられている場合は、コンテンツへのパスをリストする /paths プロパティを含めます。例えば、 /content/image /content/video および /var/files/pdfs のコンテンツを含むページがあるとします。以下の設定を使用すると、ページ上のすべてのコンテンツに対してスティッキー接続が有効になります。
/stickyConnections {
  /paths {
    "/content/image"
    "/content/video"
    "/var/files/pdfs"
  }
}

httpOnly

スティッキー接続が有効になっている場合、dispatcher モジュールは renderid cookie を設定します。この cookie には httponly フラグがないため、セキュリティを強化するためにこのフラグを追加する必要があります。これをおこなうには、 httpOnly 設定ファイルの /stickyConnections ノードで dispatcher.any プロパティを設定します。プロパティの値(0または1)は、 renderid cookie に HttpOnly 属性を追加するかどうかを定義します。デフォルト値は 0 (属性は追加されない)です。
For additional information about the httponly flag, read this page .

secure

スティッキー接続が有効になっている場合、dispatcher モジュールは renderid cookie を設定します。この cookie には secure フラグがないため、セキュリティを強化するためにこのフラグを追加する必要があります。これをおこなうには、 secure 設定ファイルの /stickyConnections ノードで dispatcher.any プロパティを設定します。プロパティの値(0または1)は、 renderid cookie に secure 属性を追加するかどうかを定義します。The default value is 0, which means the attribute will be added if the incoming request is secure. 値が 1 に設定されている場合、受信リクエストがセキュリティ保護されているかどうかに関係なく、secure フラグが追加されます。

レンダー接続エラーの処理

レンダーサーバーが 500 エラー、すなわち使用不可を返した場合の Dispatcher の動作を設定します。

ヘルスチェックページの指定

/health_check プロパティを使用して、ステータスコード 500 が発生したときに確認する URL を指定します。このページもステータスコード 500 を返す場合、インスタンスは使用不可能と見なされ、再試行の前に設定可能なタイムペナルティ( /unavailablePenalty )がレンダーに適用されます。
/health_check
  {
  # Page gets contacted when an instance returns a 500
  /url "/health_check.html"
  }

ページ再試行遅延の指定

/ retryDelay プロパティは、Dispatcher が待機する、ファームレンダーへの接続試行周期(秒単位)を設定します。周期ごとに、Dispatcher が 1 つのレンダーに対して接続を試行する最大回数は、ファーム内のレンダーの数です。
/retryDelay が明示的に定義されていない場合、Dispatcher は値 "1" を使用します。デフォルト値は、ほとんどのケースに適しています。
/retryDelay "1"

再試行回数の設定

/numberOfRetries プロパティは、Dispatcher がレンダーに対して実行する。接続試行周期の最大回数を設定します。この再試行回数内で Dispatcher がレンダーに接続できなかった場合、Dispatcher は失敗応答を返します。
周期ごとに、Dispatcher が 1 つのレンダーに対して接続を試行する最大回数は、ファーム内のレンダーの数です。したがって、Dispatcher が接続を試みる最大回数は( /numberOfRetries )x(レンダー数)になります。
明示的な定義がない場合、 5 がデフォルトの値として使用されます。
/numberOfRetries "5"

フェイルオーバーメカニズムの使用

Dispatcher ファーム上でフェイルオーバーメカニズムを有効にして、元の要求の失敗時に異なるレンダーに要求を再送信します。フェイルオーバーを有効にすると、Dispatcher は以下の動作をおこないます。
  • レンダーへの要求が HTTP ステータス 503(UNAVAILABLE)を返した場合、Dispatcher は異なるレンダーに要求を送信します。
  • レンダーへの要求が HTTP ステータス 50x(503 以外)を返した場合、Dispatcher は health_check プロパティに設定されているページへの要求を送信します。
    • ヘルスチェックが 500(INTERNAL_SERVER_ERROR)を返した場合、Dispatcher は元の要求を異なるレンダーに送信します。
    • ヘルスチェックが HTTP ステータス 200 を返した場合、Dispatcher は最初の HTTP 500 エラーをクライアントに返します。
フェイルオーバーを有効にするには、次の行をファーム(または Web サイト)に追加します。
/failover "1" 

本文を含む HTTP 要求を再試行するには、Dispatcher が Expect: 100-continue 要求ヘッダーをレンダーに送信してから、実際のコンテンツをスプールします。すると、CQSE を含む CQ 5.5 が、100(CONTINUE)またはエラーコードで即座に応答します。その他のサーブレットコンテナも、このメカニズムをサポートする必要があります。

中断エラーの無視 - /ignoreEINTR

このオプションは、通常は必要ありません。このオプションを使用する必要があるのは、次のログメッセージが表示された場合だけです。
Error while reading response: Interrupted system call
システムコールの対象が NFS 経由でアクセスするリモートシステム上にある場合、ファイルシステムからのシステムコールはすべて EINTR で中断される可能性があります。これらのシステムコールがタイムアウトするか中断されるかは、基盤となるファイルシステムがローカルマシンにどのようにマウントされたかに基づきます。
インスタンスにそのような設定があり、ログに次のメッセージが含まれる場合は、/ignoreEINTR パラメーターを使用してください。
Error while reading response: Interrupted system call
内部的に、Dispatcher は次のように表現できるループを使用して、リモートサーバー(AEM)からの応答を読み込みます。
while (response not finished) { read more data }
このようなメッセージは、「 EINTR 」セクションで read more data が発生した場合に生成されることがあります。原因は、データの受信前にシグナルを受信したことです。
このような中断を無視するには、次のパラメーターを dispatcher.any /farms の前)に追加します。
/ignoreEINTR "1"
/ignoreEINTR "1" に設定すると、Dispatcher は応答全体が読み込まれるまでデータの読み込みを続行します。デフォルト値は 0 で、このオプションを無効にします。

glob プロパティのパターンのデザイン

Dispatcher 設定ファイルのいくつかのセクションでは、 glob プロパティをクライアント要求の選択条件として使用します。glob プロパティの値は、要求されたリソースのパスやクライアントの IP アドレスなど、Dispatcher が要求の要素と比較するパターンです。例えば、 /filter セクションのアイテムは、glob パターンを使用して、Dispatcher が従う、または拒否するページのパスを識別します。
glob の値にワイルドカード文字と英数字を含めて、パターンを定義することができます。
ワイルドカード文字
説明
*
文字列に含まれる任意の文字の 0 個以上の連続するインスタンスに一致します。一致の最後の文字は、次のどちらかの状況によって判断されます。
文字列内のある文字がパターン内の次の文字に一致し、パターンの文字が以下の性質を持つ。
  • * 以外
  • ? 以外
  • リテラル文字(空白を含む)または文字クラス。
  • パターンの終わりに達している。
文字クラス内のこの文字は、リテラルとして解釈されます。
*/geo* /content/geometrixx ノードと /content/geometrixx-outdoors ノードの下にあるすべてのページに一致します。以下の HTTP 要求は、glob パターンに一致します。
  • "GET /content/geometrixx/en.html"
  • "GET /content/geometrixx-outdoors/en.html"
*outdoors/*
/content/geometrixx-outdoors ノードの下にあるすべてのページに一致します。例えば、次の HTTP 要求は glob パターンに一致します。
  • "GET /content/geometrixx-outdoors/en.html"
?
任意の 1 文字に一致します。文字クラス外で使用します。文字クラス内のこの文字は、リテラルとして解釈されます。
*outdoors/??/*
geometrixx-outdoors サイトのすべての言語のページに一致します。例えば、次の HTTP 要求は glob パターンに一致します。
  • "GET /content/geometrixx-outdoors/en/men.html"
次の要求は glob パターンに一致しません。
  • "GET /content/geometrixx-outdoors/en.html"
[ and ]
文字クラスの最初と最後を定めます。文字クラスには、1 つまたは複数の文字範囲および単一の文字を含めることができます。
ターゲット文字が文字クラス内または定義されている範囲内のいずれかの文字に一致する場合、一致が発生します。
閉じ角括弧が含まれない場合、パターンによって一致は発生しません。
*[o]men.html*
次の HTTP 要求に一致します。
  • "GET /content/geometrixx-outdoors/en/women.html"
次の HTTP 要求に一致しません。
  • "GET /content/geometrixx-outdoors/en/men.html"
*[o/]men.html*
次の HTTP 要求に一致します。
  • "GET /content/geometrixx-outdoors/en/women.html"
  • "GET /content/geometrixx-outdoors/en/men.html"
-
文字の範囲を定めます。文字クラス内で使用します。文字クラス外のこの文字は、リテラルとして解釈されます。
*[m-p]men.html* 次の HTTP 要求に一致します。
  • "GET /content/geometrixx-outdoors/en/women.html"
次の HTTP 要求に一致しません。
  • "GET /content/geometrixx-outdoors/en/men.html"
!
続く文字または文字クラスを打ち消します。文字クラス内の文字および文字範囲の打ち消しにのみ使用してください。ワイルドカード文字 ^ wildcard .
文字クラス外のこの文字は、リテラルとして解釈されます。
*[!o]men.html*
次の HTTP 要求に一致します。
  • "GET /content/geometrixx-outdoors/en/men.html"
次の HTTP 要求に一致しません。
  • "GET /content/geometrixx-outdoors/en/women.html"
*[!o!/]men.html*
次の HTTP 要求に一致しません。
  • "GET /content/geometrixx-outdoors/en/women.html" または "GET /content/geometrixx-outdoors/en/men. html"
^
続く文字または文字範囲を打ち消します。文字クラス内の文字および文字範囲の打ち消しにのみ使用してください。 ! ワイルドカードに相当します。
文字クラス外のこの文字は、リテラルとして解釈されます。
ワイルドカード文字 ! の例と同様、サンプルパターンの文字 ! が 文字 ^ に置き換えられます。

ログ

Web サーバー設定で、次の属性を設定できます。
  • Dispatcher ログファイルの場所.
  • ログレベル。
詳しくは、Web サーバーのドキュメント、および使用する Dispatcher インスタンスの readme ファイルを参照してください。
Apache の交替されるログ/パイプ経由のログ
Apache Web サーバーを使用している場合、交替されるログ(パイプ経由のログ)の標準的な機能を使用できます。例えば、次のようにパイプ経由のログを使用できます。
DispatcherLog "| /usr/apache/bin/rotatelogs logs/dispatcher.log%Y%m%d 604800"
この設定により、ログが自動的に次のように交替されます。
  • Dispatcher ログファイルの拡張子にタイムスタンプ(logs/dispatcher.log%Y%m%d)が付きます。
  • 週単位(60 x 60 x 24 x 7 = 604800 秒)で交替されます。
ログの交替やパイプ経由のログについては、Apache Web サーバーのドキュメント( Apache 2.4 など)を参照してください。
インストール時のデフォルトのログレベルは高(レベル 3 = デバッグ)なので、Dispatcher ですべてのエラーおよび警告がログに記録されます。このログレベルは、初期の段階では非常に便利です。
ただし、追加のリソースが必要となるので、Dispatcher が現在の要件で円滑に動作している場合は、ログレベルを低くしてください。**

トレースログ

Dispatcher の機能強化の中で、バージョン 4.2.0 ではトレースログも導入されています。
トレースログはデバッグログよりレベルが高く、ログに追加情報が表示されます。以下に関するログが追加されます。
  • 転送されたヘッダーの値
  • 特定のアクションに対して適用されるルール
Web サーバーでログレベルを 4 に設定して、トレースログを有効にすることができます。
トレースを有効にしたログの例を以下に示します。
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[Host] = "localhost:8443"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[User-Agent] = "curl/7.43.0"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[Accept] = "*/*"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[X-Forwarded-SSL-Client-Cert] = "(null)"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[Via] = "1.1 localhost:8443 (dispatcher)"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[X-Forwarded-For] = "::1"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[X-Forwarded-SSL] = "on"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[X-Forwarded-SSL-Cipher] = "DHE-RSA-AES256-SHA"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[X-Forwarded-SSL-Session-ID] = "ba931f5e4925c2dde572d766fdd436375e15a0fd24577b91f4a4d51232a934ae"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[X-Forwarded-Port] = "8443"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[Server-Agent] = "Communique-Dispatcher"

ブロックルールに一致するファイルが要求されると、イベントがログに記録されます。
[Thu Mar 03 14:42:45 2016] [T] [11831] 'GET /content.infinity.json HTTP/1.1' was blocked because of /0082

基本操作の確認

Web サーバー、Dispatcher および AEM インスタンスの基本の操作とやり取りを確認するには、次の手順を実行します。
  1. loglevel 3 .に設定します。
  2. Web サーバーを起動します。これに伴い、Dispatcher も起動します。
  3. AEM インスタンスを起動します。
  4. Web サーバーと Dispatcher のログファイルおよびエラーファイルを確認します。 Web サーバーによっては、次のようなメッセージが表示されます。 [Thu May 30 05:16:36 2002] [notice] Apache/2.0.50 (Unix) configured および: [Fri Jan 19 17:22:16 2001] [I] [19096] Dispatcher initialized (build XXXX)
  5. Web サーバー経由で Web サイトにアクセスします。コンテンツが要求どおりに表示されていることを確認します。 例えば、AEM がポート 4502 で、Web サーバーがポート 80 で実行されているローカルインストール上で、以下の両方を使用して Web サイトコンソールにアクセスします。 https://localhost:4502/libs/wcm/core/content/siteadmin.html https://localhost:80/libs/wcm/core/content/siteadmin.html 結果は同じになるはずです。同じ方法で、他のページへのアクセスも確認します。
  6. キャッシュディレクトリがいっぱいになっていることを確認します。
  7. ページをアクティベートし、キャッシュが正常にフラッシュされるかを確認します。
  8. すべて適切に動作している場合は、 loglevel を再び 0 に設定します。

複数の Dispatcher の使用

複雑な設定をおこなう場合は、複数の Dispatcher を使用できます。例えば、次のように使用できます。
  • 1 つ目の Dispatcher を、イントラネット上での Web サイトの公開に使用
  • 2 つ目の Dispatcher を、異なるアドレスと異なるセキュリティ設定で、インターネット上での同じコンテンツの公開に使用
この場合、各要求が経由する Dispatcher は 1 つだけにしてください。別の Dispatcher から渡された要求は処理されません。したがって、どちらの Dispatcher も AEM Web サイトに直接アクセスするようにしてください。

デバッグ

ヘッダー X-Dispatcher-Info を リクエスト に追加する場合、Dispatcher は、ターゲットがキャッシュされたか、キャッシュから返されたか、またはキャッシュ不可能であるかを返します。応答ヘッダー X-Cache-Info には、この情報が読み取り可能な形式で格納されます。これらの応答ヘッダーを使用して、Dispatcher によってキャッシュされた応答に関する問題をデバッグできます。
この機能はデフォルトで有効になっていないため、応答ヘッダー X-Cache-Info を含めるには、ファームに次のエントリが含まれている必要があります。
/info "1"

以下に例を挙げます。
/farm
{
    /mywebsite
    {
        # Include X-Cache-Info response header if X-Dispatcher-Info is in request header
        /info "1"
    }
}

また、 X-Dispatcher-Info ヘッダーに値は必要ありませんが、テストに curl を使用する場合は、ヘッダーを送信するために次のような値を指定する必要があります。
curl -v -H "X-Dispatcher-Info: true" https://localhost/content/we-retail/us/en.html

以下は、 X-Dispatcher-Info によって返される応答ヘッダーの一覧です。
  • cached ターゲットファイルはキャッシュに含まれており、Dispatcher は配信することが有効であるとを判断しました。
  • caching ターゲットファイルはキャッシュに含まれていないので、Dispatcher は出力をキャッシュして配信することが有効であると判断しました。
  • caching: stat file is more recent ターゲットファイルはキャッシュに含まれていますが、より新しい .stat ファイルによって無効化されます。Dispatcher はターゲットファイルを削除し、出力から再作成して配信します。
  • not cacheable: no document root ファームの設定にドキュメントルート(設定要素 cache.docroot )が含まれていません。
  • not cacheable: cache file path too long ターゲットファイル(ドキュメントルートと URL ファイルが連結されたものが)が、システム上で使用可能な最長ファイル名を超えています。
  • not cacheable: temporary file path too long 一時ファイル名テンプレートが、システムで使用可能な最長ファイル名を超えています。Dispatcher は、キャッシュされたファイルを作成または上書きする前に、まず一時ファイルを作成します。一時ファイル名は、ターゲットファイル名に文字 _YYYYXXXXXX が追加サれた名前です。 Y X が置き換えられ、一意の名前が作成されます。
  • not cacheable: request URL has no extension リクエスト URL に拡張子がないか、ファイル拡張子の後にパスがあります(例: /test.html/a/path )。
  • not cacheable: request wasn't a GET or HEAD HTTP メソッドが GET でも HEAD でもありません。Dispatcher は、出力にキャッシュするべきではない動的データが含まれていると想定します。
  • not cacheable: request contained a query string リクエストにクエリ文字列が含まれていました。Dispatcherは、出力が与えられたクエリ文字列に依存しているため、キャッシュされないと想定します。
  • not cacheable: session manager didn't authenticate ファームのキャッシュはセッションマネージャーによって管理され(設定に sessionmanagement ノードが含まれている)、リクエストに適切な認証情報が含まれていません。
  • not cacheable: request contains authorization ファームはキャッシュの出力( allowAuthorized 0 )が許可されておらず、リクエストに認証情報が含まれている。
  • not cacheable: target is a directory ターゲットファイルがディレクトリです。これは、URL と一部の サブURL の両方にキャッシュ可能な出力が含まれているなど、概念的な誤りを示している可能性があります。例えば、 /test.html/a/file.ext への要求が最初におこなわれ、その要求にキャッシュ可能な出力が含まれていると、Dispatcher は /test.html への後続の要求の出力をキャッシュできなくなります。
  • not cacheable: request URL has a trailing slash リクエスト URL の末尾にスラッシュが使用されています。
  • not cacheable: request URL not in cache rules このファームのキャッシュルールは、一部のリクエスト URL の出力をキャッシュすることを明示的に拒否しています。
  • not cacheable: authorization checker denied access ファームの認証チェッカーがキャッシュされたファイルへのアクセスを拒否しました。
  • not cacheable: session not valid ファームのキャッシュがセッションマネージャーによって管理され(設定に sessionmanagement ノードが含まれている)、ユーザーセッションが無効であるか、有効でなくなっています。
  • not cacheable: response contains no_cache ​リモートサーバーが Dispatcher: no_cache ヘッダーを返し、Dispatcher による出力のキャッシュが禁止されています。
  • not cacheable: response content length is zero 応答のコンテンツ長がゼロになっています。Dispatcher では、長さゼロのファイルは作成されません。