С помощью Firebase Hosting вы можете настроить индивидуальное поведение хостинга для запросов к вашему сайту.
Что можно настроить для Hosting ?
Укажите, какие файлы в локальном каталоге проекта вы хотите развернуть на Firebase Hosting . Узнайте, как.
Подавайте персонализированную страницу 404/Not Found. Узнайте, как.
Настройте
redirects
для страниц, которые вы переместили или удалили. Узнайте, как.Настройте
rewrites
для любой из следующих целей:Показывать один и тот же контент для нескольких URL. Узнайте как.
Выполнить функцию или получить доступ к контейнеру Cloud Run с URL-адреса Hosting . Узнайте, как: функция или контейнер .
Создайте собственный домен Dynamic Link . Узнайте как.
Добавьте
headers
для передачи дополнительной информации о запросе или ответе, например, о том, как браузеры должны обрабатывать страницу и ее содержимое (аутентификация, кэширование, кодирование и т. д.). Узнайте, как это сделать.Настройте интернационализацию (i18n) для переписывания определенного контента на основе языковых предпочтений пользователя и/или страны. Узнайте, как (другая страница).
Где вы определяете конфигурацию Hosting ?
Вы определяете конфигурацию Firebase Hosting в файле firebase.json
. Firebase автоматически создает ваш файл firebase.json
в корне каталога вашего проекта, когда вы запускаете команду firebase init
.
Вы можете найти полный пример конфигурации firebase.json
(охватывающий только Firebase Hosting ) внизу этой страницы. Обратите внимание, что файл firebase.json
может также содержать конфигурации для других служб Firebase .
Вы можете проверить развернутое содержимое firebase.json
с помощью REST API Hosting .
Приоритетный порядок ответов Hosting
Различные параметры конфигурации Firebase Hosting , описанные на этой странице, иногда могут перекрываться. Если возникает конфликт, Hosting определяет свой ответ, используя следующий порядок приоритетов:
- Зарезервированные пространства имен, начинающиеся с сегмента пути
/__/*
- Настроенные перенаправления
- Точное соответствие статическому контенту
- Настроенные переписывания
- Пользовательская страница 404
- Страница 404 по умолчанию
Если вы используете i18n-перезаписи , порядок приоритета точного соответствия и обработки ошибки 404 расширяется, чтобы учесть ваш «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
указывает файлы, которые нужно игнорировать при развертывании. Он может принимать globs таким же образом, как 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/Не найдено
Необязательный
Вы можете отображать пользовательскую ошибку 404 Not Found
когда пользователь пытается получить доступ к несуществующей странице.
Создайте новый файл в public
каталоге вашего проекта, назовите его 404.html
, затем добавьте в файл свой пользовательский контент 404 Not Found
.
Firebase Hosting отобразит содержимое этой пользовательской страницы 404.html
, если браузер выдаст ошибку 404 Not Found
на вашем домене или поддомене.
Настроить перенаправления
Необязательный
Используйте перенаправление URL, чтобы предотвратить появление неработающих ссылок, если вы переместили страницу, или чтобы сократить URL. Например, вы можете перенаправить браузер с example.com/team
на example.com/about.html
.
Укажите URL-перенаправления, создав атрибут redirects
, содержащий массив объектов (называемый «правилами перенаправления»). В каждом правиле укажите шаблон URL, который, если соответствует пути URL-адреса запроса, заставляет Hosting отвечать перенаправлением на указанный целевой 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
} ]
}
"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-адресом исходного запроса, заставляет Hosting применить перенаправление.
| |
destination | Статический URL, по которому браузер должен сделать новый запрос. Этот URL-адрес может быть относительным или абсолютным путем. | |
type | Код ответа HTTPS
|
Захват сегментов URL для перенаправлений
Необязательный
Иногда вам может потребоваться захватить определенные сегменты шаблона URL-адреса правила перенаправления ( source
или regex
значение), а затем повторно использовать эти сегменты в destination
пути правила.
Если вы используете поле source
(то есть указываете глоб для шаблона URL), вы можете захватывать сегменты, включая префикс :
для идентификации сегмента. Если вам также нужно захватывать оставшийся путь 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 } ] }
Если вы используете поле regex
(то есть указываете регулярное выражение RE2 для шаблона URL), вы можете захватывать сегменты, используя как именованные, так и неименованные группы захвата 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 для навигации. Когда браузер пытается открыть URL-путь, который соответствует указанному source
или regex
шаблону URL, браузеру будет предоставлено содержимое файла по destination
URL.
Укажите URL-перезаписи, создав атрибут rewrites
, содержащий массив объектов (называемый «правилами перезаписи»). В каждом правиле укажите шаблон 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
содержит массив правил перезаписи, где каждое правило должно включать поля из таблицы ниже.
Firebase Hosting применяет правило перезаписи только в том случае, если файл или каталог не существует по URL-пути, который соответствует указанному source
или шаблону URL-адреса regex
. Когда запрос запускает правило перезаписи, браузер возвращает фактическое содержимое указанного destination
файла вместо HTTP-перенаправления.
Поле | Описание | |
---|---|---|
rewrites | ||
source (рекомендуется)или regex | Шаблон URL, который, если совпадает с исходным URL-адресом запроса, заставляет Hosting применить перезапись
| |
destination | Локальный файл, который должен существовать Этот URL-адрес может быть относительным или абсолютным путем. |
Прямые запросы к функции
Вы можете использовать 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)
}
} ]
}
Если
region
не указан вfunction
блоке конфигурацииhosting.rewrites
, Firebase CLI пытается автоматически определить регион из исходного кода функции, который, если не указан, по умолчанию равенus-central1
. Если исходный код функции недоступен, CLI пытается определить регион из развернутой функции. Если функция находится в нескольких регионах, CLI требует, чтобыregion
был указан в конфигурацииhosting.rewrites
.
Функция
pinTag
доступна только в Cloud Functions for Firebase (2nd gen). С помощью этой функции вы можете быть уверены, что каждая функция для генерации динамического контента вашего сайта синхронизирована с вашими статическими ресурсами Hosting и конфигурацией Hosting . Кроме того, эта функция позволяет вам предварительно просматривать ваши перезаписи функций на каналах предварительного просмотра Hosting .Если вы добавите
"pinTag": true
вfunction
блок конфигурацииhosting.rewrites
, то функция "pinned" будет развернута вместе с вашими статическими ресурсами Hosting и конфигурацией, даже при запуске. Если вы откатите версию своего сайта, функция "pinned" также откатится.
firebase deploy --only hosting Эта функция основана на тегах Cloud Run , которые имеют ограничение в 1000 тегов на сервис и 2000 тегов на регион. Это означает, что после сотен развертываний самые старые версии сайта могут перестать работать.
После добавления этого правила перезаписи и развертывания в 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
для доступа к контейнеру Cloud Run из Firebase Hosting URL. Следующий пример представляет собой отрывок из обслуживания динамического контента с помощью 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)
}
} ]
}
С помощью этой функции вы можете гарантировать, что ревизия вашего сервиса Cloud Run для генерации динамического контента вашего сайта будет синхронизирована с вашими статическими ресурсами Hosting и конфигурацией Hosting . Кроме того, эта функция позволяет вам предварительно просматривать ваши переписывания в каналах предварительного просмотра Cloud Run Hosting .
Если вы добавите
"pinTag": true
в блокrun
конфигурацииhosting.rewrites
, ваши статические ресурсы и конфигурация Hosting будут закреплены на последней версии сервиса Cloud Run во время развертывания. Если вы откатите версию своего сайта, то также откатится и версия "закрепленного" сервиса Cloud Run .Эта функция основана на тегах Cloud Run , которые имеют ограничение в 1000 тегов на сервис и 2000 тегов на регион. Это означает, что после сотен развертываний самые старые версии сайта могут перестать работать.
После добавления этого правила перезаписи и развертывания в Firebase (с помощью firebase deploy
) ваш образ контейнера станет доступен по следующим URL-адресам:
Ваши поддомены Firebase:
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
необходимо следующее:
Поле | Описание | |
---|---|---|
appAssociation | Необходимо установить значение
| |
rewrites | ||
source | Путь, который вы хотите использовать для Dynamic Links В отличие от правил, которые переписывают пути в URL-адреса, правила перезаписи для Dynamic Links не могут содержать регулярные выражения. | |
dynamicLinks | Должно быть установлено значение true |
Настроить заголовки
Необязательный
Заголовки позволяют клиенту и серверу передавать дополнительную информацию вместе с запросом или ответом. Некоторые наборы заголовков могут влиять на то, как браузер обрабатывает страницу и ее содержимое, включая контроль доступа, аутентификацию, кэширование и кодирование.
Укажите пользовательские, специфичные для файла заголовки ответа, создав атрибут 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
содержит массив определений, где каждое определение должно включать поля из таблицы ниже.
Поле | Описание | ||
---|---|---|---|
headers | |||
source (рекомендуется)или regex | Шаблон URL, который, если совпадает с URL-адресом исходного запроса, заставляет Hosting применять пользовательский заголовок.
Чтобы создать заголовок, соответствующий вашей пользовательской странице 404 , используйте | ||
массив (под-) headers | Пользовательские заголовки, которые Hosting применяет к пути запроса Каждый подзаголовок должен включать пару | ||
key | Имя заголовка, например Cache-Control | ||
value | Значение заголовка, например max-age=7200 |
Подробнее о Cache-Control
можно узнать в разделе Hosting , где описывается обслуживание динамического контента и размещение микросервисов. Также можно узнать больше о заголовках CORS .
Управление расширениями .html
Необязательный
Атрибут cleanUrls
позволяет контролировать, должны ли URL-адреса включать расширение .html
.
Если true
, Hosting автоматически удаляет расширение .html
из URL-адресов загруженных файлов. Если в запросе добавлено расширение .html
, Hosting выполняет перенаправление 301
на тот же путь, но удаляет расширение .html
.
Вот как контролировать включение .html
в URL-адреса с помощью атрибута cleanUrls
:
"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 .
Сопоставление шаблонов глобусов
Параметры конфигурации Firebase Hosting широко используют нотацию соответствия шаблону glob с extglob, подобно тому, как Git обрабатывает правила gitignore
, а Bower обрабатывает правила ignore
. Эта страница вики является более подробным справочником, но ниже приведены пояснения примеров, используемых на этой странице:
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",
}
}