Dispatcher の設定 configuring-dispatcher

以下の節では、Dispatcher の様々な設定について説明します。

IPv4 と IPv6 のサポート support-for-ipv-and-ipv

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

Dispatcher の設定ファイル dispatcher-configuration-files

デフォルトでは、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"
  }

環境変数の使用 using-environment-variables

値を直接記述する代わりに、dispatcher.any ファイルの単一値プロパティに環境変数を使用できます。環境変数の値を含めるには、${variable_name} という形式を使用します。

例えば、dispatcher.any ファイルがキャッシュディレクトリと同じディレクトリにある場合は、docroot プロパティに次の値を使用できます。

/docroot "${PWD}/cache"

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

/renders {
  /0001 {
    /hostname "${PUBLISH_IP}"
    /port "8443"
  }
}

Dispatcher インスタンスの命名 naming-the-dispatcher-instance-name

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

ファームの定義 defining-farms-farms

/farms プロパティは、1 つまたは複数の Dispatcher の動作セットを定義します。各セットは、異なる Web サイトまたは URL に関連付けられます。/farms プロパティには、1 つまたは複数のファームを含めることができます。

/farms プロパティは、設定構造の最上位プロパティです。ファームを定義するには、/farms プロパティに子プロパティを追加します。Dispatcher インスタンス内でファームを一意に識別するプロパティ名を使用してください。

/farmname プロパティは複数値で、次のような Dispatcher 動作を定義する他のプロパティを含みます。

値には、任意の英数字（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 specify-a-default-page-iis-only-homepage

通過させる HTTP ヘッダーの指定 specifying-the-http-headers-to-pass-through-clientheaders

/clientheaders プロパティでは、Dispatcher がクライアント HTTP リクエストからレンダラー（AEM インスタンス）に渡す HTTP ヘッダーのリストを定義します。

デフォルトでは、Dispatcher から AEM インスタンスに標準の HTTP ヘッダーが転送されます。インスタンスによっては、追加のヘッダーを転送したり、特定のヘッダーを削除したりできます。

通過させる一連のヘッダーをカスタマイズした場合は、ヘッダーの完全なリスト（通常はデフォルトで含まれるヘッダーを含む）を指定する必要があります。

例えば、パブリッシュインスタンス向けのページアクティベーションリクエストを処理する 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"
  }

仮想ホストの識別 identifying-virtual-hosts-virtualhosts

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

[scheme]host[uri][*]

次の設定例では、myCompany の .com ドメインと .ch ドメイン、さらに mySubDivision のすべてのドメインに対するリクエストを処理します。

   /virtualhosts
    {
    "www.myCompany.com"
    "www.myCompany.ch"
    "www.mySubDivison.*"
    }

次の設定は、すべての ​リクエストを処理します。

   /virtualhosts
    {
    "*"
    }

仮想ホストの解決 resolving-the-virtual-host

HTTP 要求または HTTPS 要求を受信すると host,、uri および scheme ヘッダーに最適な仮想ホスト値を探します。Dispatcher は、次の順序で virtualhosts プロパティの値を評価します。

Dispatcher は、以下の方法で最良一致の仮想ホスト値を探します。

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

仮想ホストの解決の例 example-virtual-host-resolution

以下の例は dispatcher.any ファイルから抜粋したもので、2 つの Dispatcher ファームを定義しています。ファームごとに virtualhosts プロパティが定義されています。

/farms
  {
  /myProducts
    {
    /virtualhosts
      {
      "www.mycompany.com/products/*"
      }
    /renders
      {
      /hostname "server1.myCompany.com"
      /port "80"
      }
    }
  /myCompany
    {
    /virtualhosts
      {
      "www.mycompany.com"
      }
    /renders
      {
      /hostname "server2.myCompany.com"
      /port "80"
      }
    }
  }

この例の場合に、指定された HTTP リクエストがどの仮想ホストへと解決されるかを次の表に示します。

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

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

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

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

/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"
  }

ページレンダラーの定義 defining-page-renderers-renders

