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

Firebase Hosting की मदद से, अपनी साइट पर किए गए अनुरोधों के लिए, होस्टिंग के व्यवहार को पसंद के मुताबिक कॉन्फ़िगर किया जा सकता है.

Hosting के लिए क्या कॉन्फ़िगर किया जा सकता है?

• बताएं कि आपको अपनी लोकल प्रोजेक्ट डायरेक्ट्री में किन फ़ाइलों को डिप्लॉय करना है Firebase Hosting. इसका तरीका जानें.

• अपनी पसंद के मुताबिक बनाया गया 404/Not Found पेज दिखाएं. इसका तरीका जानें.

• जिन पेजों को आपने माइग्रेट किया है या मिटा दिया है उनके लिए, redirects सेट अप करें. इसका तरीका जानें.

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

  • कई यूआरएल के लिए एक ही कॉन्टेंट दिखाएं. इसका तरीका जानें.

  • कोई फ़ंक्शन इस्तेमाल करें या Hosting से Cloud Run कंटेनर ऐक्सेस करें यूआरएल. इसका तरीका जानें: फ़ंक्शन या कंटेनर.

  • कस्टम डोमेन बनाएं Dynamic Link. इसका तरीका जानें.

• किसी अनुरोध के बारे में ज़्यादा जानकारी देने के लिए headers जोड़ें या रिस्पॉन्स, जैसे कि ब्राउज़र को पेज और उसके कॉन्टेंट को किस तरह हैंडल करना चाहिए (पुष्टि करना, कैश मेमोरी, कोड में बदलने का तरीका वगैरह). इसका तरीका जानें.

• कॉन्टेंट के हिसाब से खास कॉन्टेंट दिखाने के लिए, इंटरनैशनलाइज़ेशन (i18n) रीराइट सेट अप करना उपयोगकर्ता की भाषा प्राथमिकता और/या देश पर. इसका तरीका जानें (दूसरा पेज).

Hosting का कॉन्फ़िगरेशन कहां तय किया जाता है?

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

चेतावनी: firebase init को फिर से चलाने और Hosting चुनने पर, कमांड firebase.json फ़ाइल के hosting सेक्शन को डिफ़ॉल्ट कॉन्फ़िगरेशन.

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

डिप्लॉय किए गए firebase.json कॉन्टेंट को देखने के लिए, इनका इस्तेमाल करें: Hosting REST API.

Hosting जवाबों का प्राथमिकता क्रम

इस पेज पर बताए गए Firebase Hosting कॉन्फ़िगरेशन के अलग-अलग विकल्प, कभी-कभी ओवरलैप हो सकते हैं. अगर कोई विरोध होता है, तो Hosting प्राथमिकता के इस क्रम का इस्तेमाल करके जवाब तय करता है:

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

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

अगर i18n रीराइट का इस्तेमाल किया जा रहा है, तो पूरी तरह मेल खाने वाली वैल्यू और 404 हैंडलिंग प्राथमिकता क्रम को आपके "i18n" के दायरे में बढ़ाया गया है कॉन्टेंट".

यह तय करना कि कौनसी फ़ाइलें डिप्लॉय करनी हैं

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

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

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

सार्वजनिक

ज़रूरी है
public एट्रिब्यूट से यह पता चलता है कि किस डायरेक्ट्री में डिप्लॉय करना हैFirebase Hosting. डिफ़ॉल्ट वैल्यू, 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 कॉन्टेंट जोड़ें.

Firebase Hosting, इस कस्टम 404.html पेज का कॉन्टेंट तब दिखाएगा, जब किसी ब्राउज़र से आपके डोमेन या सबडोमेन पर 404 Not Found गड़बड़ी ट्रिगर होती है.

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

ज़रूरी नहीं है
अगर आपने किसी पेज को दूसरी जगह पर ले जाया है, तो काम न करने वाले लिंक को रोकने के लिए, यूआरएल रीडायरेक्ट का इस्तेमाल करें या यूआरएल को छोटा करने के लिए किया जा सकता है. उदाहरण के लिए, आप ब्राउज़र को यहां से रीडायरेक्ट कर सकते हैं: example.com/team से example.com/about.html के लिए.

