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
   {
      ...
   }
}

各ファームプロパティには、以下の子プロパティを含めることができます。

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

通過させる 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"
  "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][*]

• scheme：（オプション） https:// または https://.
• host：ホストコンピューターの名前または IP アドレスと、必要な場合はポート番号( https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.23)
• 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 値がない場合は、最上位ファームの最上位の仮想ホストを使用します。

したがって、デフォルトの仮想ホストは ファイルの最上位ファームの virtualhosts プロパティの一番上に配置する必要があります。dispatcher.any

仮想ホストの解決の例

次の例は、 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 要求がどの仮想ホストへと解決されるかを示しています。

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

レンダーファームにアクセスするためのセキュアセッションを作成して、このファーム内のページにユーザーがアクセスする際にログインが必要になるようにします。ログイン後、ユーザーはファーム内のページにアクセスできます。閉じられたユーザーグループ（CUG）でのこの機能の使用については、閉じられたユーザーグループの作成を参照してください。また、運用を開始する前に、Dispatcher のセキュリティチェックリストを参照してください。

/sessionmanagement プロパティは /farms のサブプロパティです。

/sessionmanagement には、いくつかのサブパラメーターがあります。

/directory（必須）

セッション情報を格納するディレクトリ。ディレクトリが存在しない場合は自動的に作成されます。

/sessionmanagement
  {
  /directory "/usr/local/apache/.sessions"
  }

/encode（オプション）

セッション情報のエンコード方法。用途 md5 md5 アルゴリズムを使用した暗号化、または hex を 16 進数エンコーディング用に作成します。 セッションデータを暗号化すると、ファイルシステムにアクセスできるユーザーでも、セッション内容を読み取れなくなります。デフォルトは、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 セクションの例では、Dispatcher と同じコンピューター上で動作する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 接続を確立するまで、そのアドレスのリストを繰り返します。したがって、 ipv4 プロパティは、レンダーホスト名が、 getaddrinfo 関数を使用すると、常に同じ順序の IP アドレスのリストを返します。 この場合、 gethostbyname 関数を使用して、Dispatcher が接続する IP アドレスがランダム化されるようにします。

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 に対する要求は常に拒否されます。

この /filter セクションは、HTTP 要求の要求行部分のパターンに従ってコンテンツへのアクセスを拒否または許可する一連のルールで構成されます。 の許可リスト戦略を /filter セクション：

• まず、すべての要素へのアクセスを拒否します。
• 必要に応じて、コンテンツへのアクセスを許可します。

フィルターの定義

/filter の各アイテムには、要求行の特定の要素または要求行全体と照合するタイプとパターンが含まれます。各フィルターには、次のアイテムを含めることができます。

• タイプ：/type は、パターンに一致する要求へのアクセスを許可するか、拒否するかを示します。値は、allowまたは deny のどちらかです。

• 要求行の要素：/query、/method、/url または /protocol と、HTTP 要求の要求行の特定部分に応じて要求をフィルタリングするためのパターンを含めます。要求行全体ではなく、要求行の要素に対してフィルタリングすることをお勧めします。

• 要求行の高度な要素： Dispatcher 4.2.0 から 4 つの新しいフィルター要素を使用できます。/path、/selectors、/extension、/suffix の各要素です。これらを 1 つ以上含めると、URL パターンをさらに制御することができます。

• glob プロパティ： HTTP 要求の要求行全体と照合するには、/glob プロパティを使用します。

HTTP 要求の要求行部分

HTTP/1.1 では リクエストライン 次のように指定します。

Method Request-URI HTTP-Version<CRLF>

この <CRLF> 文字は、キャリッジリターンとそれに続くラインフィードを表します。 次の例は、クライアントが WKND サイトの US-English ページをリクエストしたときに受け取るリクエスト行です。

GET /content/wknd/us/en.html HTTP.1.1<CRLF>

パターンでは、要求行と <CRLF> 文字。

二重引用符と一重引用符

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

正規表現

4.2.0 より後のバージョンの Dispatcher では、フィルターパターンに POSIX 拡張正規表現を含めることができます。

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

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

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

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

/0001  { /type "deny" /url "*"  }

明示的に拒否された領域への要求に対して、「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*"   }

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

このフィルターは、ここで単一引用符の間に定義されている正規表現を使用して、非公開のコンテンツディレクトリで拡張子を有効にします。

