হোস্টিং আচরণ কনফিগার করুন

Firebase Hosting মাধ্যমে, আপনি আপনার সাইটের অনুরোধগুলোর জন্য নিজস্ব হোস্টিং আচরণ কনফিগার করতে পারেন।

Hosting জন্য কী কী কনফিগার করা যায়?

• আপনার লোকাল প্রজেক্ট ডিরেক্টরির কোন ফাইলগুলো Firebase Hosting এ ডেপ্লয় করতে চান, তা নির্দিষ্ট করুন। পদ্ধতিটি জেনে নিন।

• একটি কাস্টমাইজড ৪০৪/নট ফাউন্ড পেজ পরিবেশন করুন। জানুন কীভাবে।

• আপনার সরানো বা মুছে ফেলা পৃষ্ঠাগুলির জন্য redirects সেট আপ করুন। পদ্ধতিটি জেনে নিন।

• নিম্নলিখিত যেকোনো উদ্দেশ্যে rewrites সেট আপ করুন:

  • একাধিক ইউআরএল-এ একই কন্টেন্ট দেখান। পদ্ধতিটি জেনে নিন।

  • Hosting ইউআরএল থেকে কোনো ফাংশন পরিবেশন করুন বা Cloud Run কন্টেইনার অ্যাক্সেস করুন। পদ্ধতি জানুন: ফাংশন অথবা কন্টেইনার ।

  • কাস্টম ডোমেইনের জন্য Dynamic Link তৈরি করুন। পদ্ধতিটি জানুন।

• কোনো অনুরোধ বা প্রতিক্রিয়া সম্পর্কে অতিরিক্ত তথ্য জানাতে headers যোগ করুন, যেমন ব্রাউজারগুলো পৃষ্ঠা এবং এর বিষয়বস্তু কীভাবে পরিচালনা করবে (প্রমাণীকরণ, ক্যাশিং, এনকোডিং, ইত্যাদি)। পদ্ধতিটি জানুন।

• ব্যবহারকারীর ভাষার পছন্দ এবং/অথবা দেশের উপর ভিত্তি করে নির্দিষ্ট কন্টেন্ট পরিবেশন করতে আন্তর্জাতিকীকরণ (i18n) রিরাইট সেট আপ করুন। কীভাবে করবেন তা জানুন (অন্য পৃষ্ঠায়)।

আপনি আপনার Hosting কনফিগারেশন কোথায় নির্ধারণ করেন?