redirects एट्रिब्यूट बनाकर, यूआरएल रीडायरेक्ट के बारे में बताएं, जिसमें कलेक्शन मौजूद हो ऑब्जेक्ट (जिन्हें "रीडायरेक्ट नियम" कहा जाता है) के. हर नियम में, एक ऐसा यूआरएल पैटर्न डालें जो अनुरोध वाले यूआरएल पाथ से मैच करता हो. इससे, Hosting को ट्रिगर किया जाता है, ताकि वह तय किए गए डेस्टिनेशन यूआरएल पर रीडायरेक्ट करके जवाब दे सके.

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

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

फ़ील्ड		ब्यौरा
redirects
	source (सुझाया गया) या regex	ऐसा यूआरएल पैटर्न जो शुरुआती अनुरोध यूआरएल से मैच होने पर, रीडायरेक्ट लागू करने के लिए Hosting को ट्रिगर करता है source का इस्तेमाल करके ग्लोब (सुझाया गया). regex का इस्तेमाल करके RE2 रेगुलर एक्सप्रेशन.
	destination	स्टैटिक यूआरएल, जहां ब्राउज़र को नया अनुरोध करना चाहिए यह यूआरएल कोई मिलता-जुलता या ऐब्सलूट पाथ हो सकता है.
	type	एचटीटीपीएस रिस्पॉन्स कोड 'स्थानांतरित हो गया' के लिए, 301 टाइप का इस्तेमाल करें 'मिल गया' के लिए 302 के टाइप का इस्तेमाल करें (अस्थायी रीडायरेक्ट)

अहम जानकारी: redirects एट्रिब्यूट में, Hosting first नियम के मुताबिक तय किया गया रीडायरेक्ट लागू करता है. यह रीडायरेक्ट, अनुरोध किए गए पाथ से मैच करने वाले यूआरएल पैटर्न के साथ लागू होता है. इसलिए, आपको 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 रेगुलर एक्सप्रेशन का इस्तेमाल करते समय यूआरएल सेगमेंट कैप्चर करें

अगर regex फ़ील्ड का इस्तेमाल किया जा रहा है, जिसमें RE2 रेगुलर एक्सप्रेशन शामिल है आपके यूआरएल पैटर्न के लिए), तो आप नाम या बिना नाम वाले सेगमेंट का इस्तेमाल करके सेगमेंट कैप्चर कर सकते हैं RE2 कैप्चर ग्रुप. 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 pushState नेविगेशन के लिए. जब कोई ब्राउज़र, तय किए गए source या regex यूआरएल पैटर्न से मैच करने वाला यूआरएल पाथ खोलने की कोशिश करता है, तो ब्राउज़र को destination यूआरएल पर मौजूद फ़ाइल का कॉन्टेंट दिखेगा.

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

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

फ़ील्ड		ब्यौरा
rewrites
	source (सुझाया गया) या regex	शुरुआती अनुरोध के यूआरएल से मेल खाने वाला यूआरएल पैटर्न, ट्रिगर होता है फिर से लिखने के लिए Hosting source का इस्तेमाल करके ग्लोब (सुझाया गया). regex का इस्तेमाल करके RE2 रेगुलर एक्सप्रेशन.
	destination	एक लोकल फ़ाइल, जो मौजूद होनी चाहिए यह यूआरएल कोई मिलता-जुलता या ऐब्सलूट पाथ हो सकता है.

अहम जानकारी: rewrites एट्रिब्यूट में, Hosting उस रीराइट को लागू करता है जिसे पहले नियम के हिसाब से तय किया गया है. यह रीराइट, अनुरोध किए गए पाथ से मैच करने वाले यूआरएल पैटर्न के साथ लागू होता है. इसलिए, आपको rewrites एट्रिब्यूट में नियमों को ध्यान से क्रम में लगाना होगा.

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

