Google is committed to advancing racial equity for Black communities. See how.
इस पेज का अनुवाद Cloud Translation API से किया गया है.
Switch to English

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

जनता

अपेक्षित
public विशेषता निर्दिष्ट करती है कि कौन सी निर्देशिका फायरबेस होस्टिंग पर तैनात की जाए। डिफ़ॉल्ट मान public नाम की एक निर्देशिका है, लेकिन आप किसी भी निर्देशिका पथ को निर्दिष्ट कर सकते हैं, जब तक कि यह आपकी परियोजना निर्देशिका में मौजूद है।

निम्नलिखित को निर्दिष्ट करने के लिए निर्देशिका का डिफ़ॉल्ट निर्दिष्ट नाम है:

"hosting": {
  "public": "public"

  // ...
}

आप उस डिफ़ॉल्ट मान को उस निर्देशिका में बदल सकते हैं जिसे आप तैनात करना चाहते हैं:

"hosting": {
  "public": "dist/app"

  // ...
}

नज़रअंदाज़ करना

ऐच्छिक
ignore विशेषता फ़ाइलों को परिनियोजित करने के लिए अनदेखा करती है। यह ले जा सकते हैं globs एक ही तरीका है कि 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 / Not Found पेज कस्टमाइज़ करें

ऐच्छिक
जब कोई उपयोगकर्ता किसी ऐसे पेज को एक्सेस करने की कोशिश करता है जो मौजूद नहीं है, तो आप एक कस्टम 404 Not Found त्रुटि परोस सकते हैं।

अपनी परियोजना की public निर्देशिका में एक नई फ़ाइल बनाएँ, इसे 404.html नाम दें, फिर फ़ाइल में अपना कस्टम 404 Not Found सामग्री जोड़ें।

फायरबेस होस्टिंग इस कस्टम 404.html पेज की सामग्री को प्रदर्शित करेगा यदि कोई ब्राउज़र आपके डोमेन या उप डोमेन पर 404 Not Found त्रुटि चलाता है।

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

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

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

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

मैदान विवरण
redirects
source (अनुशंसित)
या regex

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

destination

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

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

type

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

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

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

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

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

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

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

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

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

मैदान विवरण
rewrites
source (अनुशंसित)
या regex

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

destination

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

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

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

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

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

"hosting": {
  // ...

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

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

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

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

क्लाउड रन कंटेनर में प्रत्यक्ष अनुरोध

आप फायरबेस होस्टिंग 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 deploy का उपयोग करके) को firebase deploy , आपकी कंटेनर छवि निम्नलिखित URL के माध्यम से उपलब्ध है:

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

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

आप कस्टम डोमेन डायनामिक लिंक बनाने के लिए 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
      } ]
    }
    
  • डायनामिक लिंक के लिए उपयोग करने के लिए कस्टम डोमेन पथ उपसर्ग निर्दिष्ट करें

    ०० बी १३३४२ ए ०

अपने firebase.json में डायनामिक लिंक्स को कॉन्फ़िगर करना। 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 बारे में और जान सकते हैं जो डायनामिक कंटेंट परोसने और माइक्रोसॉफ़्ट की मेजबानी करने का वर्णन करता है। आप कोर हेडर के बारे में अधिक जान सकते हैं।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

0488bbb870