होस्टिंग व्यवहार को कॉन्फ़िगर करें

Firebase Hosting की मदद से, अपनी साइट पर किए गए अनुरोधों के लिए, होस्टिंग के व्यवहार को पसंद के मुताबिक कॉन्फ़िगर किया जा सकता है.

Hosting के लिए क्या कॉन्फ़िगर किया जा सकता है?

• बताएं कि आपको अपनी लोकल प्रोजेक्ट डायरेक्ट्री में किन फ़ाइलों को डिप्लॉय करना है Firebase Hosting. इसका तरीका जानें.

• अपनी पसंद के मुताबिक बनाया गया 404/Not Found पेज दिखाएं. इसका तरीका जानें.

• जिन पेजों को आपने माइग्रेट किया है या मिटा दिया है उनके लिए, redirects सेट अप करें. इसका तरीका जानें.

• इनमें से किसी भी मकसद के लिए rewrites सेट अप करें:

  • कई यूआरएल के लिए एक ही कॉन्टेंट दिखाएं. इसका तरीका जानें.

  • कोई फ़ंक्शन इस्तेमाल करें या Hosting से Cloud Run कंटेनर ऐक्सेस करें यूआरएल. इसका तरीका जानें: फ़ंक्शन या कंटेनर.

  • कस्टम डोमेन बनाएं Dynamic Link. इसका तरीका जानें.

• किसी अनुरोध के बारे में ज़्यादा जानकारी देने के लिए headers जोड़ें या रिस्पॉन्स, जैसे कि ब्राउज़र को पेज और उसके कॉन्टेंट को किस तरह हैंडल करना चाहिए (पुष्टि करना, कैश मेमोरी, कोड में बदलने का तरीका वगैरह). इसका तरीका जानें.

• कॉन्टेंट के हिसाब से खास कॉन्टेंट दिखाने के लिए, इंटरनैशनलाइज़ेशन (i18n) रीराइट सेट अप करना उपयोगकर्ता की भाषा प्राथमिकता और/या देश पर. इसका तरीका जानें (दूसरा पेज).

Hosting का कॉन्फ़िगरेशन कहां तय किया जाता है?

आप इसमें अपना Firebase Hosting कॉन्फ़िगरेशन तय करते हैं firebase.json फ़ाइल. Firebase आपके प्रोजेक्ट के रूट पर, आपकी firebase.json फ़ाइल अपने-आप बनाता है डायरेक्ट्री को तब इस्तेमाल किया जाता है, जब firebase init निर्देश.

आप firebase.json कॉन्फ़िगरेशन का पूरा उदाहरण (सिर्फ़ Firebase Hosting को कवर करती है). ध्यान दें कि firebase.json फ़ाइल में ये चीज़ें भी शामिल हो सकती हैं अन्य Firebase सेवाओं के लिए कॉन्फ़िगरेशन.

डिप्लॉय किए गए firebase.json कॉन्टेंट को देखने के लिए, इनका इस्तेमाल करें: Hosting REST API.

Hosting जवाबों का प्राथमिकता क्रम

इस पेज पर बताए गए Firebase Hosting कॉन्फ़िगरेशन के अलग-अलग विकल्प, कभी-कभी ओवरलैप हो सकते हैं. अगर कोई विरोध होता है, तो Hosting प्राथमिकता के इस क्रम का इस्तेमाल करके जवाब तय करता है:

