ホスティング動作を構成する

Firebase Hosting を使用すると、サイトへのリクエストに対してカスタマイズされたホスティング動作を構成できます。

Hosting の構成で可能なこと

ローカルプロジェクトディレクトリにあるファイルの中から、Firebase Hosting にデプロイするファイルを指定します。詳しくはこちらをご覧ください。
カスタマイズされた 404/Not Found ページを提供します。詳しくはこちらをご覧ください。
移動または削除したページの redirects を設定します。詳しくはこちらをご覧ください。
次の目的で rewrites を設定します。
- 複数の URL で同じコンテンツを表示します。詳しくはこちらをご覧ください。
- Hosting の URL から関数を提供したり、Cloud Run コンテナにアクセスしたりします。詳しくは関数またはコンテナをご覧ください。
- カスタムドメインのダイナミックリンクを作成します。詳しくはこちらをご覧ください。
headers を追加して、リクエストまたはレスポンスに関する詳細情報を渡します。たとえば、ブラウザがページやコンテンツをどのように処理すべきかに関する情報を渡すことができます（認証、キャッシュ、エンコードなど）。詳しくはこちらをご覧ください。
国際化（i18n）リライトを設定し、ユーザーの言語設定または国に基づいて特定のコンテンツを提供します。詳しくはこちらをご覧ください（別のページに移動します）。

Hosting の構成を定義する場所

Firebase Hosting の構成は firebase.json ファイルで定義します。firebase init コマンドを実行すると、Firebase によってプロジェクトディレクトリのルートに firebase.json ファイルが自動的に作成されます。

このページの最後に、firebase.json の構成例（Firebase Hosting のみを対象）を紹介します。firebase.json ファイルには、他の Firebase サービスの構成も定義できます。

Hosting REST API を使用すると、デプロイされる firebase.json コンテンツを確認できます。

Hosting のレスポンスの優先順位

このページで説明する Firebase Hosting 構成オプションが競合する場合があります。競合が発生した場合、Hosting からのレスポンスは次の優先順位に従って決定されます。

/__/* パスセグメントで始まる予約済みの名前空間
リダイレクトの構成
正確に一致する静的コンテンツ
リライトの構成
カスタムの 404 ページ
デフォルトの 404 ページ

i18n リライトを使用する場合は、スコープ内の完全一致と 404 処理の優先順位が拡張され、「i18n content」が含められます。

デプロイするファイルを指定する

デフォルトの firebase.json ファイルに含まれるデフォルトの属性（public と ignore）により、プロジェクトディレクトリ内のどのファイルが Firebase プロジェクトにデプロイされるかが定義されます。

firebase.json ファイルのデフォルトの hosting 構成は次のようになります。

"hosting": {
  "public": "public",  // the only required attribute for Hosting
  "ignore": [
    "firebase.json",
    "**/.*",
    "**/node_modules/**"
  ]
}

public

必須
public 属性には、Firebase Hosting にデプロイするディレクトリを指定します。デフォルト値は public という名前のディレクトリですが、プロジェクトディレクトリ内に存在している任意のディレクトリのパスを指定できます。

デプロイするディレクトリのデフォルト名は次のとおりです。

"hosting": {
  "public": "public"

  // ...
}

デフォルト値は、デプロイするディレクトリに変更できます。

"hosting": {
  "public": "dist/app"

  // ...
}

ignore

省略可
ignore 属性には、デプロイ時に無視するファイルを指定します。Git の .gitignore と同じように glob を使用できます。

無視するファイルのデフォルト値は次のとおりです。

"hosting": {
  // ...

  "ignore": [
    "firebase.json",  // the Firebase configuration file (the file described on this page)
    "**/.*",  // files with a leading period should be hidden from the system
    "**/node_modules/**"  // contains dependencies used to create your site but not run it
  ]
}

404 / Not Found ページをカスタマイズする

省略可
存在しないページにユーザーがアクセスしようとしたときに、カスタム 404 Not Found エラーを表示するように指定できます。

プロジェクトの public ディレクトリに新しいファイルを作成し、404.html という名前を付けて、カスタムの 404 Not Found コンテンツをそのファイルに追加します。

ブラウザでドメインまたはサブドメインに 404 Not Found エラーが発生した場合、Firebase Hosting はこのカスタム 404.html ページのコンテンツを表示します。