/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|sysview|docview|query|jcr:content|_jcr_content|search|childrenlist|ext|assets|assetsearch|[0-9-]+)'
        /extension '(json|xml|html|feed))'
        }

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

Dispatcher を設定する際は、できる限り外部アクセスを制限してください。次の例では、外部の訪問者に最小限のアクセス権を付与します。

• /content

• デザインなどのその他のコンテンツおよびクライアントライブラリ。次のようなものがあります。

  • /etc/designs/default*
  • /etc/designs/mydesign*

フィルターを作成したら、ページアクセスをテストして、AEM インスタンスがセキュアであることを確認します。

以下 /filter セクション dispatcher.any ファイルを Dispatcher 設定ファイル。

このサンプルは、Dispatcher に付属するデフォルトの設定ファイルをベースとしており、実稼動環境での使用例の役割を果たすことを目的としています。プレフィックスが付いた項目 # を非アクティブ化（コメントアウト）した場合、次のいずれかをアクティブ化する ( # を参照してください )。セキュリティ上の影響を受ける可能性があります。

すべてに対するアクセスを拒否してから、特定の（限られた）要素へのアクセスを許可してください。

  /filter
      {
      # Deny everything first and then allow specific entries
      /0001  { /type "deny" /url "*"  }

      # 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
}

アクセスを拡張する場合は、以下の推奨事項について検討します。

• CQ バージョン 5.4 以前を使用している場合は、/admin への外部アクセスを常に完全に​**​無効にしてください。

• /libs 内にあるファイルへのアクセスを許可する場合は、注意が必要です。アクセスは、個別に許可する必要があります。

• レプリケーション複製の設定が表示されないよう、この設定へのアクセスを拒否してください。

  • /etc/replication.xml*
  • /etc/replication.infinity.json*

• Google Gadgets のリバースプロキシへのアクセスを拒否します。

  • /libs/opensocial/proxy*

インストールによっては、/apps、/libs またはその他の場所（使用可能にする必要があります）の下に、追加のリソースが存在する場合があります。外部からアクセスされるリソースを判別するための方法として、access.log ファイルを使用することができます。

クエリ文字列の制約

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=*" }
}