/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"
      }
  }

レンダーのオプション renders-options

/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 アドレスに関連付けられている場合は、ipv4 プロパティが重要になります。また、ホストは、getaddrinfo 関数への応答として、常に同じ順序の IP アドレスのリストを返します。このような状況では、Dispatcher が接続する IP アドレスがランダムになるように、gethostbyname 関数を使用してください。

Amazon Elastic Load Balancing（ELB）は、同じ順序になる可能性がある IP アドレスのリストを使用して、getaddrinfo に応答するサービスです。

/secure

/secure プロパティの値が "1" の場合、Dispatcher は HTTPS を使用して AEM インスタンスと通信します。詳しくは、SSL を使用するように Dispatcher を設定を参照してください。

/always-resolve

Dispatcher バージョン 4.1.6 では、次のように /always-resolve プロパティを設定できます。

また、次の例に示すように、このプロパティは動的な IP 解決の問題が発生した場合にも使用できます。

/renders {
  /0001 {
     /hostname "host-name-here"
     /port "4502"
     /ipv4 "1"
     /always-resolve "1"
     }
  }

コンテンツへのアクセスの設定 configuring-access-to-content-filter

Dispatcher が受け入れる HTTP 要求を指定するには、/filter セクションを使用します。それ以外のすべての要求は、エラーコード 404（ページが見つかりません）で Web サーバーに返送されます。/filter セクションが存在しない場合は、すべての要求が受け入れられます。

注意：statfile に対する要求は常に拒否されます。

/filter セクションは、HTTP リクエストのリクエスト行部分のパターンに応じてコンテンツへのアクセスを拒否または許可する一連のルールで構成されます。/filter セクションに対しては、許可リスト戦略を使用します。

フィルターの定義 defining-a-filter

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

HTTP リクエストのリクエスト行部分 the-request-line-part-of-http-requests

HTTP/1.1 では、リクエスト行を次のように定義しています。

Method Request-URI HTTP-Version<CRLF>

<CRLF> 文字は、キャリッジリターンとそれに続くラインフィードを表します。次の例は、クライアントが WKND サイトの米国英語ページを要求したときに受信するリクエスト行です。

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

パターンでは、リクエスト行の空白文字と <CRLF> 文字を考慮する必要があります。

二重引用符と一重引用符 double-quotes-vs-single-quotes

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

正規表現 regular-expressions

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

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

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

サンプルフィルター：すべて拒否 example-filter-deny-all

次のサンプルのフィルターセクションでは、Dispatcher がすべてのファイルに対するリクエストを拒否します。すべてのファイルへのアクセスを拒否してから、特定の領域へのアクセスを許可します。

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

明示的に拒否されたエロアへのリクエストに対して、「404 error code (page not found)」が返されます。

サンプルフィルター：特定のエリアへのアクセスを拒否 example-filter-deny-access-to-specific-areas

フィルターを使用して、サンプルの ASP ページの各種要素と、パブリッシュインスタンス内の機密エリアへのアクセスを拒否することもできます。次のフィルターは、ASP ページへのアクセスを拒否するものです。

/0002  { /type "deny" /url "*.asp"  }

サンプルフィルター：POST リクエストの有効化 example-filter-enable-post-requests

次のサンプルフィルターを使用すると、POST メソッドでフォームデータを送信できます。

/filter {
    /0001  { /glob "*" /type "deny" }
    /0002 { /type "allow" /method "POST" /url "/content/[.]*.form.html" }
}

サンプルフィルター：ワークフローコンソールへのアクセスを許可 example-filter-allow-access-to-the-workflow-console

次の例は、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*"   }

サンプルフィルター：正規表現の使用 example-filter-using-regular-expressions

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

/005  {  /type "allow" /extension '(css|gif|ico|js|png|swf|jpe?g)' }

サンプルフィルター：リクエスト URL の追加要素のフィルタリング example-filter-filter-additional-elements-of-a-request-url