リダイレクトを構成する

省略可
URL リダイレクトは、ページの移動や URL の短縮でリンクが無効にならないようにするために使用します。たとえば、ブラウザを example.com/team から example.com/about.html にリダイレクトできます。

URL リダイレクトを指定するには、オブジェクトの配列を含む redirects 属性を作成します（「リダイレクトルール」と呼ばれます）。それぞれのルールで URL パターンを指定します。この URL パターンがリクエスト URL パスと一致した場合、指定された宛先 URL へのリダイレクトの応答がトリガーされます。

redirects 属性の基本構造は次のとおりです。この例では、/foo に対するリクエストをリダイレクトし、新しいリクエストを /bar に送信します。

"hosting": {
  // ...

  // Returns a permanent redirect to "/bar" for requests to "/foo" (but not "/foo/**")
  "redirects": [ {
    "source": "/foo",
    "destination": "/bar",
    "type": 301
  } ]
}

redirects 属性の詳しい例を見る

"hosting": {
  // ...

  // Add the "redirects" attribute within "hosting"
  "redirects": [ {
    // Returns a permanent redirect to "/bar" for requests to "/foo" (but not "/foo/**")
    "source": "/foo",
    "destination": "/bar",
    "type": 301
  }, {
    // Returns a permanent redirect to "/bar" for requests to both "/foo" and "/foo/**"
    "source": "/foo{,/**}"
    "destination": "/bar"
    "type": 301
  }, {
    // Returns a temporary redirect for all requests to files or directories in the "firebase" directory
    "source": "/firebase/**",
    "destination": "https://firebase.google.com/",
    "type": 302
  }, {
    // A regular expression-based redirect equivalent to the above behavior
    "regex": "/firebase/.*",
    "destination": "https://firebase.google.com/",
    "type": 302
  } ]
}

redirects 属性にはリダイレクトルールの配列が含まれます。それぞれのルールには、以下の表に示すフィールドを含める必要があります。

Firebase Hosting は、各リクエストの開始時（ファイルまたはフォルダがそのパスに存在するかどうかをブラウザが判断する前）に source または regex の値とすべての URL パスを比較します。一致が見つかった場合、Firebase Hosting のオリジンサーバーが HTTPS リダイレクトレスポンスを送信し、destination URL に新しいリクエストを送信するようにブラウザに指示します。

フィールド		説明
`redirects`
	`source` （推奨）または `regex`	URL パターンを指定します。この URL パターンが最初のリクエスト URL と一致した場合、リダイレクトの適用がトリガーされます。 `source` を使用して glob を指定します（推奨）。 `regex` を使用して RE2 正規表現を指定します。
	`destination`	ブラウザが新しいリクエストを送信する静的 URL この URL には、相対パス、絶対パスのどちらでも指定できます。
	`type`	HTTPS レスポンスコード「Moved Permanently（恒久的に移動した）」には `301` のタイプを使用します。「Found（検出）」（一時的なリダイレクト）には `302` のタイプを使用します。

リダイレクト用の URL セグメントをキャプチャする

省略可
リダイレクトルールの URL パターン（source または regex の値）の特定のセグメントをキャプチャし、ルールの destination パスでそれらのセグメントを使用しなければならない場合があります。

glob を使用する場合の URL セグメントのキャプチャ

source フィールドを使用している場合（つまり URL パターンに glob を指定している場合）、セグメントを識別するための : プレフィックスを含めることによって、セグメントをキャプチャできます。セグメントの後の残りの URL パスもキャプチャする必要がある場合は、セグメントの直後に * を使用します。次に例を示します。

"hosting": {
  // ...

  "redirects": [ {
    "source": "/blog/:post*",  // captures the entire URL segment beginning at "post"
    "destination": "https://blog.myapp.com/:post", // includes the entire URL segment identified and captured by the "source" value
    "type": 301
  }, {
    "source": "/users/:id/profile",  // captures only the URL segment "id", but nothing following
    "destination": "/users/:id/newProfile",  // includes the URL segment identified and captured by the "source" value
    "type": 301
  } ]
}

RE2 正規表現を使用する場合の URL セグメントのキャプチャ

