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

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

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

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

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

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

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

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

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

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

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

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

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

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

सावधानी: यदि आप firebase init दोबारा चलाते हैं और होस्टिंग का चयन करते हैं, तो कमांड firebase.json फ़ाइल के hosting अनुभाग को डिफ़ॉल्ट कॉन्फ़िगरेशन पर वापस अधिलेखित कर देगा।

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

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

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

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

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

महत्वपूर्ण: प्रत्येक redirects और rewrites विशेषताओं के भीतर, होस्टिंग अनुरोधित पथ से मेल खाने वाले यूआरएल पैटर्न के साथ पहले नियम द्वारा परिभाषित रीडायरेक्ट या रीराइट लागू करता है। इसलिए, आपको जानबूझकर प्रत्येक redirects और rewrites विशेषताओं के भीतर नियमों को क्रमबद्ध करने की आवश्यकता है। कॉन्फ़िगर किए गए redirects अभी भी rewrites पर प्राथमिकता दी जाती है।

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

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

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

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 पृष्ठ की सामग्री प्रदर्शित करेगा।

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

वैकल्पिक
यदि आपने कोई पृष्ठ स्थानांतरित किया है तो टूटे हुए लिंक को रोकने या यूआरएल को छोटा करने के लिए यूआरएल रीडायरेक्ट का उपयोग करें। उदाहरण के लिए, आप किसी ब्राउज़र को 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
  } ]
}

redirects विशेषता के लिए अधिक विस्तृत उदाहरण देखें

"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 पर एक नया अनुरोध करने के लिए कहता है।

मैदान		विवरण
redirects
	source (अनुशंसित) या regex	एक यूआरएल पैटर्न, जो यदि प्रारंभिक अनुरोध यूआरएल से मेल खाता है, तो रीडायरेक्ट लागू करने के लिए होस्टिंग को ट्रिगर करता है ग्लोब निर्दिष्ट करने के लिए source उपयोग करें (अनुशंसित) । RE2 रेगुलर एक्सप्रेशन निर्दिष्ट करने के लिए regex उपयोग करें।
	destination	एक स्थिर यूआरएल जहां ब्राउज़र को एक नया अनुरोध करना चाहिए यह यूआरएल सापेक्ष या निरपेक्ष पथ हो सकता है।
	type	HTTPS प्रतिक्रिया कोड 'स्थायी रूप से स्थानांतरित' के लिए 301 प्रकार का उपयोग करें 'पाया' (अस्थायी रीडायरेक्ट) के लिए 302 प्रकार का उपयोग करें

महत्वपूर्ण: redirects विशेषता के भीतर, होस्टिंग पहले नियम द्वारा परिभाषित रीडायरेक्ट को एक यूआरएल पैटर्न के साथ लागू करता है जो अनुरोधित पथ से मेल खाता है। इसलिए, आपको जानबूझकर redirects विशेषता के भीतर नियमों को क्रमबद्ध करने की आवश्यकता है।

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

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

ग्लब्स का उपयोग करते समय यूआरएल सेगमेंट कैप्चर करें

यदि आप एक source फ़ील्ड का उपयोग कर रहे हैं (अर्थात, अपने यूआरएल पैटर्न के लिए एक ग्लोब निर्दिष्ट कर रहे हैं), तो आप सेगमेंट की पहचान करने के लिए : उपसर्ग शामिल करके सेगमेंट को कैप्चर कर सकते हैं। यदि आपको सेगमेंट के बाद शेष यूआरएल पथ को भी कैप्चर करने की आवश्यकता है, तो सेगमेंट के तुरंत बाद * शामिल करें। उदाहरण के लिए:

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

RE2 रेगुलर एक्सप्रेशन का उपयोग करते समय URL सेगमेंट कैप्चर करें

यदि आप एक regex फ़ील्ड का उपयोग कर रहे हैं (अर्थात, अपने यूआरएल पैटर्न के लिए एक आरई2 रेगुलर एक्सप्रेशन निर्दिष्ट कर रहे हैं), तो आप नामित या अनाम आरई2 कैप्चर समूहों का उपयोग करके सेगमेंट कैप्चर कर सकते हैं। नामांकित कैप्चर समूहों का उपयोग destination फ़ील्ड में : उपसर्ग के साथ किया जा सकता है, जबकि अनाम कैप्चर समूहों को regex मान में उनके संख्यात्मक सूचकांक द्वारा संदर्भित किया जा सकता है, जो 1 से अनुक्रमित है। उदाहरण के लिए:

"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 पुशस्टेट का उपयोग करने वाले ऐप्स का समर्थन करने के लिए रीराइट का भी उपयोग कर सकते हैं। जब कोई ब्राउज़र निर्दिष्ट 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"
  } ]
}

rewrites विशेषता के लिए अधिक विस्तृत उदाहरण देखें

"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 फ़ाइल की वास्तविक सामग्री लौटाता है।

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

महत्वपूर्ण: rewrites विशेषता के भीतर, होस्टिंग पहले नियम द्वारा परिभाषित रीराइट को एक यूआरएल पैटर्न के साथ लागू करता है जो अनुरोधित पथ से मेल खाता है। इसलिए, आपको rewrites विशेषता के भीतर नियमों को जानबूझकर क्रमबद्ध करने की आवश्यकता है।

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

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

उदाहरण के लिए, 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)
    }
  } ]
}

function ब्लॉक के भीतर region कैसे काम करता है

यदि region hosting.rewrites कॉन्फ़िगरेशन के function ब्लॉक से हटा दिया जाता है, तो फ़ायरबेस सीएलआई स्वचालित रूप से फ़ंक्शन के स्रोत कोड से क्षेत्र का पता लगाने का प्रयास करता है, जो अनिर्दिष्ट होने पर, us-central1 पर डिफ़ॉल्ट होता है। यदि फ़ंक्शन का स्रोत कोड अनुपलब्ध है, तो सीएलआई तैनात फ़ंक्शन से क्षेत्र का पता लगाने का प्रयास करता है। यदि फ़ंक्शन एकाधिक क्षेत्रों में है, तो सीएलआई को hosting.rewrites कॉन्फ़िगरेशन में region निर्दिष्ट करने की आवश्यकता होती है।

pinTag function ब्लॉक के भीतर कैसे काम करता है

pinTag सुविधा केवल फायरबेस (दूसरी पीढ़ी) के लिए क्लाउड फ़ंक्शंस में उपलब्ध है। इस सुविधा के साथ, आप यह सुनिश्चित कर सकते हैं कि आपकी साइट की गतिशील सामग्री उत्पन्न करने के लिए प्रत्येक फ़ंक्शन को आपके स्थिर होस्टिंग संसाधनों और होस्टिंग कॉन्फ़िगरेशन के साथ समन्वयित रखा गया है। साथ ही, यह सुविधा आपको होस्टिंग पूर्वावलोकन चैनलों पर कार्यों के लिए अपने पुनर्लेखन का पूर्वावलोकन करने की अनुमति देती है।

यदि आप hosting.rewrites कॉन्फ़िगरेशन के function ब्लॉक में "pinTag": true जोड़ते हैं, तो "पिन किया हुआ" फ़ंक्शन आपके स्थिर होस्टिंग संसाधनों और कॉन्फ़िगरेशन के साथ तैनात किया जाएगा, यहां तक ​​कि firebase deploy --only hosting चलाते समय भी। यदि आप अपनी साइट के किसी संस्करण को वापस रोल करते हैं, तो "पिन किया हुआ" फ़ंक्शन भी वापस रोल हो जाता है।

नोट: यदि आप किसी मौजूदा रीराइट में pinTag जोड़ते हैं, तो आपको पहले अपडेटेड रीराइट को अपने "लाइव" चैनल पर तैनात करना होगा। उस परिनियोजन के बाद, आप उत्पादन को प्रभावित किए बिना होस्टिंग पूर्वावलोकन चैनलों में अपने फ़ंक्शन के कोड में परिवर्तनों का पूर्वावलोकन कर सकते हैं।

यह सुविधा क्लाउड रन टैग पर निर्भर करती है, जिसकी सीमा प्रति सेवा 1000 टैग और प्रति क्षेत्र 2000 टैग है। इसका मतलब यह है कि सैकड़ों तैनाती के बाद, किसी साइट का सबसे पुराना संस्करण काम करना बंद कर सकता है।

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

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

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

होस्टिंग के साथ कार्यों के लिए अनुरोधों को पुनर्निर्देशित करते समय, समर्थित HTTP अनुरोध विधियाँ GET , POST , HEAD , PUT , DELETE , PATCH , और OPTIONS हैं। REPORT या 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)
   }
 } ]
}

pinTag run ब्लॉक के भीतर कैसे काम करता है

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