それぞれパス、セレクターおよび拡張機能に対するフィルターを使用して、/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 セクションの例 example-filter-section

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

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

以下の dispatcher.any ファイルの /filter セクションは、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
}

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

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

クエリ文字列の制約 restricting-query-strings

Dispatcher バージョン 4.1.5 以降では、/filter セクションを使用してクエリ文字列を制約します。allow フィルター要素を使用して、クエリ文字列を明示的に許可し、一般的な許可を除外することをお勧めします。

1 つのエントリに glob、または method、url、query、および version の組み合わせを含めることができますが、両方を含めることはできません。以下の例では、/etc ノードに解決される URL に対してクエリ文字列 a=* を許可し、他のすべてのクエリ文字列を拒否しています。

/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 のセキュリティのテスト testing-dispatcher-security

Dispatcher のフィルターは、AEM パブリッシュインスタンス上の以下のページおよびスクリプトへのアクセスをブロックする必要があります。Web ブラウザーを使用して、サイト訪問者として以下のページを開こうとして、コード 404 が返されることを確認してください。それ以外の結果が得られた場合は、フィルターを調整してください。

/content/add_valid_page.html?debug=layout に対しては、通常のページレンダリングが表示されます。

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

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 へのアクセスの有効化 enabling-access-to-vanity-urls-vanity-urls

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 へのアクセスを有効にするには、以下の手順を実行します。

シンジケーションリクエストの転送 - /propagateSyndPost forwarding-syndication-requests-propagatesyndpost

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

必要に応じて、/propagateSyndPost プロパティを "1" に設定して、シンジケーションリクエストを Dispatcher に転送します。設定する場合、フィルターセクションで POST リクエストが拒否されていないことを確認する必要があります。

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

/cache セクションは、Dispatcher によるドキュメントのキャッシュ方法を制御します。次のいくつかのサブプロパティを設定して、キャッシュ戦略を実装します。

キャッシュセクションの例を次に示します。

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

キャッシュディレクトリの指定 specifying-the-cache-directory

/docroot プロパティは、キャッシュされたファイルを保存するディレクトリを識別します。

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

statfile の命名 naming-the-statfile

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

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

エラー発生時の古くなったドキュメントの返送 serving-stale-documents-when-errors-occur

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

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

認証使用時のキャッシュ caching-when-authentication-is-used

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

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

ただし、認証済みドキュメントのキャッシュを要件によって承認する場合は、/allowAuthorized を「1」に設定します。

/allowAuthorized "1"

キャッシュするドキュメントの指定 specifying-the-documents-to-cache

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

/rules プロパティの各項目には、glob パターンとタイプが含まれます。

以上のルールで除外されるページ以外にも動的ページがない場合、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 にデフォルトでインストールされています。

フォルダーレベルでのファイルの無効化 invalidating-files-by-folder-level

/statfileslevel プロパティを使用して、キャッシュされたファイルをパスに応じて選択的に無効化します。

無効化されたファイルパスへの​ パスに沿った ​リソースのみが影響を受けます。次の例を考えて見ましょう。web サイトで /content/myWebsite/xx/. 構造を使用していて、statfileslevel を 3 に設定している場合、.stat ファイルは次のように作成されます。

ファイル /content/myWebsite/xx が無効化された場合、docroot から /content/myWebsite/xx までのすべての .stat ファイルに変更が加えられます。このシナリオは、/content/myWebsite/xx のみに当てはまり、/content/myWebsite/yy や /content/anotherWebSite などには当てはまりません。

キャッシュされたファイルの自動無効化 automatically-invalidating-cached-files

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

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

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

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

Glob プロパティについては、Glob プロパティのパターンの設計を参照してください。

この設定によって、/content/wknd/us/en がアクティブ化されると、以下のアクティビティが発生します。

自動生成した 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"
}

カスタム無効化スクリプトの使用 using-custom-invalidation-scripts

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

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

