Catch up on everything announced at Firebase Summit, and learn how Firebase can help you accelerate app development and run your app with confidence. Learn More

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

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

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

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

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

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

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

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

    • एकाधिक यूआरएल के लिए एक ही सामग्री दिखाएं। सीखो कैसे।

    • किसी होस्टिंग URL से कोई फ़ंक्शन परोसें या क्लाउड रन कंटेनर एक्सेस करें। जानें कैसे: फ़ंक्शन या कंटेनर

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

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

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

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

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

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

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

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

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

  1. आरक्षित नामस्थान जो एक /__/* पथ खंड से शुरू होते हैं
  2. कॉन्फ़िगर किए गए रीडायरेक्ट
  3. सटीक-मिलान स्थिर सामग्री
  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 विशेषता फ़ाइलों को तैनाती पर अनदेखा करने के लिए निर्दिष्ट करती है। यह उसी तरह .gitignore ले सकता है जैसे गिट .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 पर रीडायरेक्ट के साथ प्रतिक्रिया करने के लिए होस्टिंग को ट्रिगर करता है।

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

"hosting": {
  // ...

  // Returns a permanent redirect to "/bar" for requests to "/foo" (but not "/foo/**")
  "redirects": [ {
    "source": "/foo",
    "destination": "/bar",
    "type": 301
  } ]
}

redirects विशेषता में रीडायरेक्ट नियमों की एक सरणी होती है, जहां प्रत्येक नियम में नीचे दी गई तालिका में फ़ील्ड शामिल होनी चाहिए।

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

खेत विवरण
redirects
source (अनुशंसित)
या regex

एक URL प्रतिमान, यदि प्रारंभिक अनुरोध URL से मेल खाता है, तो रीडायरेक्ट लागू करने के लिए होस्टिंग को ट्रिगर करता है

destination

एक स्थिर यूआरएल जहां ब्राउजर को एक नया अनुरोध करना चाहिए

यह URL एक सापेक्ष या निरपेक्ष पथ हो सकता है।

type

HTTPS प्रतिक्रिया कोड

  • 'स्थायी रूप से स्थानांतरित' के लिए 301 प्रकार का उपयोग करें
  • 'पाया' (अस्थायी रीडायरेक्ट) के लिए 302 प्रकार का उपयोग करें

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

वैकल्पिक
कभी-कभी, आपको रीडायरेक्ट नियम के URL पैटर्न ( source या regex मान) के विशिष्ट सेगमेंट को कैप्चर करने की आवश्यकता हो सकती है, फिर नियम के destination पथ में इन सेगमेंट का पुनः उपयोग करें।

पुनर्लेखन कॉन्फ़िगर करें

वैकल्पिक
एकाधिक यूआरएल के लिए समान सामग्री दिखाने के लिए पुनर्लेखन का उपयोग करें। पुनर्लेखन पैटर्न मिलान के साथ विशेष रूप से उपयोगी होते हैं, क्योंकि आप पैटर्न से मेल खाने वाले किसी भी URL को स्वीकार कर सकते हैं और क्लाइंट-साइड कोड को यह तय करने देते हैं कि क्या प्रदर्शित करना है।

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

एक rewrites विशेषता बनाकर यूआरएल पुनर्लेखन निर्दिष्ट करें जिसमें ऑब्जेक्ट्स की एक सरणी होती है (जिसे "पुनर्लेखन नियम" कहा जाता है)। प्रत्येक नियम में, एक 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"
  } ]
}

rewrites विशेषता में पुनर्लेखन नियमों की एक सरणी होती है, जहां प्रत्येक नियम में नीचे दी गई तालिका में फ़ील्ड शामिल होना चाहिए।

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

खेत विवरण
rewrites
source (अनुशंसित)
या regex

एक URL प्रतिमान, यदि प्रारंभिक अनुरोध URL से मेल खाता है, तो पुनर्लेखन लागू करने के लिए होस्टिंग को ट्रिगर करता है

destination

एक स्थानीय फ़ाइल जो मौजूद होनी चाहिए

यह URL एक सापेक्ष या निरपेक्ष पथ हो सकता है।

एक समारोह के लिए प्रत्यक्ष अनुरोध

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

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

"hosting": {
  // ...

  // Directs all requests from the page `/bigben` to execute the `bigben` function
  "rewrites": [ {
    "source": "/bigben",
    "function": "bigben",
    "region": "us-central1"  // optional (see note below)
  } ]
}

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

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

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

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

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

आप फायरबेस होस्टिंग यूआरएल से क्लाउड रन कंटेनर तक पहुंचने के लिए 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 के माध्यम से पहुंच योग्य है:

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

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

होस्टिंग के साथ क्लाउड रन कंटेनरों के अनुरोधों को पुनर्निर्देशित करते समय, समर्थित HTTP अनुरोध विधियाँ हैं GET , POST , HEAD , PUT , DELETE , PATCH , और OPTIONSREPORT या 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 फ़ाइल में डायनामिक लिंक कॉन्फ़िगर करने के लिए निम्न की आवश्यकता होती है:

खेत विवरण
appAssociation

AUTO पर सेट होना चाहिए

  • यदि आप इस विशेषता को अपने कॉन्फ़िगरेशन में शामिल नहीं करते हैं, तो appAssociation के लिए डिफ़ॉल्ट AUTO है।
  • इस विशेषता को AUTO पर सेट करके, अनुरोध किए जाने पर होस्टिंग गतिशील रूप से assetlinks.json और apple-app-site-association फ़ाइलें उत्पन्न कर सकती है।
rewrites
source

एक पथ जिसे आप डायनेमिक लिंक्स के लिए उपयोग करना चाहते हैं

URL के पथ को फिर से लिखने वाले नियमों के विपरीत, डायनेमिक लिंक के लिए फिर से लिखने के नियमों में रेगुलर एक्सप्रेशन नहीं हो सकते।

dynamicLinks true पर सेट होना चाहिए

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

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

एक 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": "*"
    } ]
  } ]
}

headers विशेषता में परिभाषाओं की एक सरणी होती है, जहाँ प्रत्येक परिभाषा में नीचे दी गई तालिका में फ़ील्ड शामिल होनी चाहिए।

खेत विवरण
headers
source (अनुशंसित)
या regex

एक URL प्रतिमान, जो यदि प्रारंभिक अनुरोध URL से मेल खाता है, तो कस्टम हेडर लागू करने के लिए होस्टिंग को ट्रिगर करता है

अपने कस्टम 404 पेज से मिलान करने के लिए हेडर बनाने के लिए, 404.html को अपने source या regex मान के रूप में उपयोग करें।

(उप-) headers की सरणी

अनुरोध पथ पर होस्टिंग द्वारा लागू किए जाने वाले कस्टम हेडर

प्रत्येक उप-शीर्षक में एक key और value युग्म शामिल होना चाहिए (अगली दो पंक्तियाँ देखें)।

key हेडर का नाम, उदाहरण के लिए Cache-Control
value हेडर के लिए मान, उदाहरण के लिए max-age=7200

आप होस्टिंग अनुभाग में 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 विशेषता आपको यह नियंत्रित करने की अनुमति देती है कि स्थिर सामग्री URL में ट्रेलिंग स्लैश शामिल होने चाहिए या नहीं।

  • true होने पर, होस्टिंग URL को अनुगामी स्लैश जोड़ने के लिए पुनर्निर्देशित करता है।
  • false होने पर, होस्टिंग पीछे के स्लैश को हटाने के लिए यूआरएल को रीडायरेक्ट करता है।
  • अनिर्दिष्ट होने पर, होस्टिंग केवल डायरेक्टरी इंडेक्स फाइलों के लिए ट्रेलिंग स्लैश का उपयोग करती है (उदाहरण के लिए, 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 होस्टिंग के लिए एक पूर्ण 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",

  }
}