regex フィールドを使用している場合（つまり URL パターンに RE2 正規表現を指定している場合）、名前付きまたは名前なしの RE2 キャプチャグループを使用してセグメントをキャプチャできます。名前付きキャプチャグループは、destination フィールド内で : プレフィックスを使用することによって参照できます。名前なしキャプチャグループは、regex の値の数字インデックスで参照できます（このインデックスは 1 から始まります）。次に例を示します。

"hosting": {
  // ...

  "redirects": [ {
    "regex": "/blog/(?P<post>.+)",  // if you're familiar with PCRE, be aware that RE2 requires named capture groups to begin with ?P
    "destination": "https://blog.myapp.com/:post",  // includes the entire URL segment identified and captured by the `regex` value
    "type": 301
  }, {
    "regex": "/users/(\d+)/profile",  // uses the \d directive to only match numerical path segments
    "destination": "/users/:1/newProfile",  // the first capture group to be seen in the `regex` value is named 1, and so on
    "type": 301
  } ]
}

リライトを構成する

省略可
リライトは、複数の URL で同じコンテンツを表示するために使用します。パターンに一致する URL を受け取って、クライアント側コードで表示内容を決定するようにできるため、パターンマッチングで使用すると特に有用です。

リライトを使用すると、ナビゲーションに HTML5 pushState を使用するアプリをサポートできます。指定した source または regex の URL パターンに一致する URL パスをブラウザが開こうとすると、代わりに destination URL のファイルのコンテンツが表示されます。

URL リライトを指定するには、オブジェクトの配列を含む rewrites 属性を作成します（「リライトルール」と呼ばれます）。それぞれのルールで URL パターンを指定します。この URL パターンがリクエスト URL パスと一致した場合、Hosting の応答がトリガーされ、指定された宛先 URL を提供するように応答が行われます。

rewrites 属性の基本構造は次のとおりです。この例では、存在しないファイルまたはディレクトリへのリクエストに対して index.html を返します。

"hosting": {
  // ...

  // Serves index.html for requests to files or directories that do not exist
  "rewrites": [ {
    "source": "**",
    "destination": "/index.html"
  } ]
}

rewrites 属性の詳しい例を見る

"hosting": {
// ...

// Add the "rewrites" attribute within "hosting"
"rewrites": [ {
  // Serves index.html for requests to files or directories that do not exist
  "source": "**",
  "destination": "/index.html"
}, {
  // Serves index.html for requests to both "/foo" and "/foo/**"
  // Using "/foo/**" only matches paths like "/foo/xyz", but not "/foo"
  "source": "/foo{,/**}",
  "destination": "/index.html"
}, {
  // A regular expression-based rewrite equivalent to the above behavior
  "regex": "/foo(/.*)?",
  "destination": "/index.html"
}, {
  // Excludes specified pathways from rewrites
  "source": "!/@(js|css)/**",
  "destination": "/index.html"
} ]
}

rewrites 属性にはリライトルールの配列が含まれます。それぞれのルールには、以下の表に示すフィールドを含める必要があります。

Firebase Hosting は、指定された source または regex の URL パターンに一致する URL パスにファイルまたはディレクトリが存在しない場合にのみ、リライトルールを適用します。リクエストによってリライトルールがトリガーされると、ブラウザは HTTP リダイレクトではなく、指定された destination ファイルの実際のコンテンツを返します。

フィールド説明

フィールド	説明
`rewrites`
	`source` （推奨）または `regex`	URL パターンを指定します。この URL パターンが最初のリクエスト URL と一致した場合、リライトの適用がトリガーされます。 `source` を使用して glob を指定します（推奨）。 `regex` を使用して RE2 正規表現を指定します。
	`destination`	実際に存在するローカルファイルこの URL には、相対パス、絶対パスのどちらでも指定できます。

rewrites

source （推奨）
または regex

URL パターンを指定します。この URL パターンが最初のリクエスト URL と一致した場合、リライトの適用がトリガーされます。

source を使用して glob を指定します（推奨）。
regex を使用して RE2 正規表現を指定します。

destination

実際に存在するローカルファイル

この URL には、相対パス、絶対パスのどちらでも指定できます。

関数にリクエストを送信する

rewrites を使用すると、Firebase Hosting の URL から関数を提供できます。次のコードは、Cloud Functions を使用して動的コンテンツを提供する部分を表しています。

たとえば、Hosting サイトの /bigben ページからすべてのリクエストを送信して bigben 関数を実行する場合は、次のようになります。