আপনি আপনার firebase.json ফাইলে আপনার Firebase Hosting কনফিগারেশন নির্ধারণ করেন। আপনি যখন ` firebase init কমান্ডটি চালান, তখন ফায়ারবেস স্বয়ংক্রিয়ভাবে আপনার প্রজেক্ট ডিরেক্টরির রুটে firebase.json ফাইলটি তৈরি করে।

আপনি এই পৃষ্ঠার একেবারে নিচে একটি সম্পূর্ণ firebase.json কনফিগারেশনের উদাহরণ (শুধুমাত্র Firebase Hosting জন্য) খুঁজে পাবেন। উল্লেখ্য যে, একটি firebase.json ফাইলে অন্যান্য Firebase পরিষেবাগুলির কনফিগারেশনও থাকতে পারে।

আপনি Hosting REST API ব্যবহার করে ডেপ্লয় করা firebase.json ফাইলের কন্টেন্ট চেক করতে পারেন।

Hosting প্রতিক্রিয়াগুলির অগ্রাধিকার ক্রম

এই পৃষ্ঠায় বর্ণিত বিভিন্ন Firebase Hosting কনফিগারেশন বিকল্পগুলি কখনও কখনও ওভারল্যাপ করতে পারে। যদি কোনও দ্বন্দ্ব দেখা দেয়, তাহলে Hosting নিম্নলিখিত অগ্রাধিকার ক্রম ব্যবহার করে তার প্রতিক্রিয়া নির্ধারণ করে:

1. সংরক্ষিত নেমস্পেস যা একটি /__/* পাথ সেগমেন্ট দিয়ে শুরু হয়
2. কনফিগার করা পুনঃনির্দেশ
3. সঠিক-মিল স্থির বিষয়বস্তু
4. কনফিগার করা পুনর্লিখন
5. কাস্টম ৪০৪ পৃষ্ঠা
6. ডিফল্ট ৪০৪ পৃষ্ঠা

আপনি যদি i18n রিরাইট ব্যবহার করেন, তাহলে আপনার "i18n কন্টেন্ট"-কে অন্তর্ভুক্ত করার জন্য এক্সাক্ট-ম্যাচ এবং 404 হ্যান্ডলিং-এর অগ্রাধিকার ক্রমের পরিধি প্রসারিত হয়।

কোন ফাইলগুলি স্থাপন করতে হবে তা নির্দিষ্ট করুন

ডিফল্ট 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 অ্যাট্রিবিউট তৈরি করে ইউআরএল রিডাইরেক্ট নির্দিষ্ট করুন, যেটিতে 'redirect rules' নামে অবজেক্টের একটি অ্যারে থাকবে। প্রতিটি রুলে একটি ইউআরএল প্যাটার্ন নির্দিষ্ট করুন, যা রিকোয়েস্ট ইউআরএল পাথের সাথে মিলে গেলে 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
  } ]
}

"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 প্রতিটি অনুরোধের শুরুতে (ব্রাউজার সেই পাথে কোনো ফাইল বা ফোল্ডার আছে কিনা তা নির্ধারণ করার আগে) সমস্ত URL পাথের সাথে source বা regex ভ্যালুটি তুলনা করে। যদি কোনো মিল খুঁজে পাওয়া যায়, তাহলে Firebase Hosting অরিজিন সার্ভার একটি HTTPS রিডাইরেক্ট রেসপন্স পাঠায়, যা ব্রাউজারকে destination URL-এ একটি নতুন অনুরোধ করতে নির্দেশ দেয়।

রিডাইরেক্টের জন্য ইউআরএল সেগমেন্ট ক্যাপচার করুন

ঐচ্ছিক
কখনও কখনও, আপনার একটি রিডাইরেক্ট রুলের URL প্যাটার্নের ( source বা regex ভ্যালু) নির্দিষ্ট অংশ ক্যাপচার করার এবং তারপর সেই অংশগুলো রুলটির destination পাথে পুনরায় ব্যবহার করার প্রয়োজন হতে পারে।

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

"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 pushState ব্যবহার করে। যখন কোনো ব্রাউজার নির্দিষ্ট source বা regex ইউআরএল প্যাটার্নের সাথে মেলে এমন কোনো ইউআরএল পাথ খোলার চেষ্টা করে, তখন ব্রাউজারটিকে তার পরিবর্তে destination ইউআরএল-এ থাকা ফাইলের কন্টেন্ট দেওয়া হবে।

একটি rewrites অ্যাট্রিবিউট তৈরি করে ইউআরএল রিরাইট নির্দিষ্ট করুন, যেটিতে 'rewrite rules' নামে অবজেক্টের একটি অ্যারে থাকবে। প্রতিটি রুলে একটি ইউআরএল প্যাটার্ন নির্দিষ্ট করুন, যা রিকোয়েস্ট ইউআরএল পাথের সাথে মিলে গেলে Hosting এমনভাবে সাড়া দিতে ট্রিগার করবে যেন সার্ভিসটিকে নির্দিষ্ট ডেস্টিনেশন ইউআরএলটি দেওয়া হয়েছে।

এখানে একটি 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 শুধুমাত্র তখনই একটি রিরাইট রুল প্রয়োগ করে, যখন নির্দিষ্ট source বা regex ইউআরএল প্যাটার্নের সাথে মেলে এমন কোনো ইউআরএল পাথে ফাইল বা ডিরেক্টরি বিদ্যমান থাকে না। যখন কোনো অনুরোধ একটি রিরাইট রুল ট্রিগার করে, তখন ব্রাউজার HTTP রিডাইরেক্টের পরিবর্তে নির্দিষ্ট 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)
    }
  } ]
}

এই রিরাইট রুলটি যোগ করার পর এবং ফায়ারবেসে ( firebase deploy ব্যবহার করে) ডিপ্লয় করার পর, আপনার ফাংশনটি নিম্নলিখিত URL-গুলির মাধ্যমে অ্যাক্সেসযোগ্য হবে:

• আপনার ফায়ারবেস সাবডোমেনগুলি:
  PROJECT_ID .web.app/bigben এবং PROJECT_ID .firebaseapp.com/bigben

• যেকোনো সংযুক্ত কাস্টম ডোমেইন :
  CUSTOM_DOMAIN /bigben

যখন Firebase Hosting কোনো ফাংশনে ট্র্যাফিক ফরওয়ার্ড করে, তখন ফাংশনটি সম্পূর্ণ মূল রিকোয়েস্ট পাথ এবং কোয়েরি স্ট্রিং গ্রহণ করে। উদাহরণস্বরূপ, আপনার Hosting সাইটে /bigben/hello/world?foo=bar একটি রিকোয়েস্ট সম্পূর্ণ পাথ এবং কোয়েরি অক্ষত রেখে ফাংশনে পাঠানো হয়। নিশ্চিত করুন যে আপনার ফাংশন হ্যান্ডলারটি শুধুমাত্র রিরাইটে সংজ্ঞায়িত বেস পাথ নয়, বরং সম্পূর্ণ অ্যাবসোলিউট ইউআরএল (absolute URL) হ্যান্ডেল করার জন্য লেখা হয়েছে।

Hosting ব্যবহার করে ফাংশনে অনুরোধ পুনঃনির্দেশ করার সময়, সমর্থিত HTTP অনুরোধ পদ্ধতিগুলি হলো GET , POST , HEAD , PUT , DELETE , PATCH এবং OPTIONS । REPORT বা PROFIND মতো অন্যান্য পদ্ধতি সমর্থিত নয়।

Cloud Run কন্টেইনারে সরাসরি অনুরোধ

আপনি rewrites ব্যবহার করে একটি Firebase Hosting ইউআরএল থেকে Cloud Run কন্টেইনার অ্যাক্সেস করতে পারেন। নিম্নলিখিত উদাহরণটি 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)
   }
 } ]
}

এই রিরাইট রুলটি যোগ করার পর এবং ফায়ারবেসে ( firebase deploy ব্যবহার করে) ডিপ্লয় করার পর, আপনার কন্টেইনার ইমেজটি নিম্নলিখিত URL-গুলির মাধ্যমে অ্যাক্সেসযোগ্য হবে:

• আপনার ফায়ারবেস সাবডোমেনগুলি:
  PROJECT_ID .web.app/helloworld এবং PROJECT_ID .firebaseapp.com/helloworld

• যেকোনো সংযুক্ত কাস্টম ডোমেইন :
  CUSTOM_DOMAIN /helloworld

Hosting সহ Cloud Run কন্টেইনারে অনুরোধ পুনঃনির্দেশ করার সময়, সমর্থিত HTTP অনুরোধ পদ্ধতিগুলি হল 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 তৈরি করুন

আপনি rewrites ব্যবহার করে কাস্টম ডোমেইন Dynamic Links তৈরি করতে পারেন। 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 কনফিগার করার জন্য নিম্নলিখিত বিষয়গুলো প্রয়োজন:

হেডার কনফিগার করুন

ঐচ্ছিক
হেডার ক্লায়েন্ট এবং সার্ভারকে কোনো অনুরোধ বা প্রতিক্রিয়ার সাথে অতিরিক্ত তথ্য আদান-প্রদান করার সুযোগ দেয়। কিছু নির্দিষ্ট হেডার সেট ব্রাউজার কীভাবে পৃষ্ঠা এবং এর বিষয়বস্তু পরিচালনা করবে, তা প্রভাবিত করতে পারে; যেমন—অ্যাক্সেস কন্ট্রোল, অথেনটিকেশন, ক্যাশিং এবং এনকোডিং।

কাস্টম, ফাইল-নির্দিষ্ট রেসপন্স হেডার নির্দিষ্ট করতে, একটি headers অ্যাট্রিবিউট তৈরি করুন যাতে হেডার অবজেক্টের একটি অ্যারে থাকবে। প্রতিটি অবজেক্টে একটি URL প্যাটার্ন নির্দিষ্ট করুন, যা রিকোয়েস্ট URL পাথের সাথে মিলে গেলে 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": "*"
    } ]
  } ]
}

"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 অ্যাট্রিবিউটে ডেফিনিশনগুলোর একটি অ্যারে থাকে, যেখানে প্রতিটি ডেফিনিশনে অবশ্যই নিচের টেবিলে থাকা ফিল্ডগুলো অন্তর্ভুক্ত থাকতে হবে।

আপনি Hosting বিভাগে Cache-Control সম্পর্কে আরও জানতে পারবেন, যেখানে ডাইনামিক কন্টেন্ট পরিবেশন এবং মাইক্রোসার্ভিস হোস্টিং সম্পর্কে বর্ণনা করা হয়েছে। এছাড়াও আপনি CORS হেডার সম্পর্কেও আরও জানতে পারবেন।

.html এক্সটেনশন নিয়ন্ত্রণ করুন

ঐচ্ছিক
cleanUrls অ্যাট্রিবিউটের মাধ্যমে আপনি নিয়ন্ত্রণ করতে পারেন যে URL-গুলোতে .html এক্সটেনশন যুক্ত হবে কি না।

যখন true , Hosting স্বয়ংক্রিয়ভাবে আপলোড করা ফাইলের URL থেকে .html এক্সটেনশনটি বাদ দিয়ে দেয়। যদি অনুরোধে একটি .html এক্সটেনশন যোগ করা হয়, Hosting একই পাথে একটি 301 রিডাইরেক্ট করে কিন্তু .html এক্সটেনশনটি বাদ দিয়ে দেয়।

cleanUrls অ্যাট্রিবিউট যোগ করে URL-এ .html এর অন্তর্ভুক্তি নিয়ন্ত্রণ করার উপায়টি নিচে দেওয়া হলো:

"hosting": {
  // ...

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

ট্রেলিং স্ল্যাশ নিয়ন্ত্রণ করুন

ঐচ্ছিক
trailingSlash অ্যাট্রিবিউটের মাধ্যমে আপনি নিয়ন্ত্রণ করতে পারেন যে স্ট্যাটিক কন্টেন্টের URL-এর শেষে স্ল্যাশ থাকবে কি না।

• যখন true , Hosting ইউআরএল-এর শেষে একটি স্ল্যাশ যোগ করে রিডাইরেক্ট করে।
• false হলে, Hosting URL-এর শেষের স্ল্যাশটি মুছে ফেলার জন্য সেটিকে রিডাইরেক্ট করে।
• অনির্দিষ্ট থাকলে, Hosting শুধুমাত্র ডিরেক্টরি ইনডেক্স ফাইলগুলির শেষে স্ল্যাশ ব্যবহার করে (উদাহরণস্বরূপ, about/index.html )।

trailingSlash অ্যাট্রিবিউট যোগ করে কীভাবে শেষের স্ল্যাশ নিয়ন্ত্রণ করা যায়, তা এখানে দেওয়া হলো:

"hosting": {
  // ...

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

trailingSlash অ্যাট্রিবিউটটি Cloud Functions বা Cloud Run দ্বারা পরিবেশিত ডাইনামিক কন্টেন্টের রিরাইটকে প্রভাবিত করে না।

গ্লোব প্যাটার্ন মেলানো

Firebase Hosting কনফিগারেশন অপশনগুলোতে extglob সহ গ্লোব প্যাটার্ন ম্যাচিং নোটেশন ব্যাপকভাবে ব্যবহার করা হয়, ঠিক যেভাবে গিট gitignore রুল এবং বাওয়ার 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 ফাইলে অন্যান্য ফায়ারবেস পরিষেবাগুলির কনফিগারেশনও থাকতে পারে।

{
  "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",

  }
}