फायरबेस होस्टिंग के साथ, आप अपनी साइट के अनुरोधों के लिए अनुकूलित होस्टिंग व्यवहार को कॉन्फ़िगर कर सकते हैं।
आप होस्टिंग के लिए क्या कॉन्फ़िगर कर सकते हैं?
निर्दिष्ट करें कि आपके स्थानीय प्रोजेक्ट डायरेक्टरी में कौन सी फाइलें आप फायरबेस होस्टिंग पर तैनात करना चाहते हैं। कैसे सीखें।
अनुकूलित 404 / नहीं मिला पृष्ठ परोसें। कैसे सीखें।
आपके द्वारा स्थानांतरित या हटाए गए पृष्ठों के लिए
redirects
सेट करें। कैसे सीखें।इनमें से किसी भी उद्देश्य के लिए
rewrites
सेट करें:एकाधिक URL के लिए समान सामग्री दिखाएं। कैसे सीखें।
एक फ़ंक्शन परोसें या एक होस्टिंग URL से क्लाउड रन कंटेनर तक पहुंचें। जानें कैसे: समारोह या कंटेनर ।
एक कस्टम डोमेन डायनामिक लिंक बनाएं। कैसे सीखें।
किसी अनुरोध या प्रतिक्रिया के बारे में अतिरिक्त जानकारी पास करने के लिए
headers
जोड़ें, जैसे कि ब्राउज़र को पृष्ठ और उसकी सामग्री (प्रमाणीकरण, कैशिंग, एन्कोडिंग, आदि) को कैसे संभालना चाहिए। कैसे सीखें।उपयोगकर्ता की भाषा की वरीयता और / या देश के आधार पर विशिष्ट सामग्री की सेवा के लिए अंतर्राष्ट्रीयकरण (i18n) को फिर से लिखना। जानिए कैसे (अलग पेज)।
आप अपने होस्टिंग कॉन्फ़िगरेशन को कहाँ परिभाषित करते हैं?
आप अपने में अपने Firebase होस्टिंग विन्यास को परिभाषित firebase.json
फ़ाइल। जब आप firebase init
कमांड चलाते हैं, तो firebase init
आपके प्रोजेक्ट डायरेक्टरी के रूट में आपकी firebase.json
फाइल को स्वचालित रूप से बनाता है।
आप इस पृष्ठ के निचले भाग में एक पूर्ण firebase.json
कॉन्फ़िगरेशन उदाहरण (केवल फायरबेस होस्टिंग को कवर करके) पा सकते हैं। ध्यान दें कि एक firebase.json
फ़ाइल में अन्य Firebase सेवाओं के लिए विन्यास भी हो सकता है।
आप होस्टिंग रेस्ट एपीआई का उपयोग करके तैनात firebase.json
सामग्री की जांच कर सकते हैं।
होस्टिंग प्रतिक्रियाओं की प्राथमिकता क्रम
इस पृष्ठ पर वर्णित विभिन्न फायरबेस होस्टिंग विन्यास विकल्प कभी-कभी ओवरलैप कर सकते हैं। यदि कोई विरोध है, तो होस्टिंग निम्नलिखित प्राथमिकता क्रम का उपयोग करके अपनी प्रतिक्रिया निर्धारित करता है:
- आरक्षित नामस्थान जो
/__/*
पथ खंड से शुरू होते हैं - कॉन्फ़िगर किए गए पुनर्निर्देश
- सटीक मिलान स्थिर सामग्री
- कॉन्फ़िगर किया गया फिर से लिखना
- कस्टम 404 पेज
- डिफ़ॉल्ट 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
} ]
}
"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
विशेषता में पुनर्निर्देशित नियमों की एक सरणी होती है, जहां प्रत्येक नियम में नीचे दी गई तालिका में फ़ील्ड शामिल होना चाहिए।
फायरबेस होस्टिंग हर अनुरोध के प्रारंभ में (ब्राउज़र द्वारा यह निर्धारित करने से पहले कि फ़ाइल या फ़ोल्डर उस पथ पर मौजूद है) सभी URL पथों के विरुद्ध source
या regex
मान की तुलना करता है। यदि कोई मेल पाया जाता है, तो फायरबेस होस्टिंग मूल सर्वर destination
URL पर एक नया अनुरोध करने के लिए ब्राउज़र को बताकर एक HTTPS पुनर्निर्देशित प्रतिक्रिया भेजता है।
मैदान | विवरण | |
---|---|---|
redirects | ||
source (अनुशंसित)या regex | एक URL पैटर्न, जो यदि प्रारंभिक अनुरोध URL से मेल खाता है, तो पुनर्निर्देशन को लागू करने के लिए होस्टिंग को ट्रिगर करता है
| |
destination | एक स्थिर यूआरएल जहां ब्राउज़र को एक नया अनुरोध करना चाहिए यह URL एक सापेक्ष या निरपेक्ष पथ हो सकता है। | |
type | HTTPS प्रतिक्रिया कोड
|
रीडायरेक्ट के लिए URL सेगमेंट कैप्चर करें
ऐच्छिक
कभी-कभी, आपको रीडायरेक्ट नियम के URL पैटर्न ( source
या regex
मान) के विशिष्ट खंडों को पकड़ने की आवश्यकता हो सकती है, फिर नियम के destination
पथ में इन खंडों को फिर से उपयोग करें।
यदि आप एक source
फ़ील्ड का उपयोग कर रहे हैं (जो आपके URL पैटर्न के लिए ग्लोब निर्दिष्ट कर रहा है), तो आप सेगमेंट को पहचानने के लिए a :
prefix को शामिल करके सेगमेंट पर कब्जा कर सकते हैं। यदि आपको खंड के बाद शेष URL पथ पर कब्जा करने की आवश्यकता है, तो खंड के तुरंत बाद एक *
शामिल करें। उदाहरण के लिए:
"hosting": { // ... "redirects": [ { "source": "/blog/:post*", // captures the entire URL segment beginning at "post" "destination": "https://blog.myapp.com/:post", // includes the entire URL segment identified and captured by the "source" value "type": 301 }, { "source": "/users/:id/profile", // captures only the URL segment "id", but nothing following "destination": "/users/:id/newProfile", // includes the URL segment identified and captured by the "source" value "type": 301 } ] }
यदि आप एक regex
फ़ील्ड का उपयोग कर रहे हैं (जो कि आपके URL पैटर्न के लिए RE2 नियमित अभिव्यक्ति निर्दिष्ट कर रहा है), तो आप या तो नामित या अनाम RE2 कैप्चर समूहों का उपयोग करके सेगमेंट पर कब्जा कर सकते हैं। नामित कैप्चर समूहों का उपयोग destination
फ़ील्ड में a :
उपसर्ग के साथ किया जा सकता है, जबकि अनाम कैप्चर समूहों को regex
मान में उनके संख्यात्मक सूचकांक द्वारा संदर्भित किया जा सकता है, 1 से अनुक्रमित। उदाहरण के लिए:
"hosting": { // ... "redirects": [ { "regex": "/blog/(?P<post>.+)", // if you're familiar with PCRE, be aware that RE2 requires named capture groups to begin with ?P "destination": "https://blog.myapp.com/:post", // includes the entire URL segment identified and captured by the `regex` value "type": 301 }, { "regex": "/users/(\d+)/profile", // uses the \d directive to only match numerical path segments "destination": "/users/:1/newProfile", // the first capture group to be seen in the `regex` value is named 1, and so on "type": 301 } ] }
पुनः कॉन्फ़िगर करें
ऐच्छिक
एक से अधिक URL के लिए समान सामग्री दिखाने के लिए पुनर्लेखन का उपयोग करें। रिवाइटर पैटर्न मिलान के साथ विशेष रूप से उपयोगी होते हैं, क्योंकि आप पैटर्न से मेल खाने वाले किसी भी 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"
} ]
}
"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 केवल एक पुनर्लेखन नियम लागू करता है यदि कोई फ़ाइल या निर्देशिका किसी 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 |
| |
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": "*"
} ]
} ]
}
"hosting": { // ... // Add the "headers" attribute within "hosting" "headers": [ { // Applies a CORS header for all font files "source": "**/*.@(eot|otf|ttf|ttc|woff|font.css)", "headers": [ { "key": "Access-Control-Allow-Origin", "value": "*" } ] }, { // Overrides the default 1 hour browser cache with a 2 hour cache for all image files "source": "**/*.@(jpg|jpeg|gif|png)", "headers": [ { "key": "Cache-Control", "value": "max-age=7200" } ] }, { // A regular expression-based rewrite equivalent to the above behavior "regex": ".+/\w+\.(jpg|jpeg|gif|png)$", "headers": [ { "key": "Cache-Control", "value": "max-age=7200" } ] }, { // Sets the cache header for 404 pages to cache for 5 minutes "source": "404.html", "headers": [ { "key": "Cache-Control", "value": "max-age=300" } ] } ] }
headers
विशेषता में परिभाषाओं की एक सरणी होती है, जहां प्रत्येक परिभाषा में नीचे दी गई तालिका में फ़ील्ड शामिल होनी चाहिए।
मैदान | विवरण | ||
---|---|---|---|
headers | |||
source (अनुशंसित)या regex | एक URL पैटर्न, जो यदि प्रारंभिक अनुरोध URL से मेल खाता है, तो कस्टम हेडर को लागू करने के लिए होस्टिंग को ट्रिगर करता है
अपने कस्टम 404 पेज के विरुद्ध मिलान करने के लिए एक हेडर बनाने के लिए, | ||
सरणी (उप-) headers | कस्टम हेडर जो होस्टिंग अनुरोध पथ पर लागू होता है प्रत्येक उप-हेडर में एक | ||
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 सेवाओं के लिए विन्यास भी हो सकता है।