Firebase Hosting यूआरएल से फ़ंक्शन दिखाने के लिए, rewrites का इस्तेमाल किया जा सकता है. कॉन्टेंट बनाने नीचे दिया गया उदाहरण Cloud Functions का इस्तेमाल करके लगातार अपडेट होने वाली जानकारी दिखाना.

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

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

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

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

कैसे pinTag, function ब्लॉक में काम करता है

pinTag की सुविधा सिर्फ़ Cloud Functions for Firebase (2nd gen) में उपलब्ध है. इस सुविधा की मदद से, यह पक्का किया जा सकता है कि साइट की लगातार अपडेट होने वाली जानकारी को आपके स्टैटिक Hosting संसाधनों के साथ सिंक रखा जाता है और Hosting कॉन्फ़िगरेशन. साथ ही, इस सुविधा की मदद से आपके जवाबों की झलक देखी जा सकती है Hosting प्रीव्यू चैनल पर फ़ंक्शन के लिए.

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

ध्यान दें: अगर मौजूदा रीराइट में pinTag जोड़ा जाता है, तो पहले आपको डिप्लॉय करना होगा आपके "लाइव" के लिए अपडेट किया गया रीराइट चैनल. इसके बाद, आपको Hosting झलक चैनल में अपने फ़ंक्शन के कोड में हुए बदलावों की झलक देखें इससे प्रोडक्शन पर कोई असर नहीं पड़ता.

यह सुविधा इन बातों पर निर्भर करती है: Cloud Run टैग, जिसमें हर सेवा के लिए ज़्यादा से ज़्यादा 1,000 टैग और हर क्षेत्र में 2,000 टैग हो सकते हैं. इसका मतलब है कि सैकड़ों डिप्लॉयमेंट के बाद, किसी साइट के सबसे पुराने वर्शन काम करना बंद कर सकते हैं.

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

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

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

Hosting वाले फ़ंक्शन पर अनुरोधों को रीडायरेक्ट करते समय, काम करने वाला एचटीटीपी अनुरोध तरीके GET, POST, HEAD, PUT, DELETE, PATCH, और OPTIONS हैं. REPORT या PROFIND जैसे दूसरे तरीके काम नहीं करते.

Cloud Run कंटेनर के लिए किए गए सीधे अनुरोध

आप rewrites का इस्तेमाल करकेCloud Run Firebase Hosting यूआरएल. यहां दिया गया उदाहरण, Cloud Run का इस्तेमाल करके डाइनैमिक कॉन्टेंट दिखाने के बारे में जानकारी का एक हिस्सा है.

उदाहरण के लिए, /helloworld पेज से सभी अनुरोधों को अपने helloworld कंटेनर को शुरू करने और चलाने को ट्रिगर करने के लिए Hosting साइट उदाहरण:

"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 ब्लॉक में काम करता है

इस सुविधा के साथ, आप पक्का कर सकते हैं कि आपके Cloud Run का संशोधन आपकी साइट की गतिशील सामग्री जनरेट करने की सेवा को आपके साथ सिंक में रखा जाता है स्टैटिक Hosting रिसॉर्स और Hosting कॉन्फ़िगरेशन. साथ ही, इस सुविधा की मदद से आपको Hosting पर Cloud Run में फिर से लिखे गए कॉन्टेंट की झलक देखने को मिलेगी चैनल.

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

यह सुविधा इन बातों पर निर्भर करती है: Cloud Run टैग, जिसमें हर सेवा के लिए ज़्यादा से ज़्यादा 1,000 टैग और हर क्षेत्र में 2,000 टैग हो सकते हैं. इसका मतलब है कि सैकड़ों डिप्लॉयमेंट के बाद, किसी साइट के सबसे पुराने वर्शन काम करना बंद कर सकते हैं.

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

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

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

