इस पेज का अनुवाद Cloud Translation API से किया गया है.

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

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

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

निर्दिष्ट करें कि आप अपनी स्थानीय प्रोजेक्ट निर्देशिका में कौन-सी फ़ाइलें Firebase होस्टिंग पर परिनियोजित करना चाहते हैं। सीखो कैसे।
अनुकूलित 404/नहीं मिला पृष्ठ परोसें। सीखो कैसे।
आपके द्वारा स्थानांतरित या हटाए गए पृष्ठों के लिए redirects सेट अप करें। सीखो कैसे।
इनमें से किसी भी उद्देश्य के लिए rewrites सेट अप करें:
- एकाधिक यूआरएल के लिए एक ही सामग्री दिखाएं। सीखो कैसे।
- किसी होस्टिंग URL से कोई फ़ंक्शन परोसें या क्लाउड रन कंटेनर एक्सेस करें। जानें कैसे: फ़ंक्शन या कंटेनर ।
- एक कस्टम डोमेन डायनेमिक लिंक बनाएँ। सीखो कैसे।
किसी अनुरोध या प्रतिक्रिया के बारे में अतिरिक्त जानकारी देने के लिए headers जोड़ें, जैसे ब्राउज़र को पृष्ठ और उसकी सामग्री (प्रमाणीकरण, कैशिंग, एन्कोडिंग, आदि) को कैसे संभालना चाहिए। सीखो कैसे।
उपयोगकर्ता की भाषा वरीयता और/या देश के आधार पर विशिष्ट सामग्री प्रस्तुत करने के लिए अंतर्राष्ट्रीयकरण (i18n) पुनर्लेखन सेट अप करें। जानें कैसे (अलग पेज)।

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

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

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

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

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

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

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

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

यदि आप 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 को संभालता है।

फ़ाइलों को अनदेखा करने के लिए निम्न डिफ़ॉल्ट मान हैं:

"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 एट्रिब्यूट के लिए ज़्यादा विस्तृत उदाहरण देखें

"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`	एक URL प्रतिमान, यदि प्रारंभिक अनुरोध URL से मेल खाता है, तो रीडायरेक्ट लागू करने के लिए होस्टिंग को ट्रिगर करता है ग्लोब निर्दिष्ट करने के लिए `source` उपयोग करें (अनुशंसित) । RE2 रेगुलर एक्सप्रेशन निर्दिष्ट करने के लिए `regex` उपयोग करें।
	`destination`	एक स्थिर यूआरएल जहां ब्राउजर को एक नया अनुरोध करना चाहिए यह URL एक सापेक्ष या निरपेक्ष पथ हो सकता है।
	`type`	HTTPS प्रतिक्रिया कोड 'स्थायी रूप से स्थानांतरित' के लिए `301` प्रकार का उपयोग करें 'पाया' (अस्थायी रीडायरेक्ट) के लिए `302` प्रकार का उपयोग करें

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

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

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

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

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

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

मैदान विवरण

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

rewrites

source (अनुशंसित)
या regex

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

ग्लोब निर्दिष्ट करने के लिए source उपयोग करें (अनुशंसित) ।
RE2 रेगुलर एक्सप्रेशन निर्दिष्ट करने के लिए regex उपयोग करें।

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)
    "pinTag": true           // optional (see note below)
  } ]
}

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

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

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

pinTag सुविधा केवल Firebase (2nd gen) के लिए क्लाउड फ़ंक्शंस में उपलब्ध है। इस सुविधा के साथ, आप यह सुनिश्चित कर सकते हैं कि आपकी साइट की गतिशील सामग्री उत्पन्न करने के लिए प्रत्येक कार्य को आपके स्थिर होस्टिंग संसाधनों और होस्टिंग कॉन्फ़िगरेशन के साथ समन्वयित रखा गया है। साथ ही, यह सुविधा आपको होस्टिंग पूर्वावलोकन चैनलों पर कार्यों के लिए अपने पुनर्लेखन का पूर्वावलोकन करने की अनुमति देती है।
यदि आप "pinTag": true को hosting.rewrites कॉन्फ़िगरेशन के function ब्लॉक में जोड़ते हैं, तो "पिन किए गए" फ़ंक्शन को आपके स्थिर होस्टिंग संसाधनों और कॉन्फ़िगरेशन के साथ तैनात किया जाएगा, यहां तक कि जब firebase deploy --only hosting चल रही हो। यदि आप अपनी साइट के किसी संस्करण को रोलबैक करते हैं, तो "पिन किया गया" फ़ंक्शन भी वापस रोलबैक हो जाता है।
नोट: यदि आप किसी मौजूदा पुनर्लेखन में एक pinTag जोड़ते हैं, तो आपको पहले अपने "लाइव" चैनल पर अद्यतन किए गए पुनर्लेखन को परिनियोजित करना होगा। उस परिनियोजन के बाद, आप उत्पादन को प्रभावित किए बिना होस्टिंग पूर्वावलोकन चैनलों में अपने फ़ंक्शन के कोड में परिवर्तनों का पूर्वावलोकन कर सकते हैं।
यह सुविधा क्लाउड रन टैग पर निर्भर करती है, जिसकी सीमा प्रति सेवा 1000 टैग और प्रति क्षेत्र 2000 टैग है। इसका अर्थ है कि सैकड़ों तैनाती के बाद, साइट के सबसे पुराने संस्करण काम करना बंद कर सकते हैं।

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

आपके फायरबेस सबडोमेन:
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)
   }
 } ]
}

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

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

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

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

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

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

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

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

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

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

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

"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`		एक URL प्रतिमान, जो यदि प्रारंभिक अनुरोध URL से मेल खाता है, तो कस्टम हेडर लागू करने के लिए होस्टिंग को ट्रिगर करता है ग्लोब निर्दिष्ट करने के लिए `source` उपयोग करें (अनुशंसित) । RE2 रेगुलर एक्सप्रेशन निर्दिष्ट करने के लिए `regex` उपयोग करें। अपने कस्टम 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",

  }
}