このメソッドは、複数の異なるユースケースを扱う場合に使用できます。例えば、他のアプリケーションに固有のキャッシュを無効化する場合や、ページの外部化された URL とドキュメントルート内のその場所がコンテンツパスと一致しないケースを扱う場合などです。

以下のサンプルスクリプトは、各無効化リクエストをファイルに記録します。

/invalidateHandler "/opt/dispatcher/scripts/invalidate.sh"

サンプルの無効化ハンドラースクリプト sample-invalidation-handler-script

#!/bin/bash

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

キャッシュをフラッシュできるクライアントの制限 limiting-the-clients-that-can-flush-the-cache

/allowedClients プロパティは、キャッシュをフラッシュできる特定のクライアントを定義します。このグロビングパターンが、IP と照合されます。

以下の例の内容は次のとおりです。

/allowedClients
  {
   /0001 { /glob "*.*.*.*"  /type "deny" }
   /0002 { /glob "127.0.0.1" /type "allow" }
  }

Glob プロパティについては、Glob プロパティのパターンの設計を参照してください。

URL パラメーターの無視 ignoring-url-parameters

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

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

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

次の例では、Dispatcher は nocache パラメーターを除くすべてのパラメーターを無視します。そのため、Dispatcher は nocache パラメーターを含んだリクエスト URL をキャッシュしません。

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

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

GET /mypage.html?willbecached=true

ignoreUrlParams 設定例のコンテキストでは、nocache パラメーターは無視されないので、次の HTTP リクエストによってページはキャッシュされま​ せん。

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

Glob プロパティについては、Glob プロパティのパターンの設計を参照してください。

HTTP 応答ヘッダーのキャッシュ caching-http-response-headers

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

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

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

FileETag none

Dispatcher キャッシュファイルの権限 dispatcher-cache-file-permissions

mode プロパティは、キャッシュ内の新しいディレクトリおよびファイルに適用されるファイル権限を指定します。呼び出しプロセスの umask は、この設定を制限します。これは、次の値のうち 1 つまたは複数の合計から構成される 8 進数です。

デフォルト値は 0755 で、所有者は読み取り、書き込みまたは検索を行い、グループおよびその他のユーザーは読み取りまたは検索を行うことができます。

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

デフォルトの /invalidate プロパティでは、アクティベーションごとに、すべての .html ファイルが事実上無効化されます（パスが /invalidate セクションに一致する場合）。トラフィック量が多い web サイトでは、複数回のアクティベーションによってバックエンドの CPU 負荷が増加します。このようなシナリオでは、.stat ファイル更新の「スロットリング」を行って web サイトの応答性を保つことをお勧めします。それには、/gracePeriod プロパティを使用します。

/gracePeriod プロパティは、自動的に無効化された古いリソースを前回のアクティベーション発生後も引き続きキャッシュから使用できる秒数を定義します。このプロパティは、アクティベートのバッチによってキャッシュ全体が繰り返し無効化されるような設定で使用できます。推奨される値は 2 秒です。

詳しくは、上記の /invalidate および /statfileslevel を参照してください。

時間に基づくキャッシュ無効化の設定 - /enableTTL configuring-time-based-cache-invalidation-enablettl

時間に基づくキャッシュ無効化は、/enableTTL プロパティと、HTTP 標準の通常の有効期限ヘッダーの存在によって可能になります。このプロパティを 1（/enableTTL "1"）に設定すると、バックエンドからの応答ヘッダーが評価されます。ヘッダーに Cache-Control、max-age または Expires 日付が含まれている場合、キャッシュされたファイルの横に補助的な空のファイルが作成され、変更時刻は有効期限と同じになります。変更時刻以降にキャッシュされたファイルが要求されると、自動的にバックエンドから再要求されます。

Dispatcher 4.3.5 より前では、TTL 無効化ロジックは、設定された TTL 値のみに基づいていました。Dispatcher 4.3.5 では、設定された TTL と Dispatcher キャッシュ無効化ルールの​ 両方 ​が考慮されます。そのため、キャッシュされたファイルの場合は次のようになります。