"hosting": {
  // ...

  // Directs all requests from the page `/bigben` to execute the `bigben` function
  "rewrites": [ {
    "source": "/bigben",
    "function": "bigben",
    "region": "us-central1"  // optional (see note below)
  } ]
}

このリライトルールを追加して Firebase にデプロイすると（firebase deploy を使用）、次の URL から関数にアクセスできるようになります。

Firebase のサブドメイン:
PROJECT_ID.web.app/bigben と PROJECT_ID.firebaseapp.com/bigben
接続されたカスタムドメイン:
CUSTOM_DOMAIN/bigben

Hosting を使用してリクエストを関数にリダイレクトする場合、サポートされている HTTP リクエストメソッドは、GET、POST、HEAD、PUT、DELETE、PATCH、OPTIONS です。 REPORT や PROFIND などの他のメソッドはサポートされていません。

Cloud Run コンテナにリクエストを送信する

rewrites を使用すると、Firebase Hosting の URL から Cloud Run コンテナにアクセスできます。次のコードは、Cloud Run を使用して動的コンテンツを提供する部分を表しています。

たとえば、Hosting サイトのページ（/helloworld）からのすべてのリクエストを送信して、helloworld コンテナインスタンスの起動と実行をトリガーする場合は、次のようにします。

"hosting": {
 // ...

 // Directs all requests from the page `/helloworld` to trigger and run a `helloworld` container
 "rewrites": [ {
   "source": "/helloworld",
   "run": {
     "serviceId": "helloworld",  // "service name" (from when you deployed the container image)
     "region": "us-central1"  // optional (if omitted, default is us-central1)
   }
 } ]
}

このリライトルールを追加して Firebase にデプロイすると（firebase deploy を使用）、次の URL からコンテナイメージにアクセスできるようになります。

Firebase のサブドメイン:
PROJECT_ID.web.app/helloworld と PROJECT_ID.firebaseapp.com/helloworld
接続されたカスタムドメイン:
CUSTOM_DOMAIN/helloworld

Hosting を使用して Cloud Run コンテナにリクエストをリダイレクトする場合、サポートされている HTTP リクエストメソッドは GET、POST、HEAD、PUT、DELETE、PATCH、OPTIONS です。REPORT や PROFIND などの他のメソッドはサポートされていません。

現在、次のリージョンでは、Hosting で Cloud Run の rewrites を使用できます。

asia-east1
asia-east2
asia-northeast1
asia-northeast2
asia-northeast3
asia-south1
asia-southeast1
asia-southeast2
australia-southeast1
europe-north1
europe-west1
europe-west2
europe-west3
europe-west4
europe-west6
northamerica-northeast1
southamerica-east1
us-central1
us-east1
us-east4
us-west1

カスタムドメインの Dynamic Links を作成する

rewrites を使用して、カスタムドメインの Dynamic Links を作成できます。Dynamic Links にカスタムドメインを設定する方法については、Dynamic Links のドキュメントをご覧ください。

Dynamic Links にのみカスタムドメインを使用する

"hosting": {
  // ...

  "appAssociation": "AUTO",  // required for Dynamic Links (default is AUTO if not specified)

  // Add the "rewrites" attribute within "hosting"
  "rewrites": [ {
    "source": "/**",  // the Dynamic Links start with "https://CUSTOM_DOMAIN/"
    "dynamicLinks": true
  } ]
}

Dynamic Links に使用するカスタムドメインのパスプレフィックスを指定する

"hosting": {
  // ...

  "appAssociation": "AUTO",  // required for Dynamic Links (default is AUTO if not specified)

  // Add the "rewrites" attribute within "hosting"
  "rewrites": [ {
    "source": "/promos/**",  // the Dynamic Links start with "https://CUSTOM_DOMAIN/promos/"
    "dynamicLinks": true
  }, {
    "source": "/links/share/**",  // the Dynamic Links start with "https://CUSTOM_DOMAIN/links/share/"
    "dynamicLinks": true
  } ]
}

firebase.json ファイル内での Dynamic Links の構成には、次の要素が必要です。

