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

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

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

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

• पसंद के मुताबिक बनाया गया 404/पेज नहीं मिला वाला पेज दिखाना. इसका तरीका जानें.

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

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

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

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

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

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

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

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

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

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

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

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

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

ज़रूरी नहीं
ignore एट्रिब्यूट से, डिप्लॉय करते समय अनदेखी की जाने वाली फ़ाइलों के बारे में पता चलता है. यह .gitignore को उसी तरह से हैंडल करता है जिस तरह Git, globs को हैंडल करता है.

इग्नोर की जाने वाली फ़ाइलों के लिए डिफ़ॉल्ट वैल्यू ये हैं:

"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 को रीडायरेक्ट करने का ट्रिगर करे. इससे, Hosting तय किए गए डेस्टिनेशन यूआरएल पर रीडायरेक्ट कर पाएगा.

redirects एट्रिब्यूट के लिए बुनियादी स्ट्रक्चर यहां दिया गया है. इस उदाहरण में, /foo पर किए गए अनुरोधों को /foo पर रीडायरेक्ट किया गया है. इसके लिए, /foo पर नया अनुरोध किया गया है./bar

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

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

फिर से लिखने की सुविधा कॉन्फ़िगर करना

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

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

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

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

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

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

अगर hosting.rewrites कॉन्फ़िगरेशन के function ब्लॉक में region को शामिल नहीं किया जाता है, तो Firebase सीएलआई, फ़ंक्शन के सोर्स कोड से क्षेत्र का अपने-आप पता लगाने की कोशिश करता है. अगर क्षेत्र की जानकारी नहीं दी जाती है, तो डिफ़ॉल्ट रूप से us-central1 का इस्तेमाल किया जाता है. अगर फ़ंक्शन का सोर्स कोड उपलब्ध नहीं है, तो सीएलआई, डिप्लॉय किए गए फ़ंक्शन से क्षेत्र का पता लगाने की कोशिश करता है. अगर फ़ंक्शन कई क्षेत्रों में है, तो सीएलआई को region कॉन्फ़िगरेशन में 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 पर डिप्लॉय करने के बाद (firebase deploy का इस्तेमाल करके), आपके फ़ंक्शन को इन यूआरएल से ऐक्सेस किया जा सकता है:

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

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

जब Firebase Hosting किसी फ़ंक्शन को ट्रैफ़िक फ़ॉरवर्ड करता है, तो फ़ंक्शन को अनुरोध का पूरा ओरिजनल पाथ और क्वेरी स्ट्रिंग मिलती है. उदाहरण के लिए, आपकी Hosting साइट पर /bigben/hello/world?foo=bar का अनुरोध, फ़ंक्शन को पूरे पाथ और क्वेरी के साथ भेजा जाता है. पक्का करें कि आपका फ़ंक्शन हैंडलर, पूरे ऐब्सलूट यूआरएल को हैंडल करने के लिए लिखा गया हो. सिर्फ़ रीराइट में तय किए गए बेस पाथ को हैंडल करने के लिए नहीं.

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

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

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

अगर hosting.rewrites कॉन्फ़िगरेशन के run ब्लॉक में "pinTag": true जोड़ा जाता है, तो आपके स्टैटिक 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

ध्यान दें: Firebase डाइनैमिक लिंक की सुविधा अब काम नहीं करती. इसलिए, नए प्रोजेक्ट में इसका इस्तेमाल नहीं किया जाना चाहिए. यह सेवा जल्द ही बंद हो जाएगी. ज़्यादा जानकारी के लिए, डेटा को दूसरी जगह भेजने से जुड़ी गाइड पढ़ें. साथ ही, डाइनैमिक लिंक बंद होने के बारे में अक्सर पूछे जाने वाले सवाल देखें.

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

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

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

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

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

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

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

.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 — यह 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",

  }
}