Hosting वाले Cloud Run कंटेनर पर अनुरोधों को रीडायरेक्ट करते समय, काम करने वाले एचटीटीपी अनुरोध के तरीके GET, POST, HEAD, PUT, DELETE हैं, PATCH और OPTIONS. REPORT या PROFIND जैसे दूसरे तरीके समर्थित हैं.

सबसे अच्छी परफ़ॉर्मेंस के लिए, Cloud Run की सेवा को Hosting के साथ सेट करें. इसके लिए, इन क्षेत्रों का इस्तेमाल करें:

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

Hosting के Cloud Run में लिखे गए टेक्स्ट को इस तरह से लिखा गया है: इन इलाकों में:

• 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

कस्टम डोमेन Dynamic Links बनाएं

कस्टम डोमेन Dynamic Links बनाने के लिए, rewrites का इस्तेमाल किया जा सकता है. Dynamic Links पर जाएं दस्तावेज़, जिसमें Dynamic Links के लिए कस्टम डोमेन सेट अप करना.

• Dynamic Links के लिए सिर्फ़ अपने कस्टम डोमेन का इस्तेमाल करें

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

• Dynamic Links में इस्तेमाल करने के लिए, कस्टम डोमेन पाथ के प्रीफ़िक्स डालें

  "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 फ़ाइल में Dynamic Links को कॉन्फ़िगर करने के लिए ये चीज़ें ज़रूरी हैं:

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

अहम जानकारी: Dynamic Links के लिए, ख़ास तौर पर इन बातों का ध्यान रखें होस्टिंग प्राथमिकता क्रम.

• पक्का करें कि आपका Dynamic Links यूआरएल प्रीफ़िक्स, ऊपर दिए गए यूआरएल से मेल न खाता हो प्राथमिकता वाले होस्टिंग कॉन्फ़िगरेशन (उदाहरण के लिए, होस्ट किया गया स्टैटिक कॉन्टेंट हमेशा को प्राथमिकता दी जाती है).
• हर redirects और rewrites के अंदर एट्रिब्यूट के लिए, Hosting यूआरएल पैटर्न वाला पहला नियम, जो अनुरोध किए गए पाथ से मेल खाता है. इसलिए, आपको प्रत्येक कीवर्ड के लिए redirects और rewrites एट्रिब्यूट.

ज़्यादा जानकारी के लिए, इसे देखें Dynamic Links दस्तावेज़.

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

ज़रूरी नहीं है
हेडर की मदद से, क्लाइंट और सर्वर ज़्यादा जानकारी भेज सकते हैं अनुरोध या जवाब भेज सकते हैं. हेडर के कुछ सेट, ब्राउज़र के काम करने के तरीके पर असर डाल सकते हैं यह पेज और उसके कॉन्टेंट को मैनेज करता है. इसमें ऐक्सेस कंट्रोल, पुष्टि करना, कैश मेमोरी में सेव करने और कोड में बदलने का तरीका.

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

यहां headers एट्रिब्यूट का बुनियादी स्ट्रक्चर दिया गया है. यह उदाहरण लागू होता है सभी फ़ॉन्ट फ़ाइलों के लिए सीओआरएस हेडर.

"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		शुरुआती अनुरोध के यूआरएल से मेल खाने वाला यूआरएल पैटर्न, ट्रिगर होता है कस्टम हेडर लागू करने के लिए Hosting source का इस्तेमाल करके ग्लोब (सुझाया गया). regex का इस्तेमाल करके RE2 रेगुलर एक्सप्रेशन. अपने कस्टम 404 पेज, 404.html का इस्तेमाल अपने source या regex वैल्यू.
	(sub-)headers का कलेक्शन		कस्टम हेडर, जो Hosting अनुरोध पाथ पर लागू होते हैं हर सब-हेडर में key और value जोड़ी (अगली दो पंक्तियां देखें).
		key	हेडर का नाम, उदाहरण के लिए Cache-Control
		value	हेडर के लिए वैल्यू, जैसे कि max-age=7200

