پیکربندی رفتار میزبانی

با Firebase Hosting ، می‌توانید رفتار میزبانی سفارشی را برای درخواست‌های ارسالی به سایت خود پیکربندی کنید.

چه چیزی را می‌توانید برای Hosting پیکربندی کنید؟

• مشخص کنید که می‌خواهید کدام فایل‌ها را در دایرکتوری پروژه محلی خود در Firebase Hosting مستقر کنید. نحوه‌ی انجام این کار را بیاموزید.

• یک صفحه خطای ۴۰۴/یافت نشد سفارشی ارائه دهید. یاد بگیرید چگونه.

• برای صفحاتی که منتقل یا حذف کرده‌اید، redirects تنظیم کنید. نحوه انجام آن را بیاموزید.

• برای هر یک از این اهداف rewrites تنظیم کنید:

  • نمایش محتوای یکسان برای چندین URL. نحوه انجام آن را بیاموزید.

  • یک تابع را ارائه دهید یا از طریق یک آدرس اینترنتی Hosting به یک کانتینر Cloud Run دسترسی پیدا کنید. نحوه‌ی کار را بیاموزید: تابع یا کانتینر .

  • ایجاد یک Dynamic Link دامنه سفارشی. نحوه انجام آن را بیاموزید.

• برای ارسال اطلاعات اضافی در مورد یک درخواست یا پاسخ، مانند نحوه برخورد مرورگرها با صفحه و محتوای آن (احراز هویت، ذخیره‌سازی، رمزگذاری و غیره)، headers اضافه کنید. نحوه انجام این کار را بیاموزید.

• بازنویسی‌های بین‌المللی‌سازی (i18n) را برای ارائه محتوای خاص بر اساس ترجیح زبان و/یا کشور کاربر تنظیم کنید. نحوه انجام آن را بیاموزید (صفحه متفاوت).

پیکربندی Hosting خود را کجا تعریف می‌کنید؟

شما پیکربندی Firebase Hosting خود را در فایل firebase.json تعریف می‌کنید. Firebase هنگام اجرای دستور firebase init ، به طور خودکار فایل firebase.json شما را در ریشه دایرکتوری پروژه‌تان ایجاد می‌کند.

می‌توانید یک نمونه کامل از پیکربندی firebase.json (که فقط شامل Firebase Hosting می‌شود) را در پایین این صفحه پیدا کنید. توجه داشته باشید که یک فایل firebase.json می‌تواند شامل پیکربندی‌هایی برای سایر سرویس‌های Firebase نیز باشد.

می‌توانید محتوای firebase.json پیاده‌سازی‌شده را با استفاده از Hosting REST API بررسی کنید.

ترتیب اولویت پاسخ‌های Hosting

گزینه‌های مختلف پیکربندی Firebase Hosting که در این صفحه توضیح داده شده‌اند، گاهی اوقات می‌توانند با هم همپوشانی داشته باشند. در صورت وجود تداخل، Hosting پاسخ خود را با استفاده از ترتیب اولویت زیر تعیین می‌کند:

