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

फायरबेस होस्टिंग के साथ, आप अपनी साइट के अनुरोधों के लिए अनुकूलित होस्टिंग व्यवहार को कॉन्फ़िगर कर सकते हैं।

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

• निर्दिष्ट करें कि आप अपने स्थानीय प्रोजेक्ट निर्देशिका में कौन-सी फ़ाइलें Firebase होस्टिंग पर परिनियोजित करना चाहते हैं। कैसे सीखें।

• एक अनुकूलित 404/नहीं मिला पृष्ठ परोसें। कैसे सीखें।

• उन पृष्ठों के लिए redirects सेट करें जिन्हें आपने स्थानांतरित या हटा दिया है। कैसे सीखें।

• इनमें से किसी भी उद्देश्य के लिए rewrites सेट करें:

  • अनेक URL के लिए समान सामग्री दिखाएं. कैसे सीखें।

  • एक होस्टिंग यूआरएल से एक फ़ंक्शन परोसें या क्लाउड रन कंटेनर तक पहुंचें। जानें कि कैसे: फ़ंक्शन या कंटेनर ।

  • एक कस्टम डोमेन डायनामिक लिंक बनाएं। कैसे सीखें।

• अनुरोध या प्रतिक्रिया के बारे में अतिरिक्त जानकारी देने के लिए headers जोड़ें, जैसे कि ब्राउज़र को पृष्ठ और उसकी सामग्री (प्रमाणीकरण, कैशिंग, एन्कोडिंग, आदि) को कैसे संभालना चाहिए। कैसे सीखें।

• उपयोगकर्ता की भाषा वरीयता और/या देश के आधार पर विशिष्ट सामग्री परोसने के लिए अंतर्राष्ट्रीयकरण (i18n) पुनर्लेखन सेट करें। जानें कैसे (अलग पृष्ठ)।

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

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

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

आप Hosting REST API का उपयोग करके परिनियोजित firebase.json सामग्री की जांच कर सकते हैं।

होस्टिंग प्रतिक्रियाओं का प्राथमिकता क्रम

इस पृष्ठ पर वर्णित विभिन्न फायरबेस होस्टिंग कॉन्फ़िगरेशन विकल्प कभी-कभी ओवरलैप हो सकते हैं। यदि कोई विरोध होता है, तो होस्टिंग निम्नलिखित प्राथमिकता क्रम का उपयोग करके अपनी प्रतिक्रिया निर्धारित करती है:

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

यदि आप i18n पुनर्लेखन का उपयोग कर रहे हैं, तो आपकी "i18n सामग्री" को समायोजित करने के लिए सटीक-मिलान और 404 हैंडलिंग प्राथमिकता क्रम का विस्तार किया गया है।

निर्दिष्ट करें कि कौन सी फाइलें तैनात करनी हैं

डिफ़ॉल्ट विशेषताएँ — public और ignore — डिफ़ॉल्ट firebase.json फ़ाइल में शामिल होती हैं, यह परिभाषित करती हैं कि आपकी प्रोजेक्ट निर्देशिका में कौन-सी फ़ाइलें आपके Firebase प्रोजेक्ट में परिनियोजित की जानी चाहिए।

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

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

सह लोक

अपेक्षित
public विशेषता निर्दिष्ट करती है कि फायरबेस होस्टिंग में कौन सी निर्देशिका परिनियोजित की जाए। डिफ़ॉल्ट मान 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 त्रुटि ट्रिगर करता है, तो फायरबेस होस्टिंग इस कस्टम 404.html पृष्ठ की सामग्री प्रदर्शित करेगी।

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

ऐच्छिक
यदि आपने किसी पृष्ठ को स्थानांतरित किया है या URL को छोटा करने के लिए टूटे हुए लिंक को रोकने के लिए URL रीडायरेक्ट का उपयोग करें। उदाहरण के लिए, आप में से एक ब्राउज़र अनुप्रेषित सकता example.com/team को example.com/about.html ।