この新しい実装では、ファイルの TTL が長いユースケース（CDN 上の場合など）をサポートしています。ただし、TTL の有効期限が切れていない場合でも、これらのファイルは無効化できます。Dispatcher でのキャッシュヒット率よりもコンテンツの鮮度が優先されます。

逆に、有効期限ロジック​ のみ ​をファイルに適用する必要がある場合は、/enableTTL を 1 に設定し、そのファイルを標準のキャッシュ無効化メカニズムから除外します。例えば、次のことができます。

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

これにより、.stat ファイルの無効化が使用されなくなり、指定したファイルに対して TTL の有効期限のみがアクティブになります。

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

/statistics セクションは、Dispatcher が各レンダーの応答性のスコアを付けるファイルのカテゴリを定義します。Dispatcher は、このスコアを使用して、リクエストを送信するレンダーを決定します。

作成したカテゴリごとに glob パターンを定義します。Dispatcher は、要求されたコンテンツの URI とこれらのパターンを比較して、要求されたコンテンツのカテゴリを決定します。

Dispatcher は、最大 8 個の統計カテゴリをサポートしています。9 個以上のカテゴリを定義した場合は、最初の 8 個のカテゴリのみが使用されます。

レンダーの選択

Dispatcher は、レンダリングされたページが必要になるたびに、以下のアルゴリズムを使用してレンダーを選択します。

レンダーのカテゴリのスコアは、以前の応答時間と Dispatcher が以前試みた接続の失敗および成功に基づいています。接続を試みるたびに、要求された URI のカテゴリのスコアが更新されます。

統計カテゴリの定義 defining-statistics-categories

レンダーを選択するための統計を保持する対象となるドキュメントのタイプごとに、カテゴリを定義します。/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 統計へのサーバー使用不可能状態の反映 reflecting-server-unavailability-in-dispatcher-statistics

/unavailablePenalty プロパティは、レンダーへの接続が失敗した場合にレンダー統計に適用される時間（0.1 秒単位）を設定します。Dispatcher は、要求された URI に一致する統計カテゴリにこの時間を追加します。

例えば、指定されたホスト名／ポートへの TCP/IP 接続を確立できない場合は、ペナルティが適用されます。これは、AEM が動作していない（およびリスンしていない）か、ネットワーク関連の問題が発生したことが原因です。

/unavailablePenalty プロパティは、/farm セクション（/statistics セクションの兄弟）の直接の子です。

/unavailablePenalty プロパティが存在しない場合は、値 "1" が使用されます。

/unavailablePenalty "1"

スティッキー接続フォルダーの識別 - /stickyConnectionsFor identifying-a-sticky-connection-folder-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 httponly

スティッキー接続が有効になっている場合、Dispatcher モジュールは renderid Cookie を設定します。この Cookie には httponly フラグがないので、セキュリティを強化するために、このフラグを追加する必要があります。httponly フラグを追加するには、dispatcher.any 設定ファイルの /stickyConnections ノードに httpOnly プロパティを設定します。プロパティの値（0 または 1）は、renderid Cookie に HttpOnly 属性が追加されるかどうかを定義します。デフォルト値は 0 で、この属性が追加されないことを意味します。

httponly フラグについて詳しくは、このページを参照してください。

secure secure

スティッキー接続が有効になっている場合、Dispatcher モジュールは renderid Cookie を設定します。この Cookie には secure フラグがないので、セキュリティを強化するために、このフラグを追加する必要があります。secure フラグを追加するには、dispatcher.any 設定ファイルの /stickyConnections ノードに secure プロパティを設定します。プロパティの値（0 または 1）は、renderid Cookie に secure 属性が追加されるかどうかを定義します。デフォルト値は 0 です。これは、受信リクエストがセキュリティ上安全な​ 場合 ​にこの属性が追加されることを意味します。値が 1 に設定されている場合、受信リクエストがセキュリティ上安全かどうかに関係なく、secure フラグが追加されます。

レンダー接続エラーの処理 handling-render-connection-errors

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

