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

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

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

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

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

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

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

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

  • होस्टिंग यूआरएल से Cloud Run कंटेनर ऐक्सेस करें या फ़ंक्शन चलाएं. तरीका जानें: फ़ंक्शन या कंटेनर.

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

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

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

आप अपना होस्टिंग कॉन्फ़िगरेशन कहां तय करते हैं?

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

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

Hosting REST API का इस्तेमाल करके, लागू किया गया firebase.json कॉन्टेंट देखा जा सकता है.

जवाबों को होस्ट करने का प्राथमिकता क्रम

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

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

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

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

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

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

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

सार्वजनिक

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

अगर कोई ब्राउज़र आपके डोमेन या सबडोमेन पर 404 Not Found गड़बड़ी ट्रिगर करता है, तो Firebase होस्टिंग इस कस्टम 404.html पेज का कॉन्टेंट दिखाएगी.

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

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

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

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

फिर से लिखे जाने वाले मैसेज को कॉन्फ़िगर करें

ज़रूरी नहीं
कई यूआरएल के लिए एक जैसा कॉन्टेंट दिखाने के लिए, रीराइट का इस्तेमाल करें. पैटर्न मैचिंग के लिए रीराइट की सुविधा खास तौर पर काम की है, क्योंकि पैटर्न से मेल खाने वाला कोई भी यूआरएल स्वीकार किया जा सकता है और क्लाइंट-साइड कोड से यह तय किया जा सकता है कि कौनसा यूआरएल दिखाया जाए.

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

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

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

किसी फ़ंक्शन के लिए सीधे तौर पर किए गए अनुरोध

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

उदाहरण के लिए, bigben फ़ंक्शन चलाने के लिए, अपनी होस्टिंग साइट के /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 का इस्तेमाल करके), आपके फ़ंक्शन तक इन यूआरएल से पहुंचा जा सकता है:

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

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

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

Cloud Run कंटेनर को सीधे तौर पर किए जाने वाले अनुरोध

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

उदाहरण के लिए, helloworld कंटेनर इंस्टेंस के स्टार्टअप और रनिंग को ट्रिगर करने के लिए, अपनी होस्टिंग साइट के /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 का इस्तेमाल करके), आपकी कंटेनर इमेज को नीचे दिए गए यूआरएल से ऐक्सेस किया जा सकता है:

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

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

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

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

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

होस्टिंग से 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

कस्टम डोमेन के डाइनैमिक लिंक बनाना

कस्टम डोमेन के डाइनैमिक लिंक बनाने के लिए, rewrites का इस्तेमाल किया जा सकता है. डाइनैमिक लिंक के लिए कस्टम डोमेन सेट अप करने के बारे में ज़्यादा जानकारी के लिए, डाइनैमिक लिंक दस्तावेज़ देखें.

• अपने कस्टम डोमेन का इस्तेमाल सिर्फ़ डाइनैमिक लिंक के लिए करें

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

• डाइनैमिक लिंक के लिए इस्तेमाल करने के लिए, कस्टम डोमेन पाथ के प्रीफ़िक्स बताएं

  "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 फ़ाइल में डाइनैमिक लिंक कॉन्फ़िगर करने के लिए, यह ज़रूरी है:

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

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

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

यहां 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 के बारे में ज़्यादा जानने के लिए, होस्टिंग सेक्शन में जाएं. यहां डाइनैमिक कॉन्टेंट दिखाने और माइक्रोसेवाएं होस्ट करने की सुविधा के बारे में जानकारी दी गई है. सीओआरएस हेडर के बारे में भी ज़्यादा जानकारी पाएं.

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

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

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

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

"hosting": {
  // ...

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

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

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

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

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

"hosting": {
  // ...

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

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

ग्लोब पैटर्न मैच करना

Firebase होस्टिंग कॉन्फ़िगरेशन के विकल्पों में, एक्सटेंशन के साथ ग्लोब पैटर्न मैचिंग नोटेशन का बेहतर तरीके से इस्तेमाल किया जाता है. यह उसी तरह से इस्तेमाल होता है जिस तरह Git gitignore के नियमों और Bower के नियमों को ignore के साथ मैनेज करता है. यह विकी पेज ज़्यादा जानकारी वाला रेफ़रंस है, लेकिन इस पेज पर इस्तेमाल किए जाने वाले उदाहरणों के बारे में यहां बताया गया है:

• firebase.json — सिर्फ़ public डायरेक्ट्री के रूट में मौजूद firebase.json फ़ाइल से मैच करता है

• ** — आर्बिट्रेरी सब-डायरेक्ट्री में मौजूद किसी भी फ़ाइल या फ़ोल्डर से मेल खाता है

• * — सिर्फ़ public डायरेक्ट्री के रूट में मौजूद फ़ाइलों और फ़ोल्डर से मेल खाता है

• **/.* — . से शुरू होने वाली किसी भी सब-डायरेक्ट्री में मौजूद फ़ाइलों से मैच करता है. आम तौर पर, छिपी हुई फ़ाइलें, जैसे कि .git फ़ोल्डर में होती हैं

• **/node_modules/** — किसी node_modules फ़ोल्डर की आर्बिट्रेरी सब-डायरेक्ट्री में मौजूद किसी भी फ़ाइल या फ़ोल्डर से मेल खाता है. यह public डायरेक्ट्री की आर्बिट्रेरी सब-डायरेक्ट्री में खुद भी हो सकता है

• **/*.@(jpg|jpeg|gif|png) — यह मॉडल, आर्बिट्रेरी सब-डायरेक्ट्री में, उन सभी फ़ाइलों से मेल खाता है जो इनमें से किसी एक पर खत्म होती हैं: .jpg, .jpeg, .gif या .png

होस्ट के कॉन्फ़िगरेशन का उदाहरण

Firebase होस्टिंग के लिए, firebase.json के कॉन्फ़िगरेशन का पूरा उदाहरण यहां दिया गया है. ध्यान दें कि किसी 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",

  }
}