フィールド		説明
`appAssociation`		`AUTO` に設定する必要があります。この属性を構成に追加しないと、`appAssociation` のデフォルトは `AUTO` になります。この属性を `AUTO` に設定すると、Hosting はリクエスト時に `assetlinks.json` ファイルと `apple-app-site-association` ファイルを動的に生成できます。
`rewrites`
	`source`	Dynamic Links に使用するパス URL のパスのリライトルールとは異なり、Dynamic Links のリライトルールに正規表現を含めることはできません。
	`dynamicLinks`	`true` に設定する必要があります。

重要: Dynamic Links では、ホスティングの優先順位に注意する必要があります。

Dynamic Links URL プレフィックスは、それよりも優先度の高いホスティング構成と競合しないようにします。たとえば、ホストされる静的コンテンツは必ずリライトよりも優先されます。
それぞれの redirects と rewrites の属性の中で、リクエストされたパスと一致する URL パターンを持つ最初のルールで定義されているリダイレクトまたはリライトが適用されます。そのため、それぞれの redirects 属性と rewrites 属性の中でルールを意図的に並べる必要があります。

詳細については、Dynamic Links のドキュメントをご覧ください。

ヘッダーを構成する

省略可
ヘッダーを使用すると、クライアントとサーバーはリクエストまたはレスポンスと一緒に追加情報を渡すことができます。ヘッダーの一部は、ブラウザがページとそのコンテンツを処理する方法（アクセス制御、認証、キャッシュ、エンコードなど）に影響を与える可能性があります。

ファイル固有のカスタムレスポンスヘッダーを指定するには、ヘッダーオブジェクトの配列を含む headers 属性を作成します。各オブジェクトに URL パターンを指定します。この URL パターンがリクエスト URL のパスと一致した場合、指定されたカスタムレスポンスヘッダーを適用するようにトリガーされます。

headers 属性の基本構造は次のとおりです。この例では、すべてのフォントファイルに CORS ヘッダーを適用します。

"hosting": {
  // ...

  // Applies a CORS header for all font files
  "headers": [ {
    "source": "**/*.@(eot|otf|ttf|ttc|woff|font.css)",
    "headers": [ {
      "key": "Access-Control-Allow-Origin",
      "value": "*"
    } ]
  } ]
}

headers 属性の詳しい例を見る

"hosting": {
  // ...

  // Add the "headers" attribute within "hosting"
  "headers": [ {
    // Applies a CORS header for all font files
    "source": "**/*.@(eot|otf|ttf|ttc|woff|font.css)",
    "headers": [ {
      "key": "Access-Control-Allow-Origin",
      "value": "*"
    } ]
  }, {
    // Overrides the default 1 hour browser cache with a 2 hour cache for all image files
    "source": "**/*.@(jpg|jpeg|gif|png)",
    "headers": [ {
      "key": "Cache-Control",
      "value": "max-age=7200"
    } ]
  }, {
    // A regular expression-based rewrite equivalent to the above behavior
    "regex": ".+/\w+\.(jpg|jpeg|gif|png)$",
    "headers": [ {
      "key": "Cache-Control",
      "value": "max-age=7200"
    } ]
  }, {
    // Sets the cache header for 404 pages to cache for 5 minutes
    "source": "404.html",
    "headers": [ {
      "key": "Cache-Control",
      "value": "max-age=300"
    } ]
  } ]
}

headers 属性には定義の配列が含まれます。それぞれの定義には、以下の表に示すフィールドを含める必要があります。

フィールド			説明
`headers`
	`source` （推奨）または `regex`		URL パターンを指定します。この URL パターンが最初のリクエスト URL と一致した場合、カスタムヘッダーの適用がトリガーされます。 `source` を使用して glob を指定します（推奨）。 `regex` を使用して RE2 正規表現を指定します。カスタム 404 ページに対して照合されるヘッダーを作成するには、`source` または `regex` の値として `404.html` を使用します。
	（sub-）`headers` の配列		リクエストパスに適用されるカスタムヘッダーそれぞれのサブヘッダーには `key` と `value` のペアを含める必要があります（次の 2 行を参照）。
		`key`	ヘッダーの名前。例: `Cache-Control`
		`value`	ヘッダーの値。例: `max-age=7200`

動的コンテンツの提供とマイクロサービスのホスティングの詳細については、Hosting セクションの Cache-Control をご覧ください。また、CORS ヘッダーの詳細も確認してください。

`.html` 拡張子を制御する