1. فضاهای نام رزرو شده که با بخش مسیر /__/* شروع می‌شوند
2. تغییر مسیرهای پیکربندی شده
3. محتوای استاتیک با تطابق دقیق
4. بازنویسی‌های پیکربندی‌شده
5. صفحه ۴۰۴ سفارشی
6. صفحه پیش‌فرض ۴۰۴

اگر از بازنویسی‌های i18n استفاده می‌کنید، ترتیب اولویت تطابق دقیق و مدیریت خطای ۴۰۴ گسترش می‌یابد تا با «محتوای i18n» شما سازگار شود.

مشخص کنید کدام فایل‌ها را باید مستقر کنید

ویژگی‌های پیش‌فرض - public و ignore - که در فایل پیش‌فرض firebase.json قرار دارند، مشخص می‌کنند که کدام فایل‌های موجود در دایرکتوری پروژه شما باید در پروژه Firebase شما مستقر شوند.

پیکربندی پیش‌فرض hosting در فایل firebase.json به این شکل است:

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

عمومی

مورد نیاز
ویژگی public مشخص می‌کند که کدام دایرکتوری برای Firebase Hosting مستقر شود. مقدار پیش‌فرض، دایرکتوری به نام public است، اما می‌توانید مسیر هر دایرکتوری را مشخص کنید، مادامی که در دایرکتوری پروژه شما وجود داشته باشد.

نام پیش‌فرض دایرکتوری که باید مستقر شود به صورت زیر است:

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

  // ...
}

می‌توانید مقدار پیش‌فرض را به دایرکتوری که می‌خواهید مستقر کنید تغییر دهید:

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

  // ...
}

نادیده گرفتن

اختیاری
ویژگی ignore فایل‌هایی را که باید در هنگام استقرار نادیده گرفته شوند، مشخص می‌کند. این ویژگی می‌تواند globها را به همان روشی که Git با .gitignore رفتار می‌کند، بپذیرد.

مقادیر پیش‌فرض برای نادیده گرفتن فایل‌ها به شرح زیر است:

"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 نمایش دهید.

یک فایل جدید در دایرکتوری public پروژه خود ایجاد کنید، نام آن را 404.html بگذارید، سپس محتوای سفارشی 404 Not Found خود را به فایل اضافه کنید.

اگر مرورگری خطای 404 Not Found را در دامنه یا زیر دامنه شما نشان دهد، Firebase Hosting محتوای این صفحه 404.html سفارشی را نمایش می‌دهد.

پیکربندی تغییر مسیرها

اختیاری
اگر صفحه‌ای را جابه‌جا کرده‌اید، برای جلوگیری از لینک‌های خراب یا کوتاه کردن URLها از ریدایرکت URL استفاده کنید. برای مثال، می‌توانید مرورگر را از example.com/team به example.com/about.html ریدایرکت کنید.

با ایجاد یک ویژگی redirects که شامل آرایه‌ای از اشیاء (به نام "قوانین redirect") است، ریدایرکت‌های URL را مشخص کنید. در هر قانون، یک الگوی URL مشخص کنید که در صورت مطابقت با مسیر URL درخواستی، Hosting وادار به ریدایرکت به URL مقصد مشخص شده کند.

ساختار اولیه برای ویژگی redirects به این صورت است. این مثال با ارسال یک درخواست جدید به /bar درخواست‌ها را به /foo هدایت می‌کند.

"hosting": {
  // ...

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

"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 شامل آرایه‌ای از قوانین redirect است که هر قانون باید شامل فیلدهای جدول زیر باشد.

Firebase Hosting در ابتدای هر درخواست (قبل از اینکه مرورگر تشخیص دهد که آیا فایل یا پوشه‌ای در آن مسیر وجود دارد یا خیر)، مقدار source یا regex را با تمام مسیرهای URL مقایسه می‌کند. اگر تطابقی پیدا شود، سرور مبدا Firebase Hosting یک پاسخ تغییر مسیر HTTPS ارسال می‌کند و به مرورگر می‌گوید که درخواست جدیدی را در URL destination ایجاد کند.

بخش‌های URL را برای تغییر مسیرها ضبط کنید

اختیاری
گاهی اوقات، ممکن است لازم باشد بخش‌های خاصی از الگوی URL یک قانون تغییر مسیر (مقدار source یا regex ) را ثبت کنید، سپس از این بخش‌ها در مسیر destination قانون دوباره استفاده کنید.

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

"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 ای را که با الگو مطابقت دارد بپذیرید و اجازه دهید کد سمت کلاینت تصمیم بگیرد چه چیزی را نمایش دهد.

همچنین می‌توانید از بازنویسی‌ها برای پشتیبانی از برنامه‌هایی که از pushState HTML5 برای ناوبری استفاده می‌کنند، استفاده کنید. وقتی یک مرورگر سعی می‌کند یک مسیر URL را که با الگوی URL source یا regex مشخص شده مطابقت دارد، باز کند، به جای آن، محتوای فایل در URL destination به مرورگر داده می‌شود.

با ایجاد یک ویژگی rewrites که شامل آرایه‌ای از اشیاء است (به نام "قوانین rewrite") بازنویسی‌های 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"
  } ]
}

"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 شامل آرایه‌ای از قوانین rewrite است که هر قانون باید شامل فیلدهای جدول زیر باشد.

Firebase Hosting فقط در صورتی قانون بازنویسی را اعمال می‌کند که فایل یا دایرکتوری در مسیر URL که با الگوی URL source یا regex مشخص شده مطابقت دارد، وجود نداشته باشد. هنگامی که یک درخواست، قانون بازنویسی را فعال می‌کند، مرورگر به جای تغییر مسیر HTTP، محتوای واقعی فایل destination مشخص شده را برمی‌گرداند.

درخواست‌های مستقیم به یک تابع

شما می‌توانید از rewrites برای ارائه یک تابع از یک URL Firebase Hosting استفاده کنید. مثال زیر گزیده‌ای از ارائه محتوای پویا با استفاده از Cloud Functions است.

برای مثال، برای هدایت تمام درخواست‌ها از صفحه /bigben در سایت Hosting خود به اجرای تابع bigben :

"hosting": {
  // ...

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

پس از افزودن این قانون بازنویسی و استقرار در Firebase (با استفاده از firebase deploy )، تابع شما از طریق URL های زیر قابل دسترسی است:

• زیر دامنه‌های فایربیس شما:
  PROJECT_ID .web.app/bigben و PROJECT_ID .firebaseapp.com/bigben

• هر دامنه سفارشی متصل:
  CUSTOM_DOMAIN /bigben

وقتی Firebase Hosting ترافیک را به یک تابع ارسال می‌کند، تابع مسیر درخواست و رشته پرس‌وجوی کامل اصلی را دریافت می‌کند. برای مثال، درخواستی به /bigben/hello/world?foo=bar در سایت Hosting شما با مسیر کامل و پرس‌وجوی دست‌نخورده به تابع ارسال می‌شود. مطمئن شوید که کنترل‌کننده تابع شما طوری نوشته شده است که کل URL مطلق را مدیریت کند، نه فقط مسیر پایه تعریف‌شده در بازنویسی.

هنگام هدایت درخواست‌ها به توابع با Hosting ، روش‌های درخواست HTTP پشتیبانی‌شده عبارتند از GET ، POST ، HEAD ، PUT ، DELETE ، PATCH و OPTIONS . روش‌های دیگر مانند REPORT یا PROFIND پشتیبانی نمی‌شوند.

درخواست‌های مستقیم به یک کانتینر Cloud Run

شما می‌توانید از rewrites برای دسترسی به یک کانتینر Cloud Run از طریق URL Firebase Hosting استفاده کنید. مثال زیر گزیده‌ای از ارائه محتوای پویا با استفاده از Cloud Run است.

برای مثال، برای هدایت تمام درخواست‌ها از صفحه /helloworld در سایت Hosting خود به منظور راه‌اندازی و اجرای یک نمونه کانتینر 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 های زیر قابل دسترسی است:

• زیر دامنه‌های فایربیس شما:
  PROJECT_ID .web.app/helloworld و PROJECT_ID .firebaseapp.com/helloworld

• هر دامنه سفارشی متصل:
  CUSTOM_DOMAIN /helloworld

هنگام هدایت درخواست‌ها به کانتینرهای Cloud Run با Hosting ، روش‌های درخواست HTTP پشتیبانی‌شده عبارتند از GET ، POST ، HEAD ، PUT ، DELETE ، PATCH و OPTIONS . روش‌های دیگر مانند REPORT یا PROFIND پشتیبانی نمی‌شوند.

برای بهترین عملکرد، سرویس Cloud Run خود را با Hosting با استفاده از مناطق زیر در یک مکان قرار دهید:

• us-west1
• us-central1
• us-east1
• europe-west1
• asia-east1

بازنویسی‌ها به Cloud Run از Hosting در مناطق زیر پشتیبانی می‌شوند:

• asia-east1
• asia-east2
• asia-northeast1
• asia-northeast2
• asia-northeast3
• asia-south1
• asia-south2
• asia-southeast1
• asia-southeast2
• australia-southeast1
• australia-southeast2
• europe-central2
• europe-north1
• europe-southwest1
• europe-west1
• europe-west12
• europe-west2
• europe-west3
• europe-west4
• europe-west6
• europe-west8
• europe-west9
• me-central1
• me-west1
• northamerica-northeast1
• northamerica-northeast2
• southamerica-east1
• southamerica-west1
• us-central1
• us-east1
• us-east4
• us-east5
• us-south1
• us-west1
• us-west2
• us-west3
• us-west4
• us-west1
• us-central1
• us-east1
• europe-west1
• asia-east1

ایجاد 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
    } ]
  }

پیکربندی Dynamic Links در فایل firebase.json شما به موارد زیر نیاز دارد:

پیکربندی هدرها

اختیاری
هدرها به کلاینت و سرور اجازه می‌دهند تا اطلاعات اضافی را به همراه یک درخواست یا پاسخ ارسال کنند. برخی از مجموعه هدرها می‌توانند بر نحوه مدیریت صفحه و محتوای آن توسط مرورگر، از جمله کنترل دسترسی، احراز هویت، ذخیره‌سازی و رمزگذاری، تأثیر بگذارند.

با ایجاد یک ویژگی headers که شامل آرایه‌ای از اشیاء هدر است، هدرهای پاسخ سفارشی و مختص فایل را مشخص کنید. در هر شیء، یک الگوی URL مشخص کنید که در صورت مطابقت با مسیر URL درخواست، Hosting برای اعمال هدرهای پاسخ سفارشی مشخص شده فعال کند.

ساختار اولیه برای ویژگی 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": "*"
    } ]
  } ]
}

"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 شامل آرایه‌ای از تعاریف است که هر تعریف باید شامل فیلدهای جدول زیر باشد.

می‌توانید در بخش Hosting که به ارائه محتوای پویا و میزبانی میکروسرویس‌ها می‌پردازد، اطلاعات بیشتری در مورد Cache-Control کسب کنید. همچنین می‌توانید در مورد هدرهای CORS اطلاعات بیشتری کسب کنید.

کنترل پسوندهای .html

اختیاری
ویژگی cleanUrls به شما امکان می‌دهد کنترل کنید که آیا URLها باید شامل پسوند .html باشند یا خیر.

وقتی true ، Hosting به طور خودکار پسوند .html را از آدرس‌های اینترنتی فایل‌های آپلود شده حذف می‌کند. اگر پسوند .html در درخواست اضافه شود، Hosting یک ریدایرکت 301 به همان مسیر انجام می‌دهد اما پسوند .html را حذف می‌کند.

در اینجا نحوه کنترل گنجاندن .html در URL ها با استفاده از ویژگی cleanUrls آورده شده است:

"hosting": {
  // ...

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

کنترل اسلش‌های انتهایی

اختیاری
ویژگی trailingSlash به شما امکان می‌دهد کنترل کنید که آیا URLهای محتوای استاتیک باید شامل اسلش‌های انتهایی باشند یا خیر.

• وقتی true ، Hosting آدرس‌های اینترنتی را به یک اسلش انتهایی هدایت می‌کند.
• وقتی false ، Hosting آدرس‌های اینترنتی را تغییر مسیر می‌دهد تا علامت اسلش انتهایی را حذف کند.
• وقتی مشخص نشده باشد، Hosting فقط از اسلش‌های انتهایی برای فایل‌های فهرست دایرکتوری استفاده می‌کند (برای مثال، about/index.html ).

در اینجا نحوه کنترل اسلش‌های انتهایی با اضافه کردن یک ویژگی trailingSlash آورده شده است:

"hosting": {
  // ...

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

ویژگی trailingSlash بر بازنویسی محتوای پویا که توسط Cloud Functions یا Cloud Run ارائه می‌شود، تأثیری ندارد.

تطبیق الگوی سراسری

گزینه‌های پیکربندی Firebase Hosting به طور گسترده از نمادگذاری تطبیق الگوی glob با extglob استفاده می‌کنند، مشابه نحوه مدیریت قوانین gitignore توسط Git و مدیریت قوانین ignore توسط Bower . این صفحه ویکی مرجع دقیق‌تری است، اما در ادامه توضیحاتی در مورد مثال‌های استفاده شده در این صفحه آمده است:

• firebase.json - فقط با فایل firebase.json در ریشه دایرکتوری public مطابقت دارد.

• ** — با هر فایل یا پوشه‌ای در یک زیرشاخه دلخواه مطابقت دارد

• * — فقط با فایل‌ها و پوشه‌های موجود در ریشه دایرکتوری public مطابقت دارد

• **/.* — با هر فایلی که با . شروع می‌شود (معمولاً فایل‌های مخفی، مانند پوشه .git ) در یک زیرشاخه دلخواه مطابقت دارد.

• **/node_modules/** — با هر فایل یا پوشه‌ای در یک زیرشاخه دلخواه از پوشه node_modules مطابقت دارد، که خود آن پوشه می‌تواند در یک زیرشاخه دلخواه از دایرکتوری public باشد.

• **/*.@(jpg|jpeg|gif|png) ‎ — با هر فایلی در یک زیرشاخه دلخواه که دقیقاً با یکی از موارد زیر خاتمه می‌یابد، مطابقت دارد: .jpg ، .jpeg ، .gif یا .png

مثال کامل پیکربندی Hosting

در ادامه یک مثال کامل از پیکربندی firebase.json برای Firebase Hosting آمده است. توجه داشته باشید که یک فایل 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",

  }
}