Configure hosting behavior

With Firebase Hosting, you can configure customized hosting behavior, including custom error pages, redirects, rewrites, and headers. You can also specify which files to deploy from your project directory to your Firebase project.

Define your Firebase Hosting configuration in your firebase.json file.

Find your firebase.json file in the root of your project directory. Firebase automatically creates your firebase.json file when you run the firebase init command.

You can find a full firebase.json configuration example (covering only Firebase Hosting) at the bottom of this page. Note that a firebase.json file can also contain configurations for other Firebase services.

Priority order of Hosting responses

The different Firebase Hosting configuration options described on this page can sometimes overlap. If there is a conflict, Hosting determines its response using the following priority order:

  1. Reserved namespaces that begin with a /__/* path segment
  2. Configured redirects
  3. Exact-match static content
  4. Configured rewrites
  5. Custom 404 page
  6. Default 404 page

Specify files to deploy

The default attributes — public and ignore — included in the default firebase.json file define which files in your project directory should be deployed to your Firebase project.

The default hosting configuration in a firebase.json file looks like this:

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

public

Required
The public attribute specifies which directory to deploy to Firebase Hosting. The default value is a directory named public, but you can specify any directory's path, as long as it exists in your project directory.

The following is the default specified name of the directory to deploy:

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

You can change the default value to the directory that you want to deploy:

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

ignore

Optional
The ignore attribute specifies the files to ignore on deploy. It can take glob pattern the same way that Git handles .gitignore.

The following are the default values for the files to ignore:

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

Customize a 404/Not Found page

Optional
You can serve a custom 404 Not Found error when a user tries to access a page that doesn't exist.

Create a new file in your project's public directory, name it 404.html, then add your custom 404 Not Found content to the file.

Firebase Hosting will display the content of this custom 404.html page if a browser triggers a 404 Not Found error on your domain or subdomain.

Configure redirects

Optional
Use a URL redirect to prevent broken links if you've moved a page or to shorten URLs. For example, you could redirect a browser from example.com/team to example.com/about.html.

Specify URL redirects by including a redirects attribute within hosting in your firebase.json file. For example:

"hosting": {
  // Add the "redirects" attribute within "hosting"
  "redirects": [ {
    "source": "/foo",
    "destination": "/bar",
    "type": 301
  }, {
    "source": "/firebase/*",
    "destination": "https://firebase.google.com/",
    "type": 302
  } ]
}

The redirects attribute contains an array of redirect rules, where each rule must include:

  • A source specifying a glob pattern

  • A destination, which is a static URL that can be a relative or an absolute path

  • A type specifying the HTTP response code

Firebase Hosting compares the source value against all URL paths at the start of every request (before the browser determines whether a file or folder exists at that path). If a match is found, then the Firebase Hosting origin server sends an HTTP redirect response telling the browswer to make a new request at the destination URL.

Finally, the type value specifies the specific HTTP response code served and can either be 301 for 'Moved Permanently' or 302 for 'Found' (Temporary Redirect).

Capture URL segments for redirects

Optional
Sometimes, you might need to capture specific segments of a redirect source URL, then re-use these segments in the redirect destination URL.

You can capture these segments by including a : prefix to identify the segment. If you also need to capture the remaining URL path after the segment, include a * immediately after the segment. For example:

"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 caputured by the "source" value
    "type": 301
  } ]
}

Configure rewrites

Optional
Use a rewrite to show the same content for multiple URLs. Rewrites are particularly useful with pattern matching, as you can accept any URL that matches the pattern and let the client-side code decide what to display.

You can also use rewrites to support apps that use HTML5 pushState for navigation. When a browser attempts to open a specified source URL, it will be given the contents of the file at the destination URL.

Specify URL rewrites by including a rewrites attribute within hosting in your firebase.json file. For example:

"hosting": {
  // Add the "rewrites" attribute within "hosting"
  "rewrites": [ {
    "source": "**",
    "destination": "/index.html"
  } ]
}

The rewrites attribute contains an array of rewrite rules, where each rule must include:

  • A source specifying a glob pattern

  • A destination, which is a local file that must exist

Firebase Hosting only applies a rewrite rule if a file or folder does not exist at the specified source. When a rule is triggered, the browser returns the actual content of the specified destination file instead of an HTTP redirect.

Configure headers

Optional
Headers allow the client and the server to pass additional information along with a request or a response. Some sets of headers can affect how the browser handles the page and its content, including access control, authentication, caching, and encoding.

Specify custom, file-specific response headers by including a headers attribute within hosting in your firebase.json file. For example:

"hosting": {
  // Add the "headers" attribute within "hosting"
  "headers": [ {
    // Specifies 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"
    } ]
  }, {
    // Sets the cache header for 404 pages to cache for 5 minutes
    "source": "404.html",
    "headers": [ {
      "key": "Cache-Control",
      "value": "max-age=300"
    } ]
  } ]
}

The headers attribute contains an array of definitions, where each definition must include:

  • A source value that Hosting matches against the original request path, regardless of any rewrite rules.

  • An array of (sub-)headers that Hosting applies to the request path; each sub-header array must include a specified key and a value.

You can learn more about Cache-Control in the Hosting section that describes serving dynamic content and hosting microservices with the use of Cloud Functions for Firebase.

You can also learn more about CORS headers.

Control .html extensions

Optional
The cleanUrls attribute allows you to control whether or not URLs should include the .html extension.

When true, Hosting automatically drops the .html extension from uploaded file URLs. If an .html extension is added in the request, Hosting performs a 301 redirect to the same path but eliminates the .html extension.

Specify the inclusion of .html extensions by including a cleanUrls attribute within hosting in your firebase.json file. For example:

"hosting": {
  // Add the "cleanUrls" attribute within "hosting"
  "cleanUrls": true
}

Control trailing slashes

Optional
The trailingSlash attribute allows you to control whether or not URLs should include trailing slashes.

  • When true, Hosting redirects URLs to add a trailing slash.
  • When false, Hosting redirects URLs to remove a trailing slash.
  • When unspecified, Hosting only uses trailing slashes for directory index files (for example, about/index.html).

Specify the inclusion of trailing slashes by including a trailingSlash attribute within hosting in your firebase.json file. For example:

"hosting": {
  // Add the "trailingSlash" attribute within "hosting"
  "trailingSlash": false
}

Glob pattern matching

Firebase Hosting configuration options make extensive use of the glob pattern matching notation with extglob, similar to how Git handles gitignore rules and Bower handles ignore rules. This wiki page is a more detailed reference, but the following are explanations of examples used on this page:

  • firebase.json — Only matches the firebase.json file in the root of the public directory

  • ** — Matches any file or folder in an arbitrary sub-directory

  • * — Only matches files and folders in the root of the public directory

  • **/.* — Matches any file beginning with . (usually hidden files, like in the .git folder) in an arbitrary sub-directory

  • **/node_modules/** — Matches any file or folder in an arbitrary sub-directory of a node_modules folder, which can itself be in an arbitrary sub-directory of the public directory

  • **/*.@(jpg|jpeg|gif|png) — Matches any file in an arbitrary sub-directory that ends with exactly one of the following: .jpg, .jpeg, .gif, or .png

Full Hosting configuration example

The following is a full firebase.json configuration example for Firebase Hosting. Note that a firebase.json file can also contain configurations for other Firebase services.

{
  "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": [ {
      "source": "/app/**",
      "destination": "/app/index.html"
    } ],

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

Оставить отзыв о...

Текущей странице
Нужна помощь? Обратитесь в службу поддержки.