ध्यान दें: कस्टम हेडर के लिए, यूआरएल पैटर्न को किसी भी हेडर से पहले मैच किया जाता है कॉन्टेंट को फिर से लिखने के नियम लागू होते हैं.

Cache-Control के बारे में ज़्यादा जानने के लिए, यहां जाएं: Hosting सेक्शन, जिसमें डाइनैमिक कॉन्टेंट दिखाने और होस्टिंग की जानकारी दी गई है माइक्रोसर्विस. इसके बारे में ज़्यादा जानने के लिए, सीओआरएस हेडर.

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

.html एक्सटेंशन को कंट्रोल करें

ज़रूरी नहीं
cleanUrls एट्रिब्यूट की मदद से, यह कंट्रोल किया जा सकता है कि यूआरएल में .html एक्सटेंशन शामिल करना है या नहीं.

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

यूआरएल में .html को शामिल करने के कंट्रोल को कंट्रोल करने का तरीका यहां बताया गया है cleanUrls एट्रिब्यूट:

"hosting": {
  // ...

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

ट्रेलिंग स्लैश को कंट्रोल करना

ज़रूरी नहीं है
trailingSlash एट्रिब्यूट की मदद से यह कंट्रोल किया जा सकता है कि स्टैटिक है या नहीं कॉन्टेंट के यूआरएल में आखिर में स्लैश होने चाहिए.

• जब true, Hosting यूआरएल को रीडायरेक्ट करता है, तो आखिर में स्लैश जोड़ता है.
• जब false, Hosting पीछे के स्लैश को हटाने के लिए यूआरएल को रीडायरेक्ट करता है.
• अगर कोई वैल्यू नहीं दी जाती है, तो Hosting सिर्फ़ डायरेक्ट्री इंडेक्स फ़ाइलों के लिए आखिर में स्लैश का इस्तेमाल करता है (उदाहरण के लिए, about/index.html).

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

"hosting": {
  // ...

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

trailingSlash एट्रिब्यूट से, Cloud Functions या Cloud Run से दिखाए गए डाइनैमिक कॉन्टेंट को फिर से लिखने पर कोई असर नहीं पड़ता.

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

Firebase Hosting कॉन्फ़िगरेशन के विकल्प, extglob के साथ ग्लोब पैटर्न मैचिंग नोटेशन का ज़्यादा से ज़्यादा इस्तेमाल करते हैं. यह ठीक वैसा ही है जैसे Git, gitignore नियमों को मैनेज करता है और Bower, ignore नियमों को मैनेज करता है. यह विकी पेज ज़्यादा जानकारी के लिए है, लेकिन इस पेज पर इस्तेमाल किए गए उदाहरणों की पूरी जानकारी नीचे दी गई है:

• firebase.json — रूट में मौजूद सिर्फ़ firebase.json फ़ाइल से मेल खाता है public डायरेक्ट्री में से

• ** — आर्बिट्रेरी सब-डायरेक्ट्री में मौजूद किसी भी फ़ाइल या फ़ोल्डर से मेल खाता है

• * — सिर्फ़ रूट में मौजूद फ़ाइलों और फ़ोल्डर से मेल खाता है public डायरेक्ट्री

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

• **/node_modules/** — node_modules फ़ोल्डर की किसी भी सब-डायरेक्ट्री में मौजूद किसी भी फ़ाइल या फ़ोल्डर से मेल खाता है. यह सब-डायरेक्ट्री, public डायरेक्ट्री की किसी भी सब-डायरेक्ट्री में हो सकती है

• **/*.@(jpg|jpeg|gif|png) — किसी भी फ़ाइल को आर्बिट्रेरी तरीके से मैच करता है वह सब-डायरेक्ट्री जो इनमें से किसी एक से खत्म होती है: .jpg, .jpeg, .gif या .png

Hosting कॉन्फ़िगरेशन का पूरा उदाहरण

यहां firebase.json के लिए कॉन्फ़िगरेशन का पूरा उदाहरण दिया गया है Firebase Hosting. ध्यान दें कि 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",

  }
}