ヘルスチェックページの指定 specifying-a-health-check-page

/health_check プロパティを使用して、ステータスコード 500 が発生したときに確認する URL を指定します。このページもステータスコード 500 を返す場合、インスタンスは使用不可能と見なされ、再試行の前に設定可能なタイムペナルティ（/unavailablePenalty）がレンダーに適用されます。

/health_check
  {
  # Page gets contacted when an instance returns a 500
  /url "/health_check.html"
  }

ページ再試行遅延の指定 specifying-the-page-retry-delay

/retryDelay プロパティは、Dispatcher が待機する、ファームレンダーへの接続試行周期（秒単位）を設定します。各ラウンドで、Dispatcher が 1 件のレンダリングに対して接続を試みる最大回数は、ファーム内のレンダリング回数です。

/retryDelay が明示的に定義されていない場合、Dispatcher は値 "1" を使用します。通常、デフォルト値は適切です。

/retryDelay "1"

再試行回数の設定 configuring-the-number-of-retries

/numberOfRetries プロパティは、Dispatcher がレンダーに対して実行する。接続試行周期の最大回数を設定します。この回数だけ再試行を行っても Dispatcher がレンダーに正常に接続できなかった場合、Dispatcher は失敗応答を返します。

各ラウンドで、Dispatcher が 1 件のレンダリングに対して接続を試みる最大回数は、ファーム内のレンダリング回数です。したがって、Dispatcher が接続を試みる最大回数は（/numberOfRetries）x（レンダリング回数）になります。

明示的な定義がない場合、5 がデフォルトの値として使用されます。

/numberOfRetries "5"

フェイルオーバーメカニズムの使用 using-the-failover-mechanism

Dispatcher ファーム上でフェイルオーバーメカニズムを有効にして、元のリクエストの失敗時に異なるレンダーにリクエストを再送信します。フェイルオーバーを有効にすると、Dispatcher は以下の動作を行います。

フェイルオーバーを有効にするには、次の行をファーム（または Web サイト）に追加します。

/failover "1"

中断エラーの無視 - /ignoreEINTR ignoring-interruption-errors-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 プロパティのパターンの設計 designing-patterns-for-glob-properties

Dispatcher 設定ファイルのいくつかのセクションでは、glob プロパティをクライアントリクエストの選択条件として使用します。glob プロパティの値は、リクエストされたリソースのパスやクライアントの IP アドレスなど、Dispatcher がリクエストの要素と比較するパターンです。例えば、/filter セクションのアイテムは、glob パターンを使用して、Dispatcher が従う、または拒否するページのパスを識別します。

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

ログ logging

Web サーバー設定で、次の設定ができます。

詳しくは、Web サーバーのドキュメント、および使用する Dispatcher インスタンスの readme ファイルを参照してください。

Apache のローテーションされるログまたはパイプ経由のログ

Apache web サーバーを使用している場合、ローテーションされるログ、パイプ経由のログまたはその両方の標準的な機能を使用できます。例えば、パイプ経由のログを次のように使用できます。

DispatcherLog "| /usr/apache/bin/rotatelogs logs/dispatcher.log%Y%m%d 604800"

この機能は自動的に回転します。

ログのローテーションやパイプ経由のログについては、Apache web サーバーのドキュメントを参照してください。例：Apache 2.4。

トレースログ trace-logging

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

基本操作の確認 confirming-basic-operation

Web サーバー、Dispatcher および AEM インスタンスの基本の操作とやり取りを確認するには、次の手順を実行します。

複数の Dispatcher の使用 using-multiple-dispatchers

複雑な設定を行う場合は、複数の Dispatcher を使用できます。例えば、次のように使用できます。

この場合、各要求が経由する Dispatcher は 1 つだけにしてください。別の Dispatcher から渡された要求は処理されません。したがって、どちらの Dispatcher も AEM web サイトに直接アクセスするようにしてください。

デバッグ debugging

ヘッダー 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 によって返される応答ヘッダーの一覧です。