Azure Static Web Apps を構成する
Azure Static Web Apps の構成は、次の設定を制御する staticwebapp.config.json ファイルで定義されます。
- ルーティング
- 認証
- 承認
- フォールバック規則
- HTTP 応答のオーバーライド
- グローバル HTTP ヘッダーの定義
- カスタムの MIME の種類
- ネットワーク
Note
ルーティングを構成するのに以前使用されていた routes.json は非推奨となっています。 この記事の説明のとおりに staticwebapp.config.json を使用して、静的 Web アプリのルーティングやその他の設定を構成してください。
これは、Azure Static Web Apps に関するドキュメントで、Azure Storage の静的 Web サイトのホスティング機能とは別の、スタンドアロン製品です。
ファイルの場所
staticwebapp.config.json の推奨される場所は、ワークフロー ファイルで app_location
として設定されたフォルダー内です。 ただし、このファイルは app_location
として設定されたフォルダー内の任意のサブフォルダーに配置できます。
詳細については、「構成ファイルの例」を参照してください。
重要
staticwebapp.config.json がある場合、非推奨の routers.json ファイルは無視されます。
ルート
静的 web アプリ内の1つ以上のルートに対して規則を定義できます。 ルートルールを使用すると、特定のロールのユーザーへのアクセスを制限したり、リダイレクトや書き換えなどのアクションを実行したりできます。 ルートは、ルーティング規則の配列として定義します。 使用例については、「構成ファイルの例」を参照してください。
- 規則は、ルートが 1 つしかない場合でも
routes
配列で定義します。 - 規則は、
routes
配列に出現する順序で評価されます。 - 最初に一致した時点で、規則の評価は停止します。 一致は、
route
プロパティと配列内の値methods
(指定されている場合) が要求と一致した場合に発生します。 各要求は、1つのルールに一致することができます。
ルーティングの懸念事項は、認証 (ユーザーの識別) および承認 (ユーザーへの機能の割り当て) の概念とかなり重複しています。 この記事と共に、認証と承認に関するガイドをお読みください。
ルートの定義
各規則は、ルート パターンと、1 つまたは複数のオプションの規則プロパティで構成されます。 ルート規則は routes
配列で定義します。 使用例については、「構成ファイルの例」を参照してください。
重要
ルールが 要求と一致するかどうかを判断するために、route
および methods
(指定されている場合) プロパティのみが使用されます。
規則のプロパティ | 必須 | 既定値 | 解説 |
---|---|---|---|
route |
はい | 該当なし | 呼び出し元によって要求されるルート パターン。
|
methods |
いいえ | すべてのメソッド | ルートに一致する要求メソッドの配列を定義します。 使用可能なメソッドには、GET 、HEAD 、POST 、PUT 、DELETE 、CONNECT 、OPTIONS 、TRACE 、PATCH があります。 |
rewrite |
いいえ | 該当なし | 要求から返されるファイルまたはパスを定義します。
|
redirect |
いいえ | 該当なし | 要求のファイルまたはパスのリダイレクト先を定義します。 |
statusCode |
いいえ | 301 または302 リダイレクトの場合 |
応答の HTTP 状態コード。 |
headers |
いいえ | 該当なし | 応答に追加される HTTP ヘッダーのセット。
|
allowedRoles |
いいえ | anonymous | ルートにアクセスするために必要なロール名の配列を定義します。
|
各プロパティは、要求または応答パイプラインで特定の目的があります。
目的 | Properties |
---|---|
ルートと一致させる | route , methods |
規則が一致して承認された後に処理する | rewrite (要求を変更する)redirect 、headers 、statusCode (応答を変更する) |
ルートが一致した後に承認する | allowedRoles |
ルートパターンの指定
route
プロパティは、正確なルートまたはワイルドカードパターンにすることができます。
正確なルート
正確なルートを定義するには、ファイルの完全なパスをroute
プロパティに配置します。
{
"route": "/profile/index.html",
"allowedRoles": ["authenticated"]
}
このルールは、ファイル/ /profile/index.htmlの要求と一致します。 index.htmlが既定のファイルであるため、このルールはフォルダー (/profileまたは/profile/) の要求とも一致します。
重要
route
プロパティでフォルダーパス (/profile
または/profile/
) を使用する場合は、 ファイル/ /profile/index.htmlの要求と一致しません。 ファイルを提供するルートを保護する場合は、ファイルの完全なパス (/profile/index.html
など) を常に使用します。
ワイルドカード パターン
ワイルドカード規則は、ルート パターン内のすべての要求と一致し、パスの末尾でのみサポートされます。また、ファイル拡張子でフィルター処理できます。 使用例については、「構成ファイルの例」を参照してください。
たとえば、カレンダー アプリケーションに対するルートを実装するには、1 つのファイルを提供するように、calendar ルートに該当するすべての URL を書き換えることができます。
{
"route": "/calendar*",
"rewrite": "/calendar.html"
}
その場合、calendar.html ファイルでは、クライアント側ルーティングを使用して、/calendar/january/1
、/calendar/2020
、/calendar/overview
などの URL のバリエーションに対して異なるビューを提供できます。
Note
/calendar/*
のルートパターンは 、 /calendar/パスの下にあるすべての要求と一致します。 ただし、path /calendar または /calendar.htmlの要求とは一致しません。 /calendarで始まるすべての要求を照合するには、/calendar*
を使用します。
ワイルドカードの一致をファイル拡張子でフィルター処理できます。 たとえば、指定したパスの HTML ファイルのみに一致する規則を追加する場合は、次の規則を作成できます。
{
"route": "/articles/*.html",
"headers": {
"Cache-Control": "public, max-age=604800, immutable"
}
}
複数のファイル拡張子に基づいてフィルター処理するには、この例に示すように、オプションを中かっこで囲みます。
{
"route": "/images/thumbnails/*.{png,jpg,gif}",
"headers": {
"Cache-Control": "public, max-age=604800, immutable"
}
}
ワイルドカード ルートの一般的なユース ケースには、以下が含まれます。
- パス パターン全体に対して特定のファイルを提供する
- 認証と承認の規則を適用する
- 特殊なキャッシュ規則を実装する
ロールによるルートのセキュリティ保護
ルートをセキュリティで保護するには、1 つまたは複数のロール名を規則の allowedRoles
配列に追加します。 使用例については、「構成ファイルの例」を参照してください。
重要
ルーティング規則では、HTTP 要求をセキュリティで保護できるのは、クライアントから提供されるルートStatic Web Appsのみです。 多くのフロントエンド フレームワークでは、Static Web Appsへの要求を発行せずに、ブラウザ上でルートを変更するクライアント側のルーティングを採用しています。 ルーティング規則では、クライアント側のルートはセキュリティで保護されません。 クライアントは、機密データ を取得するために HTTP API を呼び出す必要があります。 API がデータを返す前に、ユーザーのID を検証します。
既定では、すべてのユーザーが組み込みの anonymous
ロールに属し、ログインしているすべてのユーザーが authenticated
ロールのメンバーになります。 必要に応じて、状態を介してユーザーをカスタム ロールに関連付けることができます。
たとえば、認証されたユーザーのみにルートを制限するには、組み込みの authenticated
ロールを allowedRoles
配列に追加します。
{
"route": "/profile*",
"allowedRoles": ["authenticated"]
}
必要に応じて、allowedRoles
配列に新しいロールを作成できます。 ルートを管理者のみに制限するには、allowedRoles
配列に administrator
という名前の独自のロールを定義できます。
{
"route": "/admin*",
"allowedRoles": ["administrator"]
}
- ロールの名前は完全に制御できます。ロールが従う必要のあるリストはありません。
- 個々のユーザーは、招待によってロールに関連付けられます。
重要
コンテンツをセキュリティで保護する場合は、可能な限り正確なファイルを指定します。 保護するファイルが多数ある場合は、共有プレフィックスの後にワイルドカードを使用します。 例:/profile を含む、 /profile/profile*
で始まる可能性のあるすべてのルートをセキュリティで保護します。
アプリケーション全体へのアクセスの制限
アプリケーション内のすべてのルートについて認証を要求することが一般的です。 これを実現するには、すべてのルートに一致する規則を追加し、組み込みの authenticated
ロールを allowedRoles
配列に格納します。
次の構成例では、匿名アクセスをブロックし、認証済みでないすべてのユーザーを Azure Active Directory のログイン ページにリダイレクトします。
{
"routes": [
{
"route": "/*",
"allowedRoles": ["authenticated"]
}
],
"responseOverrides": {
"401": {
"statusCode": 302,
"redirect": "/.auth/login/aad"
}
}
}
注意
既定では、構成済みのすべての ID プロバイダーが有効になっています。 認証プロバイダーをブロックするには、認証と承認に関するページを参照してください。
フォールバック ルート
シングル ページ アプリケーションは、多くの場合、クライアント側のルーティングに依存します。 これらのクライアント側ルーティング規則では、要求をサーバーに返さずに、ブラウザーのウィンドウの場所が更新されます。 ページを更新する場合、またはクライアント側ルーティング規則によって生成された URL に直接移動する場合は、適切な HTML ページ (通常はクライアント側アプリの index.html) を提供するために、サーバー側フォールバック ルートが必要です。
navigationFallback
セクションを追加して、フォールバック ルールを定義できます。 次の例は、デプロイされたファイルに一致しないすべての静的ファイルの要求に対して /index.html を返します。
{
"navigationFallback": {
"rewrite": "/index.html"
}
}
フィルターを定義すると、どの要求でフォールバック ファイルを返すかを制御できます。 次の例では、 /images フォルダーの特定のルートと /css フォルダーのすべてのファイルに対する要求が、フォールバック ファイルを返す対象から除外されます。
{
"navigationFallback": {
"rewrite": "/index.html",
"exclude": ["/images/*.{png,jpg,gif}", "/css/*"]
}
}
次のファイル構造の例では、この規則を使用して次の結果を得ることができます。
├── images
│ ├── logo.png
│ ├── headshot.jpg
│ └── screenshot.gif
│
├── css
│ └── global.css
│
└── index.html
要求先 | 返されるもの | 状態 |
---|---|---|
/about/ | index.html ファイル | 200 |
/images/logo.png | 画像ファイル | 200 |
/images/icon.svg | /index.html ファイル。svg ファイル拡張子が /images/*.{png,jpg,gif} フィルターに含まれていないため |
200 |
/images/unknown.png | "ファイルが見つかりませんでした" エラー | 404 |
/css/unknown.css | "ファイルが見つかりませんでした" エラー | 404 |
/css/global.css | スタイルシート ファイル | 200 |
/images または /css フォルダー外にあるその他のファイル | index.html ファイル | 200 |
重要
非推奨の routes.json ファイルから移行する場合は、routing rules にレガシ フォールバック ルート ("route": "/*"
) を含めないでください。
グローバル ヘッダー
globalHeaders
セクションでは、ルート ヘッダー規則によってオーバーライドされない限り、各応答に適用される一連の HTTP ヘッダーが提供されます。それ以外の場合は、ルートからのヘッダーとグローバル ヘッダーの両方の和集合が返されます。
使用例については、「構成ファイルの例」を参照してください。
ヘッダーを削除するには、値を空の文字列 (""
) に設定します。
グローバル ヘッダーの一般的なユース ケースには、以下が含まれます。
- カスタム キャッシュ ルール
- セキュリティ ポリシーの適用
- エンコードの設定
- クロスオリジン リソース共有 (CORS) の構成
次の例では、カスタム CORS 構成を実装します。
{
"globalHeaders": {
"Access-Control-Allow-Origin": "https://example.com",
"Access-Control-Allow-Methods": "POST, GET, OPTIONS"
}
}
注意
グローバル ヘッダーは、API の応答には影響を与えません。 API 応答内のヘッダーは、保持されて、クライアントに返されます。
応答のオーバーライド
responseOverrides
セクションでは、サーバーからエラー コードが返される場合のカスタム応答を定義できます。 使用例については、「構成ファイルの例」を参照してください。
次の HTTP コードをオーバーライドできます。
状態コード | 説明 | 考えられる原因 |
---|---|---|
400 | 正しくない要求 | 無効な招待リンク |
401 | 権限がありません | 認証されていない状態での制限されたページへの要求 |
403 | Forbidden |
|
404 | 見つかりません | ファイルが見つからない |
次の構成例は、エラー コードをオーバーライドする方法を示しています。
{
"responseOverrides": {
"400": {
"rewrite": "/invalid-invitation-error.html"
},
"401": {
"statusCode": 302,
"redirect": "/login"
},
"403": {
"rewrite": "/custom-forbidden-page.html"
},
"404": {
"rewrite": "/custom-404.html"
}
}
}
プラットフォーム
platform
セクションでは、API 言語ランタイムのバージョンなど、プラットフォーム固有の設定を制御します。
API 言語ランタイムのバージョンの選択
API 言語ランタイムのバージョンを構成するには、platform
セクションの apiRuntime
プロパティを、サポートされている次の値のいずれかに設定します。
言語ランタイムのバージョン | オペレーティング システム | Azure Functions バージョン | apiRuntime 値 |
---|---|---|---|
.NET Core 3.1 | Windows | 3.x | dotnet:3.1 |
.NET 6.0 インプロセス | Windows | 4.x | dotnet:6.0 |
.NET 6.0 分離 | Windows | 4.x | dotnet-isolated:6.0 |
Node.js 12.x | Linux | 3.x | node:12 |
Node.js 14.x | Linux | 4.x | node:14 |
Node.js 16.x | Linux | 4.x | node:16 |
Python 3.8 | Linux | 3.x | python:3.8 |
Python 3.9 | Linux | 4.x | python:3.9 |
次の構成例では、apiRuntime
プロパティを使用して、API 言語ランタイムのバージョンとして Node.js 16 を選択する方法を示します。
{
"platform": {
"apiRuntime": "node:16"
}
}
ネットワーク
networking
セクションは、静的 Web アプリのネットワーク構成を制御します。 アプリへのアクセスを制限するには、allowedIpRanges
で許可される IP アドレス ブロックの一覧を指定します。
Note
ネットワーク構成は、Azure Static Web Apps Standard プランでのみ使用できます。
クラスレス ドメイン間ルーティング (CIDR) 表記で IPv4 アドレス ブロックを定義します。 CIDR 表記の詳細については、「クラスレス ドメイン間ルーティング」を参照してください。 各 IPv4 アドレス ブロックは、パブリック アドレス空間またはプライベート アドレス空間を表します。 1 つの IP アドレスからのアクセスのみを許可したい場合は、/32
CIDR ブロックを使用できます。
{
"networking": {
"allowedIpRanges": [
"10.0.0.0/24",
"100.0.0.0/32",
"192.168.100.0/22"
]
}
}
1 つ以上の IP アドレス ブロックが指定されている場合、allowedIpRanges
の値と一致しない IP アドレスからの要求はアクセスを拒否されます。
IP アドレス ブロックに加えて、allowedIpRanges
配列でサービス タグを指定して、特定の Azure サービスにトラフィックを制限することもできます。
"networking": {
"allowedIpRanges": ["AzureFrontDoor.Backend"]
}
認証
- 既定の認証プロバイダーには、構成ファイル内の設定が必要ありません。
- カスタム認証プロバイダーでは、設定ファイルの
auth
セクションが使用されます。
認証されたユーザーにルートを制限する方法の詳細については、「ロールを使用したルートのセキュリティ保護」を参照してください。
認証されたパスのキャッシュの無効化
Azure Front Door との手動統合を設定している場合は、セキュリティで保護されたルートのキャッシュを無効にすることをお勧めします。 エンタープライズレベルのエッジが有効になっている場合は、既に構成されています。
セキュリティで保護されたルートに対する Azure Front Door のキャッシュを無効にするには、ルート ヘッダーの定義に "Cache-Control": "no-store"
を追加します。
次に例を示します。
{
"route": "/members",
"allowedRoles": ["authenticated, members"],
"headers": {
"Cache-Control": "no-store"
}
}
転送ゲートウェイ
forwardingGateway
セクションでは、CDN や Azure Front Door などの転送ゲートウェイから静的 Web アプリにアクセスする方法を構成します。
Note
転送ゲートウェイの構成は、Azure Static Web Apps Standard プランでのみ使用できます。
許可された転送先ホスト
allowedForwardedHosts
リストでは、X-Forwarded-Host ヘッダーで受け入れるホスト名を指定します。 一致するドメインがリストにある場合は、ログインが成功した後など、リダイレクト URL が作成されるときに、Static Web Apps によって X-Forwarded-Host
の値が使用されます。
転送ゲートウェイの内側にある Static Web Apps が正しく機能するには、ゲートウェイからの要求の X-Forwarded-Host
ヘッダーに正しいホスト名が含まれ、同じホスト名が allowedForwardedHosts
のリストに存在する必要があります。
"forwardingGateway": {
"allowedForwardedHosts": [
"example.org",
"www.example.org",
"staging.example.org"
]
}
X-Forwarded-Host
ヘッダーがリストの値と一致しない場合でも、要求は成功しますが、ヘッダーは応答で使用されません。
必須ヘッダー
必須ヘッダーは、サイトへの要求ごとに送信される必要のある HTTP ヘッダーです。 必須ヘッダーの用途の 1 つは、すべての必須ヘッダーが各要求に存在しない場合、サイトへのアクセスを拒否することです。
たとえば、次の構成は、サイトへのアクセスを特定の Azure Front Door インスタンスに制限する Azure Front Door 用の一意の識別子を追加する方法を示したものです。 詳細については、Azure Front Door の構成に関するチュートリアルの記事を参照してください。
"forwardingGateway": {
"requiredHeaders": {
"X-Azure-FDID" : "692a448c-2b5d-4e4d-9fcc-2bc4a6e2335f"
}
}
- キーと値のペアは、どのような文字列のセットでもかまいません
- キーは、大文字と小文字が区別されません
- 値は、大文字と小文字が区別されます
末尾のスラッシュ
末尾のスラッシュは、URL の最後の /
です。 従来、末尾のスラッシュ URL は Web サーバー上のディレクトリを参照し、末尾のスラッシュ以外の URL はファイルを示します。
検索エンジンは、ファイルかディレクトリかに関係なく、2 つの URL を個別に扱います。 これらの両方の URL で同じコンテンツがレンダリングされると、Web サイトは重複するコンテンツを提供し、検索エンジンの最適化 (SEO) に悪影響を与える可能性があります。 明示的に構成されている場合、Azure Static Web Apps は、Web サイトのパフォーマンスと SEO の向上に役立つ一連の URL 正規化とリダイレクト ルールを適用します。
使用可能な構成ごとに、次の正規化とリダイレクト ルールが適用されます。
Always
trailingSlash
を always
に設定すると、末尾のスラッシュを含まないすべての要求が末尾のスラッシュ付き URL にリダイレクトされます。 たとえば、/contact
は /contact/
にリダイレクトされます。
"trailingSlash": "always"
要求先 | 返されるもの | 状態 | パス |
---|---|---|---|
/about | /about/index.html ファイル | 301 |
/about/ |
/about/ | /about/index.html ファイル | 200 |
/about/ |
/about/index.html | /about/index.html ファイル | 301 |
/about/ |
/contact | /contact.html ファイル | 301 |
/contact/ |
/contact/ | /contact.html ファイル | 200 |
/contact/ |
/contact.html | /contact.html ファイル | 301 |
/contact/ |
行わない
trailingSlash
を never
に設定すると、末尾のスラッシュ付きのすべての要求が末尾のスラッシュ無しの URL にリダイレクトされます。 たとえば、/contact/
は /contact
にリダイレクトされます。
"trailingSlash": "never"
要求先 | 返されるもの | 状態 | パス |
---|---|---|---|
/about | /about/index.html ファイル | 200 |
/about |
/about/ | /about/index.html ファイル | 301 |
/about |
/about/index.html | /about/index.html ファイル | 301 |
/about |
/contact | /contact.html ファイル | 200 |
/contact |
/contact/ | /contact.html ファイル | 301 |
/contact |
/contact.html | /contact.html ファイル | 301 |
/contact |
Auto
trailingSlash
を auto
に設定すると、フォルダーへのすべての要求が末尾のスラッシュを含む URL にリダイレクトされます。 ファイルに対するすべての要求は、末尾にスラッシュを含まない URL にリダイレクトされます。
"trailingSlash": "auto"
要求先 | 返されるもの | 状態 | パス |
---|---|---|---|
/about | /about/index.html ファイル | 301 |
/about/ |
/about/ | /about/index.html ファイル | 200 |
/about/ |
/about/index.html | /about/index.html ファイル | 301 |
/about/ |
/contact | /contact.html ファイル | 200 |
/contact |
/contact/ | /contact.html ファイル | 301 |
/contact |
/contact.html | /contact.html ファイル | 301 |
/contact |
Web サイトのパフォーマンスを最適にするには、always
、never
、auto
のいずれかのモードを使用して末尾のスラッシュの戦略を設定します。
既定では、trailingSlash
の設定を省略すると、Azure Static Web Apps は次の規則を適用します。
要求先 | 返されるもの | 状態 | パス |
---|---|---|---|
/about | /about/index.html ファイル | 200 |
/about |
/about/ | /about/index.html ファイル | 200 |
/about/ |
/about/index.html | /about/index.html ファイル | 200 |
/about/index.html |
/contact | /contact.html ファイル | 200 |
/contact |
/contact/ | /contact.html ファイル | 301 |
/contact |
/contact.html | /contact.html ファイル | 200 |
/contact.html |
構成ファイルの例
{
"routes": [
{
"route": "/profile*",
"allowedRoles": ["authenticated"]
},
{
"route": "/admin/index.html",
"allowedRoles": ["administrator"]
},
{
"route": "/images/*",
"headers": {
"cache-control": "must-revalidate, max-age=15770000"
}
},
{
"route": "/api/*",
"methods": ["GET"],
"allowedRoles": ["registeredusers"]
},
{
"route": "/api/*",
"methods": ["PUT", "POST", "PATCH", "DELETE"],
"allowedRoles": ["administrator"]
},
{
"route": "/api/*",
"allowedRoles": ["authenticated"]
},
{
"route": "/customers/contoso*",
"allowedRoles": ["administrator", "customers_contoso"]
},
{
"route": "/login",
"rewrite": "/.auth/login/github"
},
{
"route": "/.auth/login/twitter",
"statusCode": 404
},
{
"route": "/logout",
"redirect": "/.auth/logout"
},
{
"route": "/calendar*",
"rewrite": "/calendar.html"
},
{
"route": "/specials",
"redirect": "/deals",
"statusCode": 301
}
],
"navigationFallback": {
"rewrite": "index.html",
"exclude": ["/images/*.{png,jpg,gif}", "/css/*"]
},
"responseOverrides": {
"400": {
"rewrite": "/invalid-invitation-error.html"
},
"401": {
"redirect": "/login",
"statusCode": 302
},
"403": {
"rewrite": "/custom-forbidden-page.html"
},
"404": {
"rewrite": "/404.html"
}
},
"globalHeaders": {
"content-security-policy": "default-src https: 'unsafe-eval' 'unsafe-inline'; object-src 'none'"
},
"mimeTypes": {
".json": "text/json"
}
}
上記の構成に基づいて、次のシナリオを確認します。
要求先 | 結果 |
---|---|
/profile | 認証されたユーザーには、 /profile/index.html ファイルが提供されます。 認証されていないユーザーは401 応答の上書き規則によって /login にリダイレクトされます。 |
/admin、 /admin/、または /admin/index.html | administrator ロールの認証されたユーザーには、 /admin/index.html ファイルが提供されます。 administrator ロールに属していない認証されたユーザーには、403 エラーが返されます1。 認証されていないユーザーは /login にリダイレクトされます。 |
/images/logo.png | 最長有効期間が 182 日 (15,770,000 秒) を少し超えるカスタム キャッシュ規則を使用して画像を提供します。 |
/api/admin | registeredusers ロールの認証されたユーザーからの GET 要求は、API に送信されます。 registeredusers ロールに属していない認証されたユーザー、および認証されていないユーザーには、401 エラーが返されます。administrator ロールの認証されたユーザーからの POST 、PUT 、PATCH 、および DELETE 要求は、API に送信されます。 administrator ロールに属していない認証されたユーザー、および認証されていないユーザーには、401 エラーが返されます。 |
/customers/contoso | administrator または customers_contoso ロールに属している認証されたユーザーには、 /customers/contoso/index.html ファイルが提供されます。 administrator または customers_contoso ロールに属していない認証されたユーザーには、403 エラーが返されます1。 認証されていないユーザーは /login にリダイレクトされます。 |
/login | 認証されていないユーザーは、GitHub で認証するように求められます。 |
/.auth/login/twitter | Twitter での承認がルート規則によって無効になっているため、404 エラーが返されます。これにより、フォールバックされ、200 状態コードと共に /index.html が提供されます。 |
/logout | ユーザーは、すべての認証プロバイダーからログアウトされます。 |
/calendar/2021/01 | ブラウザーには、 /calendar.html ファイルが提供されます。 |
/specials | ブラウザーは、永続的に /deals にリダイレクトされます。 |
/data.json | MIME の種類 text/json で提供されるファイル。 |
/about、またはクライアント側のルーティング パターンに一致する任意のフォルダー | /index.html ファイルは、200 状態コードと共に提供されます。 |
/Images/ フォルダー内に存在しないファイル | 404 エラー。 |
1応答のオーバーライド規則を使用することにより、カスタム エラー ページを提供できます。
制限
staticwebapp.config.json ファイルには次の制限があります。
- 最大ファイル サイズは 20 KB です
- 最大 50 種類のロール
一般的な制限事項と限度については、クォータに関する記事を参照してください。