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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

होस्टिंग 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 फ़ाइल का असल कॉन्टेंट दिखाता है.

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

Firebase होस्टिंग यूआरएल से फ़ंक्शन दिखाने के लिए, rewrites का इस्तेमाल किया जा सकता है. नीचे दिया गया उदाहरण 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 होस्टिंग कॉन्फ़िगरेशन विकल्पों में, extग्लोब के साथ ग्लोब पैटर्न मैचिंग नोटेशन का बहुत ज़्यादा इस्तेमाल किया जाता है. यह बिलकुल वैसे ही है जैसे 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",

  }
}