/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]/(@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
• /welcome

端末またはコマンドプロンプトで次のコマンドを発行して、匿名での書き込みアクセスが可能かどうかを判断します。ノードにはデータを書き込みできません。

curl -X POST "https://anonymous:anonymous@hostname:port/content/usergenerated/mytestnode"

ターミナルまたはコマンドプロンプトで次のコマンドを発行して、Dispatcher キャッシュの無効化を試み、コード 403 応答を受け取ることを確認します。

curl -H "CQ-Handle: /content" -H "CQ-Path: /content" https://yourhostname/dispatcher/invalidate.cache

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

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 サービスの呼び出し間隔（秒単位）。

バニティー URL へのアクセスを有効にするには、以下の手順を実行します。

1. レンダーサービスがAEMインスタンスの場合、 com.adobe.granite.dispatcher.vanityurl.content パッケージをパブリッシュインスタンス上に作成します（上記の注意を参照）。
2. AEM または CQ ページ向けに設定したバニティー URL ごとに、/filter 設定がその URL を拒否していることを確認します。必要に応じて、この URL を拒否するフィルターを追加します。
3. /farms の下に /vanity_urls セクションを追加します。
4. Apache Web サーバーを再起動します。

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

シンジケーション要求は、通常、Dispatcher のみを対象としているので、デフォルトではレンダラー（AEM インスタンスなど）に送信されません。

必要に応じて、 /propagateSyndPost プロパティを "1" シンジケーション要求を Dispatcher に転送する。 設定する場合、フィルターセクションで 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 プロパティは、キャッシュされたファイルを保存するディレクトリを識別します。

複数のファームを使用する場合は、ファームごとに異なるドキュメントルートを使用する必要があります。

statfile の命名

/statfile プロパティは、statfile として使用するファイルを識別します。Dispatcher は、このファイルを使用して、最も新しいコンテンツ更新時刻を登録します。statfile には、Web サーバー上の任意のファイルを指定できます。

statfile にはコンテンツがありません。コンテンツが更新されると、Dispatcher がタイムスタンプを更新します。デフォルトの statfile の名前はです。 .stat とは docroot に保存されます。 Dispatcher は、statfile へのアクセスをブロックします。

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

/serveStaleOnError プロパティは、レンダーサーバーがエラーを返した場合に Dispatcher が無効になったドキュメントを返すかどうかを制御します。デフォルトでは、statfile にアクセスし、キャッシュされたコンテンツが無効になると、Dispatcher は次回要求時にキャッシュされたコンテンツを削除します。

If /serveStaleOnError が "1"に設定すると、レンダーサーバーが成功応答を返さない限り、Dispatcher は無効になったコンテンツをキャッシュから削除しません。 AEM からの応答 5xx または接続タイムアウトによって、Dispatcher は期限切れのコンテンツを返し、HTTP ステータス 111（再検証失敗）で応答します。

認証使用時のキャッシュ

/allowAuthorized プロパティは、以下のいずれかの認証情報を含む要求をキャッシュするかどうかを制御します。

• この authorization ヘッダー
• という名前の cookie authorization
• という名前の cookie login-token

デフォルトでは、この認証情報を含む要求はキャッシュされません。キャッシュされたドキュメントをクライアントに返す場合、認証は実行されないからです。この設定によって、Dispatcher は、必要な権限を持たないユーザーにキャッシュされたドキュメントを返さなくなります。

ただし、認証済みドキュメントのキャッシュが要件によって許可されている場合は、 /allowAuthorized を 1 に変更します。

/allowAuthorized "1"

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

/rules プロパティは、ドキュメントパスに応じてキャッシュされるドキュメントを制御します。/rules プロパティにかかわらず、Dispatcher は以下の状況にあるドキュメントをキャッシュしません。

• 要求 URI に疑問符 (?) をクリックします。

  • 疑問符は通常、キャッシュの必要がない、検索結果などの動的ページを指します。

• ファイル拡張子が不明の場合。

  • Web サーバーでドキュメントのタイプ（MIME タイプ）を判別するために、拡張子が必要です。

• 認証ヘッダー（設定可）が設定されている場合。。

• AEM インスタンスが以下のヘッダーで応答する場合。

  • no-cache
  • no-store
  • must-revalidate

各項目の /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" なので）。

リソースのみ 道に沿って 無効化されたファイルに影響を与えます。 次の例を考えて見ましょう。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 などには当てはまりません。

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

/invalidate プロパティは、コンテンツが更新されたときに自動的に無効化されるドキュメントを定義します。

自動無効化を使用する場合、Dispatcher はキャッシュされたファイルをコンテンツの更新後に削除しませんが、次回要求されたときにその有効性を確認します。自動無効化されない、キャッシュ内のドキュメントは、コンテンツの更新によって明示的に削除されるまでキャッシュに残ります。

自動無効化は通常、HTML ページに対して使用されます。多くの場合、HTML ページには他のページへのリンクが含まれるので、コンテンツの更新がページに影響を与えるかどうかを判断することが困難です。コンテンツの更新時にすべての関連ページが無効化されるようにするには、すべての HTML ページを自動的に無効化します。以下の設定は、すべての HTML ページを無効化します。

  /invalidate
  {
   /0000  { /glob "*" /type "deny" }
   /0001  { /glob "*.html" /type "allow" }
  }

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

この設定により、次のアクティビティが発生します。 /content/wknd/us/en 有効化済み：

• パターン en.*は /content/wknd/us フォルダー。
• この /content/wknd/us/en./_jcr_content フォルダーが削除されました。
• その他すべてのファイルで、 /invalidate 設定は直ちには削除されません。 これらのファイルは、次回の要求が発生すると削除されます。この例では /content/wknd.html が削除されていない場合、 /content/wknd.html がリクエストされました。

自動生成した PDF や ZIP ファイルをダウンロード用に提供する場合は、これらのファイルも自動的に無効化する必要があります。この場合の設定例を次に示します。

/invalidate
  {
   /0000 { /glob "*" /type "deny" }
   /0001 { /glob "*.html" /type "allow" }
   /0002 { /glob "*.zip" /type "allow" }
   /0003 { /glob "*.pdf" /type "allow" }
  }

AEMとAdobe Analyticsの統合により、 analytics.sitecatalyst.js ファイルを Web サイト内に配置する必要があります。 例 dispatcher.any Dispatcher で提供されるファイルには、このファイルに対して次の無効化ルールが含まれます。

{
   /glob "*/analytics.sitecatalyst.js"  /type "allow"
}

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

この /invalidateHandler プロパティを使用すると、Dispatcher が受信した無効化要求ごとに呼び出されるスクリプトを定義できます。

このスクリプトは、以下の引数と共に呼び出されます。

• ハンドル — 無効化されるコンテンツのパス
• アクション — レプリケーションアクション（アクティブ化、非アクティブ化など）
• 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 プロパティのパターンのデザインを参照してください。

URL パラメーターの無視

ignoreUrlParams セクションでは、ページをキャッシュするかキャッシュから提供するかを判断するときにどの URL パラメーターを無視するかを定義します。

• 要求 URL に含まれるすべてのパラメーターを無視する場合は、ページがキャッシュされます。
• 要求 URL に含まれる 1 つ以上のパラメーターを無視しない場合は、ページはキャッシュされません。

あるページに対してパラメーターを無視する場合は、そのページが初めて要求されたときにページがキャッシュされます。そのページに対する以降の要求には、要求内のパラメーターの値にかかわらず、キャッシュされたページが返されます。

無視するパラメーターを指定するには、ignoreUrlParams プロパティに glob ルールを追加します。

• URL パラメーターを含む要求にもかかわらずページをキャッシュするには、パラメーター（無視）を許可する glob プロパティを作成します。
• ページがキャッシュされないようにするには、このパラメーターを拒否する glob プロパティを作成します（無視します）。

次の例では、Dispatcher が、 nocache パラメーター。 したがって、 nocache パラメーターは、Dispatcher によってキャッシュされません。

/ignoreUrlParams
{
    # allow-the-url-parameter-nocache-to-bypass-dispatcher-on-every-request
    /0001 { /glob "nocache" /type "deny" }
    # all-other-url-parameters-are-ignored-by-dispatcher-and-requests-are-cached
    /0002 { /glob "*" /type "allow" }
}

のコンテキストでは、 ignoreUrlParams 上記の設定例では、次の HTTP 要求によって、ページがキャッシュされます。これは、 willbecached パラメーターは無視されます：

GET /mypage.html?willbecached=true

のコンテキストでは、 ignoreUrlParams 設定例では、次の HTTP 要求によってページが not キャッシュされるのは nocache パラメーターは無視されません：

GET /mypage.html?nocache=true
GET /mypage.html?nocache=true&willbecached=true

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

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

/headers プロパティを使用して、Dispatcher がキャッシュする HTTP ヘッダータイプを定義できます。キャッシュされていないリソースへの最初のリクエストでは、設定済みの値（以下の設定サンプルを参照）のいずれかに一致するすべてのヘッダーが、キャッシュファイルの隣の別ファイルに格納されます。キャッシュされたリソースに対する後続のリクエストでは、保存されたヘッダーが応答に追加されます。

以下に、デフォルト設定のサンプルを示します。

/cache {
  ...
  /headers {
    "Cache-Control"
    "Content-Disposition"
    "Content-Type"
    "Expires"
    "Last-Modified"
    "X-Content-Type-Options"
    "Last-Modified"
  }
}

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

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

ロードバランシングの設定 - /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 ファイルは、カテゴリと othersHTMLを定義します。 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：属性は追加されないことを意味します。

詳しくは、 httponly フラグ、読み取り このページ.

secure

スティッキー接続が有効になっている場合、dispatcher モジュールは renderid cookie を設定します。この cookie には secure フラグがないため、セキュリティを強化するためにこのフラグを追加する必要があります。これをおこなうには、secure 設定ファイルの /stickyConnections ノードで dispatcher.any プロパティを設定します。プロパティの値 ( 0 または 1) は、 renderid cookie に secure 属性が追加されました。 デフォルト値は 0は、属性が追加されることを意味します。 if 受信リクエストはセキュリティで保護されています。 値が 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"

中断エラーの無視 - /ignoreEINTR

システムコールの対象が 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 セクションのアイテムは、 パターンを使用して、Dispatcher が従う、または拒否するページのパスを識別します。glob

この glob の値には、ワイルドカード文字と英数字を含めて、パターンを定義できます。

ログ

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 など）を参照してください。

トレースログ

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/wknd/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:応答を含むno_cache
  リモートサーバーが
  Dispatcher: no_cache ヘッダー。dispatcher による出力のキャッシュが禁止されています。
• not cacheable: response content length is zero
  応答のコンテンツ長がゼロになっています。Dispatcher では、長さゼロのファイルは作成されません。

Business.Adobe.com リソース

Ecommerce Integrations Content Insights Style System Personalized Experiences Content Intelligence Embedded Charts