यदि आप hosting.rewrites कॉन्फ़िगरेशन के run ब्लॉक में "pingTag": true जोड़ते हैं, तो आपके स्थिर होस्टिंग संसाधन और कॉन्फ़िगरेशन को तैनाती के समय क्लाउड रन सेवा के सबसे हालिया संशोधन पर पिन किया जाएगा। यदि आप अपनी साइट के किसी संस्करण को वापस लाते हैं, तो "पिन की गई" क्लाउड रन सेवा का संशोधन भी वापस ले लिया जाता है।

यह सुविधा क्लाउड रन टैग पर निर्भर करती है, जिसकी सीमा प्रति सेवा 1000 टैग और प्रति क्षेत्र 2000 टैग है। इसका मतलब यह है कि सैकड़ों तैनाती के बाद, किसी साइट का सबसे पुराना संस्करण काम करना बंद कर सकता है।

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

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

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

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

सर्वोत्तम प्रदर्शन के लिए, निम्नलिखित क्षेत्रों का उपयोग करके अपनी क्लाउड रन सेवा को होस्टिंग के साथ संयोजित करें:

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

होस्टिंग से क्लाउड रन पर पुनर्लेखन निम्नलिखित क्षेत्रों में समर्थित है:

• 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 फ़ाइल में डायनामिक लिंक कॉन्फ़िगर करने के लिए निम्नलिखित की आवश्यकता होती है:

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

महत्वपूर्ण : डायनेमिक लिंक के लिए, होस्टिंग प्राथमिकता क्रम के बारे में विशेष रूप से जागरूक रहें।

• सुनिश्चित करें कि आपका डायनामिक लिंक यूआरएल उपसर्ग उच्च प्राथमिकता वाले होस्टिंग कॉन्फ़िगरेशन के साथ विरोध नहीं करता है (उदाहरण के लिए, होस्ट की गई स्थिर सामग्री को हमेशा पुनर्लेखन पर प्राथमिकता दी जाती है)।
• प्रत्येक redirects और rewrites विशेषताओं के भीतर, होस्टिंग अनुरोधित पथ से मेल खाने वाले यूआरएल पैटर्न के साथ पहले नियम द्वारा परिभाषित रीडायरेक्ट या रीराइट लागू करता है। इसलिए, आपको जानबूझकर प्रत्येक redirects और rewrites विशेषताओं के भीतर नियमों को क्रमबद्ध करने की आवश्यकता है।

विस्तृत जानकारी के लिए, डायनेमिक लिंक दस्तावेज़ देखें।

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

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

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

यहां 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 विशेषता के लिए अधिक विस्तृत उदाहरण देखें

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

मैदान			विवरण
headers
	source (अनुशंसित) या regex		एक यूआरएल पैटर्न, जो यदि प्रारंभिक अनुरोध यूआरएल से मेल खाता है, तो कस्टम हेडर लागू करने के लिए होस्टिंग को ट्रिगर करता है ग्लोब निर्दिष्ट करने के लिए source उपयोग करें (अनुशंसित) । RE2 रेगुलर एक्सप्रेशन निर्दिष्ट करने के लिए regex उपयोग करें। अपने कस्टम 404 पेज से मेल खाने वाला हेडर बनाने के लिए, अपने source या regex मान के रूप में 404.html उपयोग करें।
	(उप-) headers की सारणी		कस्टम हेडर जो होस्टिंग अनुरोध पथ पर लागू करता है प्रत्येक उप-शीर्षक में एक key और value युग्म शामिल होना चाहिए (अगली दो पंक्तियाँ देखें)।
		key	हेडर का नाम, उदाहरण के लिए Cache-Control
		value	हेडर का मान, उदाहरण के लिए max-age=7200

नोट: कस्टम हेडर के लिए यूआरएल पैटर्न का मिलान किसी भी पुनर्लेखन नियम लागू होने से पहले किया जाता है।

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

महत्वपूर्ण: फायरबेस होस्टिंग डिफ़ॉल्ट होस्टिंग उपडोमेन (जैसे *.web.app ) पर Strict-Transport-Security कॉन्फ़िगरेशन को अधिलेखित कर देती है। हालाँकि, कोई भी कनेक्टेड कस्टम डोमेन कॉन्फ़िगर किए गए मान पर काम करेगा।

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

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

"hosting": {
  // ...

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

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

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

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

  }
}