एक redirects विशेषता बनाकर URL रीडायरेक्ट निर्दिष्ट करें जिसमें ऑब्जेक्ट्स की एक सरणी होती है (जिन्हें "रीडायरेक्ट नियम" कहा जाता है)। प्रत्येक नियम में, एक URL पैटर्न निर्दिष्ट करें, जो अनुरोध URL पथ से मेल खाने पर, निर्दिष्ट गंतव्य URL पर रीडायरेक्ट के साथ प्रतिक्रिया देने के लिए होस्टिंग को ट्रिगर करता है।

redirects विशेषता के लिए बुनियादी संरचना यहां दी गई है। यह उदाहरण /bar लिए एक नया अनुरोध करके अनुरोधों को /foo पुनर्निर्देशित करता है।

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

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

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

ऐच्छिक
कभी-कभी, आपको रीडायरेक्ट नियम के URL पैटर्न ( 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 के लिए समान सामग्री दिखाने के लिए पुनर्लेखन का उपयोग करें। पैटर्न मिलान के साथ पुनर्लेखन विशेष रूप से उपयोगी होते हैं, क्योंकि आप पैटर्न से मेल खाने वाले किसी भी URL को स्वीकार कर सकते हैं और क्लाइंट-साइड कोड को यह तय करने दे सकते हैं कि क्या प्रदर्शित किया जाए।

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

एक rewrites विशेषता बनाकर URL पुनर्लेखन निर्दिष्ट करें जिसमें वस्तुओं की एक सरणी होती है (जिसे "पुनर्लेखन नियम" कहा जाता है)। प्रत्येक नियम में, एक URL प्रतिमान निर्दिष्ट करें, जो अनुरोध URL पथ से मेल खाने पर, होस्टिंग को प्रतिक्रिया देने के लिए ट्रिगर करता है जैसे कि सेवा को निर्दिष्ट गंतव्य 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 विशेषता में पुनर्लेखन नियमों की एक सरणी होती है, जहां प्रत्येक नियम में नीचे दी गई तालिका में फ़ील्ड शामिल होने चाहिए।

फायरबेस होस्टिंग केवल एक पुनर्लेखन नियम लागू करता है यदि कोई फ़ाइल या निर्देशिका यूआरएल पथ पर मौजूद नहीं है जो निर्दिष्ट source या regex यूआरएल पैटर्न से मेल खाती है। जब कोई अनुरोध एक पुनर्लेखन नियम को ट्रिगर करता है, तो ब्राउज़र HTTP रीडायरेक्ट के बजाय निर्दिष्ट destination फ़ाइल की वास्तविक सामग्री लौटाता है।

एक समारोह के लिए सीधे अनुरोध

आप Firebase होस्टिंग URL से किसी फ़ंक्शन की सेवा के लिए rewrites का उपयोग कर सकते हैं। निम्न उदाहरण क्लाउड फ़ंक्शंस का उपयोग करके गतिशील सामग्री प्रस्तुत करने का एक अंश है।

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

"hosting": {
  // ...

  // Directs all requests from the page `/bigben` to execute the `bigben` function
  "rewrites": [ {
    "source": "/bigben",
    "function": "bigben"
  } ]
}

इस पुनर्लेखन नियम को जोड़ने और Firebase ( firebase deploy का उपयोग करके) पर firebase deploy , आपका कार्य निम्न URL के माध्यम से उपलब्ध है:

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

• कोई भी जुड़ा हुआ कस्टम डोमेन :
  CUSTOM_DOMAIN /bigben

जब होस्टिंग के साथ कार्यों के लिए अनुरोधों को पुनर्निर्देशित किया जाता है, तो समर्थित HTTP अनुरोध विधियाँ GET , POST , HEAD , PUT , DELETE , PATCH और OPTIONS । अन्य विधियाँ जैसे REPORT या PROFIND समर्थित नहीं हैं।

क्लाउड रन कंटेनर के लिए सीधे अनुरोध

आप Firebase होस्टिंग URL से क्लाउड रन कंटेनर तक पहुंचने के लिए rewrites का उपयोग कर सकते हैं। निम्न उदाहरण क्लाउड रन का उपयोग करके गतिशील सामग्री प्रस्तुत करने का एक अंश है।

उदाहरण के लिए, अपनी होस्टिंग साइट के पेज /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 का उपयोग करके), आपकी कंटेनर छवि निम्न URL के माध्यम से उपलब्ध है:

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