1. रिज़र्व किए गए ऐसे नेमस्पेस जो /__/* पाथ सेगमेंट से शुरू होते हैं
2. कॉन्फ़िगर किए गए रीडायरेक्ट
3. एग्ज़ैक्ट मैच वाला स्टैटिक कॉन्टेंट
4. फिर से लिखने के लिए कॉन्फ़िगर किया गया
5. कस्टम 404 पेज
6. डिफ़ॉल्ट 404 पेज

अगर i18n रीराइट का इस्तेमाल किया जा रहा है, तो पूरी तरह मेल खाने वाली वैल्यू और 404 हैंडलिंग प्राथमिकता क्रम को आपके "i18n" के दायरे में बढ़ाया गया है कॉन्टेंट".

यह तय करना कि कौनसी फ़ाइलें डिप्लॉय करनी हैं

public और ignore डिफ़ॉल्ट एट्रिब्यूट शामिल किए गए हैं डिफ़ॉल्ट firebase.json फ़ाइल में सेट करती है कि आपकी प्रोजेक्ट निर्देशिका में कौन-सी फ़ाइलें हैं को आपके Firebase प्रोजेक्ट में डिप्लॉय किया जाना चाहिए.

firebase.json फ़ाइल में डिफ़ॉल्ट hosting कॉन्फ़िगरेशन इस तरह दिखता है:

"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 एट्रिब्यूट उन फ़ाइलों के बारे में बताता है जिन्हें डिप्लॉय नहीं करना है. यह लग सकता है ग्लब को उसी तरह से इस्तेमाल करते हैं 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 गड़बड़ी ट्रिगर होती है.

रीडायरेक्ट कॉन्फ़िगर करना

ज़रूरी नहीं है
अगर आपने किसी पेज को दूसरी जगह पर ले जाया है, तो काम न करने वाले लिंक को रोकने के लिए, यूआरएल रीडायरेक्ट का इस्तेमाल करें या यूआरएल को छोटा करने के लिए किया जा सकता है. उदाहरण के लिए, आप ब्राउज़र को यहां से रीडायरेक्ट कर सकते हैं: example.com/team से example.com/about.html के लिए.

redirects एट्रिब्यूट बनाकर, यूआरएल रीडायरेक्ट के बारे में बताएं, जिसमें कलेक्शन मौजूद हो ऑब्जेक्ट (जिन्हें "रीडायरेक्ट नियम" कहा जाता है) के. हर नियम में, एक ऐसा यूआरएल पैटर्न डालें जो अनुरोध वाले यूआरएल पाथ से मैच करता हो. इससे, Hosting को ट्रिगर किया जाता है, ताकि वह तय किए गए डेस्टिनेशन यूआरएल पर रीडायरेक्ट करके जवाब दे सके.

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 एट्रिब्यूट में, रीडायरेक्ट करने के नियमों की एक कैटगरी होती है, जिसमें हर नियम को नीचे दी गई टेबल में फ़ील्ड शामिल करना ज़रूरी है.

Firebase Hosting सभी यूआरएल से source या regex वैल्यू की तुलना करता है हर अनुरोध के प्रारंभ में पथ (ब्राउज़र यह तय करता है कि फ़ाइल या फ़ोल्डर उस पाथ पर मौजूद है). अगर कोई मिलान पाया जाता है, तो Firebase Hosting का ऑरिजिन सर्वर, एक एचटीटीपीएस रीडायरेक्ट रिस्पॉन्स भेजता है. इसमें यह बताया जाता है कि ब्राउज़र को destination यूआरएल पर नया अनुरोध करने के लिए कहें.

रीडायरेक्ट के लिए यूआरएल सेगमेंट कैप्चर करें

ज़रूरी नहीं है
कभी-कभी, आपको रीडायरेक्ट नियम के यूआरएल के खास सेगमेंट कैप्चर करने पड़ सकते हैं पैटर्न (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 स्वीकार कर सकते हैं पैटर्न से मैच करता है और क्लाइंट-साइड कोड को यह तय करने देता है कि क्या दिखाना है.

जवाब को फिर से लिखने के विकल्प का इस्तेमाल, उन ऐप्लिकेशन की मदद के लिए भी किया जा सकता है जो HTML5 pushState नेविगेशन के लिए. जब कोई ब्राउज़र, तय किए गए source या regex यूआरएल पैटर्न से मैच करने वाला यूआरएल पाथ खोलने की कोशिश करता है, तो ब्राउज़र को destination यूआरएल पर मौजूद फ़ाइल का कॉन्टेंट दिखेगा.

यूआरएल रीराइट करने के लिए, rewrites एट्रिब्यूट बनाएं. इसमें ऑब्जेक्ट का कलेक्शन होता है, जिसे "रीराइट नियम" कहा जाता है. हर नियम में, ऐसा यूआरएल पैटर्न तय करें जो अगर अनुरोध यूआरएल पाथ से मेल खाता है, तो 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 किसी फ़ाइल या डायरेक्ट्री को फिर से लिखने का नियम सिर्फ़ तब लागू करता है, जब कोई फ़ाइल या डायरेक्ट्री जो बताए गए source या regex यूआरएल पैटर्न से मेल खाने वाले यूआरएल पाथ पर मौजूद हो. जब कोई अनुरोध किसी पुनर्लेखन नियम को ट्रिगर करता है, तो ब्राउज़र वास्तविक सामग्री वापस करता है destination फ़ाइल का इस्तेमाल करें, न कि एचटीटीपी रीडायरेक्ट.

किसी फ़ंक्शन के लिए अनुरोध करना

Firebase Hosting यूआरएल से फ़ंक्शन दिखाने के लिए, rewrites का इस्तेमाल किया जा सकता है. कॉन्टेंट बनाने नीचे दिया गया उदाहरण Cloud Functions का इस्तेमाल करके लगातार अपडेट होने वाली जानकारी दिखाना.

उदाहरण के लिए, /bigben पेज से सभी अनुरोधों को अपने bigben फ़ंक्शन को एक्ज़ीक्यूट करने के लिए Hosting साइट:

"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), तो आपके फ़ंक्शन तक इन यूआरएल से पहुंचा जा सकता है:

• आपके Firebase सबडोमेन:
  PROJECT_ID.web.app/bigben और PROJECT_ID.firebaseapp.com/bigben

• कनेक्ट किए गए सभी कस्टम डोमेन:
  CUSTOM_DOMAIN/bigben

Hosting वाले फ़ंक्शन पर अनुरोधों को रीडायरेक्ट करते समय, काम करने वाला एचटीटीपी अनुरोध तरीके GET, POST, HEAD, PUT, DELETE, PATCH, और OPTIONS हैं. REPORT या PROFIND जैसे दूसरे तरीके काम नहीं करते.

Cloud Run कंटेनर के लिए किए गए सीधे अनुरोध

आप rewrites का इस्तेमाल करकेCloud Run Firebase Hosting यूआरएल. यहां दिया गया उदाहरण, Cloud Run का इस्तेमाल करके डाइनैमिक कॉन्टेंट दिखाने के बारे में जानकारी का एक हिस्सा है.

उदाहरण के लिए, /helloworld पेज से सभी अनुरोधों को अपने helloworld कंटेनर को शुरू करने और चलाने को ट्रिगर करने के लिए Hosting साइट उदाहरण:

"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), तो आपकी कंटेनर इमेज तक इन यूआरएल के ज़रिए पहुंचा जा सकता है:

• आपके Firebase सबडोमेन:
  PROJECT_ID.web.app/helloworld और PROJECT_ID.firebaseapp.com/helloworld

• कनेक्ट किए गए सभी कस्टम डोमेन:
  CUSTOM_DOMAIN/helloworld

Hosting वाले Cloud Run कंटेनर पर अनुरोधों को रीडायरेक्ट करते समय, काम करने वाले एचटीटीपी अनुरोध के तरीके GET, POST, HEAD, PUT, DELETE हैं, PATCH और OPTIONS. REPORT या PROFIND जैसे दूसरे तरीके समर्थित हैं.

सबसे अच्छी परफ़ॉर्मेंस के लिए, Cloud Run की सेवा को Hosting के साथ सेट करें. इसके लिए, इन क्षेत्रों का इस्तेमाल करें:

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

Hosting के Cloud Run में लिखे गए टेक्स्ट को इस तरह से लिखा गया है: इन इलाकों में:

• 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 बनाएं

कस्टम डोमेन Dynamic Links बनाने के लिए, rewrites का इस्तेमाल किया जा सकता है. 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 को कॉन्फ़िगर करने के लिए ये चीज़ें ज़रूरी हैं:

हेडर कॉन्फ़िगर करें

ज़रूरी नहीं है
हेडर की मदद से, क्लाइंट और सर्वर ज़्यादा जानकारी भेज सकते हैं अनुरोध या जवाब भेज सकते हैं. हेडर के कुछ सेट, ब्राउज़र के काम करने के तरीके पर असर डाल सकते हैं यह पेज और उसके कॉन्टेंट को मैनेज करता है. इसमें ऐक्सेस कंट्रोल, पुष्टि करना, कैश मेमोरी में सेव करने और कोड में बदलने का तरीका.

headers एट्रिब्यूट बनाकर, पसंद के मुताबिक फ़ाइल के हिसाब से रिस्पॉन्स हेडर तय करें इसमें हेडर ऑब्जेक्ट का कलेक्शन मौजूद होता है. हर ऑब्जेक्ट में, यूआरएल पैटर्न तय करें वह, अनुरोध यूआरएल पाथ से मेल खाने पर, यूआरएल पाथ लागू करने के लिए Hosting को ट्रिगर करती है तय कस्टम रिस्पॉन्स हेडर.

यहां headers एट्रिब्यूट का बुनियादी स्ट्रक्चर दिया गया है. यह उदाहरण लागू होता है सभी फ़ॉन्ट फ़ाइलों के लिए सीओआरएस हेडर.

"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 एट्रिब्यूट में परिभाषाओं का कलेक्शन होता है, जिसमें हर परिभाषा को नीचे दी गई टेबल में फ़ील्ड शामिल करना ज़रूरी है.

Cache-Control के बारे में ज़्यादा जानने के लिए, यहां जाएं: Hosting सेक्शन, जिसमें डाइनैमिक कॉन्टेंट दिखाने और होस्टिंग की जानकारी दी गई है माइक्रोसर्विस. इसके बारे में ज़्यादा जानने के लिए, सीओआरएस हेडर.

.html एक्सटेंशन को कंट्रोल करें

ज़रूरी नहीं
cleanUrls एट्रिब्यूट की मदद से, यह कंट्रोल किया जा सकता है कि यूआरएल में .html एक्सटेंशन शामिल करना है या नहीं.

true पर, Hosting .html एक्सटेंशन को अपलोड किए गए एक्सटेंशन से अपने-आप हटा देता है यूआरएल फ़ाइल के यूआरएल मौजूद हैं. अगर अनुरोध में .html एक्सटेंशन जोड़ा जाता है, तो Hosting 301 उसी पाथ पर रीडायरेक्ट करता है, लेकिन .html एक्सटेंशन को हटा देता है.

यूआरएल में .html को शामिल करने के कंट्रोल को कंट्रोल करने का तरीका यहां बताया गया है cleanUrls एट्रिब्यूट:

"hosting": {
  // ...

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

ट्रेलिंग स्लैश को कंट्रोल करना

ज़रूरी नहीं है
trailingSlash एट्रिब्यूट की मदद से यह कंट्रोल किया जा सकता है कि स्टैटिक है या नहीं कॉन्टेंट के यूआरएल में आखिर में स्लैश होने चाहिए.

• जब true, Hosting यूआरएल को रीडायरेक्ट करता है, तो आखिर में स्लैश जोड़ता है.
• जब false, Hosting पीछे के स्लैश को हटाने के लिए यूआरएल को रीडायरेक्ट करता है.
• अगर कोई वैल्यू नहीं दी जाती है, तो Hosting सिर्फ़ डायरेक्ट्री इंडेक्स फ़ाइलों के लिए आखिर में स्लैश का इस्तेमाल करता है (उदाहरण के लिए, about/index.html).

यहां trailingSlash एट्रिब्यूट जोड़कर, ट्रेलिंग स्लैश को कंट्रोल करने का तरीका बताया गया है:

"hosting": {
  // ...

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

trailingSlash एट्रिब्यूट से, Cloud Functions या Cloud Run से दिखाए गए डाइनैमिक कॉन्टेंट को फिर से लिखने पर कोई असर नहीं पड़ता.

ग्लोब पैटर्न मैचिंग

Firebase Hosting कॉन्फ़िगरेशन के विकल्प, 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",

  }
}