省略可
cleanUrls 属性を使用すると、URL に .html 拡張子を含めるかどうかを制御できます。

true の場合、Hosting はアップロードされたファイルの URL から拡張子 .html を自動的に削除します。.html 拡張子がリクエストに追加された場合、Hosting は同じパスへの 301 リダイレクトを実行しますが、.html 拡張子は削除されます。

cleanUrls 属性を使用して、URL に含まれる .html を制御する方法を次に示します。

"hosting": {
  // ...

  // Drops `.html` from uploaded URLs
  "cleanUrls": true
}

末尾のスラッシュを制御する

省略可
trailingSlash 属性を使用すると、静的コンテンツの URL に末尾のスラッシュを含めるかどうかを制御できます。

true の場合、Hosting は URL のリダイレクトで末尾のスラッシュを追加します。
false の場合、Hosting は URL のリダイレクトで末尾のスラッシュを削除します。
指定しない場合、Hosting はディレクトリインデックスファイル（たとえば、about/index.html）にのみ末尾にスラッシュを追加します。

trailingSlash 属性を追加して末尾のスラッシュを制御する方法を次に示します。

"hosting": {
  // ...

  // Removes trailing slashes from URLs
  "trailingSlash": false
}

trailingSlash 属性は、Cloud Functions または Cloud Run によって提供される動的コンテンツへのリライトには影響しません。

glob パターンマッチング

Firebase Hosting 構成オプションでは、Git で gitignore ルールを処理する場合や Bower で ignore ルールを処理する場合と同様に、extglob を使用する glob パターンマッチング表記を使用します。より詳しい参考資料としては、こちらの Wiki ページをご覧ください。以下では、このページで使用した例について説明します。

firebase.json - public ディレクトリのルートにある firebase.json ファイルにのみ一致します。
** - 任意のサブディレクトリ内にあるファイルまたはフォルダと一致します。
* - public ディレクトリのルートにあるファイルとフォルダにのみ一致します。
**/.* - 任意のサブディレクトリ内にある「.」で始まるファイル（通常は .git フォルダ内などにある非表示ファイル）と一致します。
**/node_modules/** - node_modules フォルダの任意のサブディレクトリ内にあるファイルまたはフォルダと一致します。このフォルダ自体が public ディレクトリの任意のサブディレクトリとなります。
**/*.@(jpg|jpeg|gif|png) - 任意のサブディレクトリ内にあるファイルで、.jpg、.jpeg、.gif、.png のいずれかで終了するものと一致します。

Hosting の完全な構成の例

以下に、Firebase Hosting の完全な firebase.json 構成例を示します。firebase.json ファイルには、他の Firebase サービスの構成も定義できます。

{
  "hosting": {

    "public": "dist/app",  // "public" is the only required attribute for Hosting

    "ignore": [
      "firebase.json",
      "**/.*",
      "**/node_modules/**"
    ],

    "redirects": [ {
      "source": "/foo",
      "destination": "/bar",
      "type": 301
    }, {
      "source": "/firebase/**",
      "destination": "https://www.firebase.com",
      "type": 302
    } ],

    "rewrites": [ {
      // Shows the same content for multiple URLs
      "source": "/app/**",
      "destination": "/app/index.html"
    }, {
      // Configures a custom domain for Dynamic Links
      "source": "/promos/**",
      "dynamicLinks": true
    }, {
      // Directs a request to Cloud Functions
      "source": "/bigben",
      "function": "bigben"
    }, {
      // Directs a request to a Cloud Run containerized app
      "source": "/helloworld",
      "run": {
        "serviceId": "helloworld",
        "region": "us-central1"
      }
    } ],

    "headers": [ {
      "source": "**/*.@(eot|otf|ttf|ttc|woff|font.css)",
      "headers": [ {
        "key": "Access-Control-Allow-Origin",
        "value": "*"
      } ]
    }, {
      "source": "**/*.@(jpg|jpeg|gif|png)",
      "headers": [ {
        "key": "Cache-Control",
        "value": "max-age=7200"
      } ]
    }, {
      "source": "404.html",
      "headers": [ {
        "key": "Cache-Control",
        "value": "max-age=300"
      } ]
    } ],

    "cleanUrls": true,

    "trailingSlash": false,

    // Required to configure custom domains for Dynamic Links
    "appAssociation": "AUTO",

  }
}