• कोई भी जुड़ा हुआ कस्टम डोमेन :
  CUSTOM_DOMAIN /helloworld

होस्टिंग के साथ क्लाउड रन कंटेनरों के अनुरोधों को पुनर्निर्देशित करते समय, समर्थित HTTP अनुरोध विधियां GET , POST , HEAD , PUT , DELETE , PATCH , और OPTIONS । अन्य विधियाँ जैसे REPORT या PROFIND समर्थित नहीं हैं।

वर्तमान में, आप निम्न क्षेत्रों में होस्टिंग के साथ क्लाउड रन रीराइट का उपयोग कर सकते हैं:

• asia-east1
• asia-east2
• asia-northeast1
• asia-northeast2
• asia-northeast3
• asia-south1
• asia-southeast1
• asia-southeast2
• australia-southeast1
• europe-north1
• europe-west1
• europe-west2
• europe-west3
• europe-west4
• europe-west6
• northamerica-northeast1
• southamerica-east1
• us-central1
• us-east1
• us-east4
• us-west1

कस्टम डोमेन डायनामिक लिंक बनाएं

आप कस्टम डोमेन डायनामिक लिंक बनाने के लिए 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 विशेषता बनाकर कस्टम, फ़ाइल-विशिष्ट प्रतिक्रिया शीर्षलेख निर्दिष्ट करें। प्रत्येक ऑब्जेक्ट में, एक URL पैटर्न निर्दिष्ट करें, यदि अनुरोध URL पथ से मेल खाता है, तो निर्दिष्ट कस्टम प्रतिक्रिया शीर्षलेख लागू करने के लिए होस्टिंग को ट्रिगर करता है।

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

आप होस्टिंग सेक्शन में Cache-Control बारे में अधिक जान सकते हैं जो डायनेमिक कंटेंट परोसने और माइक्रोसर्विसेज को होस्ट करने का वर्णन करता है। आप CORS हेडर के बारे में अधिक जान सकते हैं।

नियंत्रण .html एक्सटेंशन

ऐच्छिक
cleanUrls विशेषता आपको यह नियंत्रित करने की अनुमति देती है कि URL में .html एक्सटेंशन शामिल होना चाहिए या नहीं।

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

एक cleanUrls विशेषता को शामिल करके URL में .html के समावेशन को नियंत्रित करने का तरीका यहां दिया गया है:

"hosting": {
  // ...

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

अनुगामी स्लैश को नियंत्रित करें

ऐच्छिक
trailingSlash विशेषता आप को नियंत्रित करने के लिए किया जाए या नहीं स्थैतिक सामग्री यूआरएल अनुगामी स्लैश शामिल करना चाहिए अनुमति देता है।

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

यहाँ कैसे एक जोड़कर ट्रेलिंग स्लैश नियंत्रित करने के लिए है trailingSlash विशेषता:

"hosting": {
  // ...

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

trailingSlash विशेषता क्लाउड फ़ंक्शंस या क्लाउड रन द्वारा प्रदान की जाने वाली गतिशील सामग्री के पुनर्लेखन को प्रभावित नहीं करती है।

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

फायरबेस होस्टिंग कॉन्फ़िगरेशन विकल्प एक्सग्लोब के साथ ग्लोब पैटर्न मिलान नोटेशन का व्यापक उपयोग करते हैं, उसी तरह जैसे गिट gitignore नियमों को संभालता है और बोवर नियमों को ignore है। यह विकी पृष्ठ एक अधिक विस्तृत संदर्भ है, लेकिन इस पृष्ठ पर उपयोग किए गए उदाहरणों के स्पष्टीकरण निम्नलिखित हैं:

• firebase.json — केवल public निर्देशिका के मूल में firebase.json फ़ाइल से मेल खाता है

• ** - किसी भी फ़ाइल या फ़ोल्डर को मनमानी उप-निर्देशिका में मिलाता है

• * — केवल public निर्देशिका के मूल में फाइलों और फ़ोल्डरों से मेल खाता है

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

• **/node_modules/** - एक की एक मनमाना उप निर्देशिका में किसी भी फ़ाइल या फ़ोल्डर मेल node_modules फ़ोल्डर, जो अपने आप की एक मनमाना उप निर्देशिका में हो सकता है public निर्देशिका

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

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

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