如果您在构建服务器端渲染的 Angular 或 Next.js 应用，不妨试试我们新一代的 Firebase App Hosting，这是一款适用于现代 Web 框架的全栈解决方案。

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

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

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

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

बताएं कि आपको अपनी लोकल प्रोजेक्ट डायरेक्ट्री में से किन फ़ाइलों को Firebase Hosting पर डिप्लॉय करना है. इसका तरीका जानें.
अपनी पसंद के मुताबिक बनाया गया 404/Not Found पेज दिखाएं. इसका तरीका जानें.
उन पेजों के लिए redirects सेट अप करें जिन्हें आपने किसी दूसरे पेज पर ले जाया है या मिटाया है. इसका तरीका जानें.
इनमें से किसी भी मकसद के लिए rewrites सेट अप करें:
- एक से ज़्यादा यूआरएल के लिए एक ही कॉन्टेंट दिखाएं. इसका तरीका जानें.
- Hosting यूआरएल से कोई फ़ंक्शन दिखाएं या Cloud Run कंटेनर को ऐक्सेस करें. इसका तरीका जानें: फ़ंक्शन या कंटेनर.
- कस्टम डोमेन बनाएं Dynamic Link. इसका तरीका जानें.
किसी अनुरोध या जवाब के बारे में ज़्यादा जानकारी देने के लिए, headers जोड़ें. जैसे, ब्राउज़र को पेज और उसके कॉन्टेंट को कैसे मैनेज करना चाहिए (पुष्टि करना, कैश मेमोरी में सेव करना, कोड में बदलना वगैरह). इसका तरीका जानें.
उपयोगकर्ता की भाषा की प्राथमिकता और/या देश के हिसाब से खास कॉन्टेंट दिखाने के लिए, इंटरनैशनलाइज़ेशन (i18n) रीराइट सेट अप करें. इसका तरीका जानें (अलग पेज).

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

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

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

डिप्लॉय किए गए firebase.json कॉन्टेंट की जांच करने के लिए, Hosting REST API का इस्तेमाल किया जा सकता है.

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

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

/__/* पाथ सेगमेंट से शुरू होने वाले रिज़र्व किए गए नेमस्पेस
कॉन्फ़िगर किए गए रीडायरेक्ट
एग्ज़ैक्ट मैच वाला स्टैटिक कॉन्टेंट
कॉन्फ़िगर की गई रीराइट
पसंद के मुताबिक बनाया गया 404 पेज
डिफ़ॉल्ट 404 पेज

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

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

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

डिफ़ॉल्ट firebase.json फ़ाइल में शामिल डिफ़ॉल्ट एट्रिब्यूट — public और ignore — से यह तय होता है कि आपकी प्रोजेक्ट डायरेक्ट्री में मौजूद कौनसी फ़ाइलों को 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 कॉन्टेंट जोड़ें.

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

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

ज़रूरी नहीं
अगर आपने किसी पेज को दूसरी जगह ले जाया है, तो यूआरएल रीडायरेक्ट का इस्तेमाल करके, यूआरएल के गड़बड़ होने से रोकें. इसके अलावा, यूआरएल को छोटा करने के लिए भी इसका इस्तेमाल किया जा सकता है. उदाहरण के लिए, किसी ब्राउज़र को 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 को ट्रिगर करता है glob (सुझाया गया) तय करने के लिए, `source` का इस्तेमाल करें. RE2 रेगुलर एक्सप्रेशन तय करने के लिए, `regex` का इस्तेमाल करें.
	`destination`	स्टैटिक यूआरएल, जहां ब्राउज़र को नया अनुरोध करना चाहिए यह यूआरएल, रिलेटिव या ऐब्सलूट पाथ हो सकता है.
	`type`	एचटीटीपीएस रिस्पॉन्स कोड 'स्थानांतरित हो गया' के लिए, `301` टाइप का इस्तेमाल करें 'मिल गया' (कुछ समय के लिए रीडायरेक्ट) के लिए, `302` टाइप का इस्तेमाल करें

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

ज़रूरी नहीं
कभी-कभी आपको रीडायरेक्ट करने के नियम के यूआरएल पैटर्न (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
  } ]
}

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

ज़रूरी नहीं
एक से ज़्यादा यूआरएल के लिए एक ही कॉन्टेंट दिखाने के लिए, रीराइट का इस्तेमाल करें. रीराइट, पैटर्न मैचिंग के साथ खास तौर पर काम के होते हैं. इसकी मदद से, पैटर्न से मैच करने वाले किसी भी यूआरएल को स्वीकार किया जा सकता है. साथ ही, क्लाइंट-साइड कोड को यह तय करने दिया जा सकता है कि क्या दिखाना है.

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

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

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

rewrites

source (सुझाया गया)
या regex

यूआरएल का ऐसा पैटर्न जो शुरुआती अनुरोध यूआरएल से मैच होने पर, रीराइट लागू करने के लिए Hosting को ट्रिगर करता है

glob (सुझाया गया) तय करने के लिए, source का इस्तेमाल करें.
RE2 रेगुलर एक्सप्रेशन तय करने के लिए, regex का इस्तेमाल करें.

destination

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

यह यूआरएल कोई मिलता-जुलता या ऐब्सलूट पाथ हो सकता है.

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

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

उदाहरण के लिए, अपनी Hosting साइट के पेज /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)
    }
  } ]
}

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

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

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

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

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

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

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

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

आपके 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 कंटेनर को सीधे अनुरोध भेजना

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

उदाहरण के लिए, अपनी Hosting साइट के /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 ब्लॉक में

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

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

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

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

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

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

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

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

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

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

"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 कॉन्फ़िगरेशन के विकल्पों में, extग्लोब के साथ ग्लोब पैटर्न के मैचिंग नोटेशन का बहुत ज़्यादा इस्तेमाल किया जाता है. यह बिलकुल वैसे ही है जैसे Git, gitignore नियमों को और Bower ignore के नियमों को हैंडल करता है. यह विकी पेज ज़्यादा जानकारी वाला रेफ़रंस है. हालांकि, इस पेज पर इस्तेमाल किए गए उदाहरणों के बारे में यहां बताया गया है:

firebase.json — सिर्फ़ public डायरेक्ट्री की रूट में मौजूद firebase.json फ़ाइल से मैच करता है
** — किसी भी सब-डायरेक्ट्री में मौजूद किसी भी फ़ाइल या फ़ोल्डर से मेल खाता है
* — सिर्फ़ public डायरेक्ट्री के रूट में मौजूद फ़ाइलों और फ़ोल्डर से मैच करता है
**/.* — किसी भी आर्बिट्रेरी सब-डायरेक्ट्री में, . से शुरू होने वाली किसी भी फ़ाइल (आम तौर पर, छिपी हुई फ़ाइलें, जैसे कि .git फ़ोल्डर में) से मेल खाता है
**/node_modules/** — node_modules फ़ोल्डर की किसी भी सब-डायरेक्ट्री में मौजूद किसी भी फ़ाइल या फ़ोल्डर से मेल खाता है. यह सब-डायरेक्ट्री, public डायरेक्ट्री की किसी भी सब-डायरेक्ट्री में हो सकती है
**/*.@(jpg|jpeg|gif|png) — किसी भी सब-डायरेक्ट्री में मौजूद ऐसी किसी भी फ़ाइल से मैच करता है जिसका आखिरी हिस्सा इनमें से किसी एक से मेल खाता हो: .jpg, .jpeg, .gif या .png

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

यहां Firebase Hosting के लिए, 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",

  }
}