HTTP ক্যাশের মাধ্যমে অপ্রয়োজনীয় নেটওয়ার্ক অনুরোধ আটকানো

Ilya Grigorik
Jeff Posnick

নেটওয়ার্কের মাধ্যমে রিসোর্স ফেচ করা স্লো এবং ব্যয়বহুল:

  • বড় উত্তরের জন্য ব্রাউজার এবং সার্ভারের মধ্যে অনেক রাউন্ডট্রিপ প্রয়োজন।
  • আপনার পৃষ্ঠার সব গুরুত্বপূর্ণ রিসোর্স সম্পূর্ণভাবে ডাউনলোড না হওয়া পর্যন্ত পৃষ্ঠা লোড হবে না।
  • কোনও ব্যক্তি যদি সীমিত মোবাইল ডেটা প্ল্যান ব্যবহার করে আপনার সাইট অ্যাক্সেস করেন, তাহলে প্রতিটি অপ্রয়োজনীয় নেটওয়ার্ক রিকোয়েস্টের জন্য তার টাকা নষ্ট হয়।

আপনি কীভাবে অপ্রয়োজনীয় নেটওয়ার্ক অনুরোধ এড়াতে পারেন? ব্রাউজারের HTTP ক্যাশে হল আপনার প্রথম লাইন অফ ডিফেন্স। এটি সবচেয়ে শক্তিশালী বা নমনীয় পদ্ধতি নাও হতে পারে এবং ক্যাশে করা উত্তরের লাইফটাইমের উপর আপনার সীমিত কন্ট্রোল থাকে, তবে এটি কার্যকর, সব ব্রাউজারে কাজ করে এবং এর জন্য বেশি পরিশ্রম করতে হয় না।

এই নির্দেশিকা আপনাকে কার্যকর HTTP ক্যাশিং প্রয়োগের প্রাথমিক বিষয়গুলি দেখায়।

মানানসই ব্রাউজার

HTTP ক্যাশে নামে আসলে কোনও একটি API নেই। এটি হল ওয়েব প্ল্যাটফর্ম API-এর সংগ্রহের সাধারণ নাম। এইসব API সব ব্রাউজারে কাজ করে:

Cache-Control

Browser Support

  • Chrome: 1.
  • Edge: 12.
  • Firefox: 1.
  • Safari: 1.

Source

ETag

Browser Support

  • Chrome: 1.
  • Edge: 12.
  • Firefox: 1.
  • Safari: 1.

Source

Last-Modified

Browser Support

  • Chrome: 1.
  • Edge: 12.
  • Firefox: 1.
  • Safari: 1.

Source

HTTP ক্যাশে কীভাবে কাজ করে

ব্রাউজার থেকে করা সব HTTP অনুরোধ প্রথমে ব্রাউজার ক্যাশেতে পাঠানো হয় যাতে অনুরোধ পূরণ করার জন্য কোনও সঠিক ক্যাশে করা উত্তর আছে কিনা তা চেক করা যায়। যদি কোনও মিল থাকে, তাহলে ক্যাশে থেকে উত্তরটি পড়া হয়, যা নেটওয়ার্ক লেটেন্সি এবং ট্রান্সফারের জন্য ডেটা খরচ উভয়ই কমিয়ে দেয়।

HTTP ক্যাশের আচরণ অনুরোধ হেডার এবং প্রতিক্রিয়া হেডারের সংমিশ্রণ দ্বারা নিয়ন্ত্রিত হয়। আদর্শ পরিস্থিতিতে, আপনার ওয়েব অ্যাপ্লিকেশনের কোড (যা রিকোয়েস্ট হেডার নির্ধারণ করবে) এবং আপনার ওয়েব সার্ভারের কনফিগারেশন (যা রেসপন্স হেডার নির্ধারণ করবে) দুটির উপরেই আপনার নিয়ন্ত্রণ থাকবে।

আরও গভীর ধারণাগত ওভারভিউয়ের জন্য MDN-এর HTTP ক্যাশিং নিবন্ধটি দেখুন।

রিকোয়েস্ট হেডার: ডিফল্ট সেটিংস ব্যবহার করুন (সাধারণত)

আপনার ওয়েব অ্যাপের আউটগোয়িং অনুরোধে বেশ কিছু গুরুত্বপূর্ণ হেডার অন্তর্ভুক্ত করা উচিত, তবে ব্রাউজার অনুরোধ করার সময় প্রায় সবসময় আপনার হয়ে সেগুলি সেট করার দায়িত্ব নেয়। HTTP ক্যাশেতে বর্তমান ভ্যালু সম্পর্কে ব্রাউজারের ধারণার উপর ভিত্তি করে If-None-Match এবং If-Modified-Since-এর মতো রিকোয়েস্ট হেডার দেখা যায় যা ফ্রেশনেস চেক করার উপর প্রভাব ফেলে।

এটি একটি ভালো খবর—এর অর্থ হল, আপনি নিজের HTML-এ <img src="my-image.png">-এর মতো ট্যাগ অন্তর্ভুক্ত করা চালিয়ে যেতে পারবেন এবং ব্রাউজার অটোমেটিক আপনার জন্য HTTP ক্যাশিংয়ের যত্ন নেয়, কোনও অতিরিক্ত প্রচেষ্টা ছাড়াই।

রেসপন্স হেডার: আপনার ওয়েব সার্ভার কনফিগার করুন

HTTP ক্যাশিং সেট-আপের সবচেয়ে গুরুত্বপূর্ণ অংশ হল হেডার যা আপনার ওয়েব সার্ভার প্রতিটি আউটগোয়িং রেসপন্সে যোগ করে। নিম্নলিখিত হেডারগুলি কার্যকর ক্যাশিং আচরণে প্রভাব ফেলে:

  • Cache-Control. সার্ভার একটি Cache-Control নির্দেশিকা পাঠাতে পারে যাতে উল্লেখ করা থাকে যে কীভাবে এবং কতক্ষণ ব্রাউজার এবং অন্যান্য ইন্টারমিডিয়েট ক্যাশে প্রতিটি রেসপন্স ক্যাশে করবে।
  • ETag. ব্রাউজার যখন মেয়াদ শেষ হয়ে যাওয়া ক্যাশে করা উত্তর খুঁজে পায়, তখন ফাইলটি পরিবর্তন হয়েছে কিনা তা চেক করার জন্য এটি সার্ভারে একটি ছোট টোকেন (সাধারণত ফাইলের কন্টেন্টের হ্যাশ) পাঠাতে পারে। সার্ভার একই টোকেন রিটার্ন করলে, ফাইলটি একই থাকে এবং এটি আবার ডাউনলোড করার প্রয়োজন হয় না।
  • Last-Modified. এই হেডার ETag-এর মতো একই উদ্দেশ্যে কাজ করে, তবে কোনও রিসোর্স পরিবর্তিত হয়েছে কিনা তা নির্ধারণ করতে সময়-ভিত্তিক স্ট্র্যাটেজি ব্যবহার করে, যা ETag-এর কন্টেন্ট-ভিত্তিক স্ট্র্যাটেজির বিপরীত।

কিছু ওয়েব সার্ভারে ডিফল্ট হিসেবে এইসব হেডার সেট করার জন্য বিল্ট-ইন সাপোর্ট থাকে, আবার কিছু সার্ভারে আপনি স্পষ্টভাবে কনফিগার না করলে হেডার সম্পূর্ণভাবে বাদ দেওয়া হয়। আপনি কোন ওয়েব সার্ভার ব্যবহার করছেন তার উপর নির্ভর করে হেডার কীভাবে কনফিগার করবেন তার নির্দিষ্ট বিবরণ আলাদা আলাদা হয় এবং সবচেয়ে সঠিক বিবরণ পেতে আপনার সার্ভারের ডকুমেন্টেশন দেখুন।

আপনার সার্চ করার সময় বাঁচাতে, এখানে কয়েকটি জনপ্রিয় ওয়েব সার্ভার কনফিগার করার নির্দেশাবলী দেওয়া হল:

Cache-Control রেসপন্স হেডার বাদ দিলে HTTP ক্যাশিং বন্ধ হয় না! পরিবর্তে, ব্রাউজার কার্যকরভাবে অনুমান করে যে কোন ধরনের ক্যাশিং আচরণ প্রদত্ত ধরনের কন্টেন্টের জন্য সবচেয়ে বেশি অর্থপূর্ণ। আপনি হয়ত এর থেকে আরও বেশি নিয়ন্ত্রণ চান, তাই আপনার রেসপন্স হেডার কনফিগার করতে সময় নিন।

কোন রেসপন্স হেডারের ভ্যালু আপনার ব্যবহার করা উচিত?

আপনার ওয়েব সার্ভারের রেসপন্স হেডার কনফিগার করার সময় দুটি গুরুত্বপূর্ণ পরিস্থিতি আপনাকে কভার করতে হবে।

ভার্সন করা URL-এর জন্য দীর্ঘস্থায়ী ক্যাশিং

ভার্সন করা URL কীভাবে আপনার ক্যাশিং স্ট্র্যাটেজিতে সাহায্য করতে পারে
ভার্সন করা URL ব্যবহার করা একটি ভালো অভ্যাস কারণ এটি ক্যাশে করা উত্তর বাতিল করা সহজ করে তোলে।

ধরুন, আপনার সার্ভার ব্রাউজারকে ১ বছরের (Cache-Control: max-age=31536000) জন্য CSS ফাইল ক্যাশে করার নির্দেশ দেয়, কিন্তু আপনার ডিজাইনার এইমাত্র একটি জরুরি আপডেট করেছেন যা আপনাকে অবিলম্বে প্রয়োগ করতে হবে। ফাইলের "পুরনো" ক্যাশে করা কপি আপডেট করার জন্য আপনি কীভাবে ব্রাউজারকে বিজ্ঞপ্তি পাঠান? আপনি পারবেন না, অন্তত রিসোর্সের URL পরিবর্তন না করে তো নয়ই।

ব্রাউজার রেসপন্স ক্যাশে করার পরে, ক্যাশে করা ভার্সনটি ব্যবহার করা হয় যতক্ষণ না এটি আর ফ্রেশ থাকে, যেমনটি max-age বা expires দ্বারা নির্ধারিত হয়, অথবা অন্য কোনও কারণে ক্যাশে থেকে মুছে না ফেলা পর্যন্ত—যেমন, ব্যবহারকারী তার ব্রাউজার ক্যাশে মুছে ফেললে। এর ফলে, পৃষ্ঠা তৈরি করার সময় বিভিন্ন ব্যবহারকারী ফাইলের বিভিন্ন ভার্সন ব্যবহার করতে পারেন: যে ব্যবহারকারী সবেমাত্র রিসোর্সটি পেয়েছেন তিনি নতুন ভার্সন ব্যবহার করেন, অন্যদিকে যে ব্যবহারকারী আগের (কিন্তু এখনও বৈধ) কপি ক্যাশে করেছেন তিনি এর উত্তরের পুরনো ভার্সন ব্যবহার করেন।

আপনি কীভাবে দুটিরই সেরা সুবিধা পাবেন: ক্লায়েন্ট-সাইড ক্যাশিং এবং দ্রুত আপডেট? আপনি রিসোর্সের URL পরিবর্তন করেন এবং কন্টেন্ট পরিবর্তন হলেই ব্যবহারকারীকে নতুন উত্তর ডাউনলোড করতে বাধ্য করেন। সাধারণত, আপনি ফাইলের ফিঙ্গারপ্রিন্ট বা ভার্সন নম্বর ফাইলের নামে এম্বেড করে এটি করেন—যেমন, style.x234dff.css।

"ফিঙ্গারপ্রিন্ট" বা ভার্সন সংক্রান্ত তথ্য আছে এবং যার কন্টেন্ট কখনও পরিবর্তন করা হবে না এমন URL-এর অনুরোধের উত্তর দেওয়ার সময়, আপনার উত্তরে Cache-Control: max-age=31536000 যোগ করুন।

এই ভ্যালু সেট করলে ব্রাউজার বুঝতে পারে যে আগামী এক বছরের (৩১,৫৩৬,০০০ সেকেন্ড; সর্বাধিক অনুমোদিত ভ্যালু) মধ্যে যেকোনও সময় একই URL লোড করার প্রয়োজন হলে, এটি আপনার ওয়েব সার্ভারে নেটওয়ার্ক অনুরোধ না পাঠিয়েই HTTP ক্যাশে থেকে সরাসরি ভ্যালু ব্যবহার করতে পারবে। খুব ভালো—আপনি নেটওয়ার্ক এড়িয়ে যাওয়ার ফলে অবিলম্বে নির্ভরযোগ্যতা ও স্পিড পেয়ে গেছেন!

webpack-এর মতো বিল্ড টুল আপনার অ্যাসেট URL-এ হ্যাশ ফিঙ্গারপ্রিন্ট অ্যাসাইন করার প্রসেস অটোমেট করতে পারে।

ভার্সন নেই এমন URL-এর জন্য সার্ভার রিভ্যালিডেশন

আপনি যেসব URL লোড করেন তার সবকটির ভার্সন থাকে না। আপনার ওয়েব অ্যাপ ডিপ্লয় করার আগে হয়ত আপনি বিল্ড স্টেপ যোগ করতে পারছেন না, তাই আপনার অ্যাসেট URL-এ হ্যাশ যোগ করতে পারছেন না। এবং প্রতিটি ওয়েব অ্যাপ্লিকেশনের HTML ফাইল প্রয়োজন—সেইসব ফাইলে (প্রায়!) কখনই ভার্সন সংক্রান্ত তথ্য থাকবে না, কারণ ভিজিট করার জন্য URL যে https://example.com/index.34def12.html তা মনে রাখতে হলে কেউ আপনার ওয়েব অ্যাপ ব্যবহার করার কথা ভাববে না। তাহলে, এইসব URL-এর জন্য আপনি কী করতে পারেন?

এটি এমন একটি পরিস্থিতি যেখানে আপনাকে পরাজয় স্বীকার করতে হবে। নেটওয়ার্ক সম্পূর্ণভাবে এড়িয়ে যাওয়ার জন্য শুধু HTTP ক্যাশিং যথেষ্ট নয়। (চিন্তা করবেন না—আপনি শীঘ্রই সার্ভিস ওয়ার্কার সম্পর্কে জানতে পারবেন, যা আমাদের প্রয়োজনীয় সহায়তা প্রদান করবে যাতে আমরা এই যুদ্ধে আপনার পক্ষে জয়লাভ করতে পারি।) তবে, নেটওয়ার্ক রিকোয়েস্ট যাতে যত দ্রুত ও দক্ষতার সাথে সম্ভব করা যায় তা নিশ্চিত করতে আপনি কয়েকটি ধাপ অনুসরণ করতে পারেন।

নিম্নলিখিত Cache-Control ভ্যালু আপনাকে ভার্সনহীন URL কোথায় এবং কীভাবে ক্যাশে করা হয় তা ফাইন-টিউন করতে সাহায্য করতে পারে:

  • no-cache. এটি ব্রাউজারকে নির্দেশ দেয় যে URL-এর ক্যাশে করা ভার্সন ব্যবহার করার আগে প্রতিবার সার্ভারের সাথে এটি আবার যাচাই করতে হবে।
  • no-store. এটি ব্রাউজার এবং অন্যান্য ইন্টারমিডিয়েট ক্যাশকে (যেমন CDN) ফাইলের কোনও ভার্সন কখনও স্টোর না করার নির্দেশ দেয়।
  • private. ব্রাউজার ফাইল ক্যাশে করতে পারে কিন্তু ইন্টারমিডিয়েট ক্যাশে তা পারে না।
  • public. উত্তর যেকোনও ক্যাশে স্টোর করা যেতে পারে।

কোন Cache-Control ভ্যালু ব্যবহার করা হবে তা নির্ধারণ করার প্রক্রিয়াটি কল্পনা করতে পরিশিষ্ট: Cache-Control ফ্লোচার্ট দেখুন। Cache-Control-এ কমা দিয়ে আলাদা করা নির্দেশাবলীর তালিকাও ব্যবহার করা যেতে পারে। পরিশিষ্ট: Cache-Controlটি উদাহরণ দেখুন।

এছাড়াও, ETag অথবা Last-Modified সেট করলে সাহায্য হতে পারে। রেসপন্স হেডারে যেমন উল্লেখ করা হয়েছে, ETag এবং Last-Modified দুটিই একই উদ্দেশ্যে কাজ করে: মেয়াদ শেষ হয়ে যাওয়া ক্যাশে করা ফাইল ব্রাউজারকে আবার ডাউনলোড করতে হবে কিনা তা নির্ধারণ করা। আমরা ETag ব্যবহার করার সাজেশন দিই কারণ এটি আরও নির্ভুল।

ETag-এর উদাহরণ

ধরে নিন যে প্রাথমিক ফেচ করার পর থেকে ১২০ সেকেন্ড কেটে গেছে এবং ব্রাউজার একই রিসোর্সের জন্য একটি নতুন অনুরোধ শুরু করেছে। প্রথমে, ব্রাউজার HTTP ক্যাশে চেক করে এবং আগের উত্তর খুঁজে পায়। দুর্ভাগ্যবশত, ব্রাউজার আগের উত্তর ব্যবহার করতে পারছে না কারণ উত্তরটির মেয়াদ এখন শেষ হয়ে গেছে। এই মুহূর্তে, ব্রাউজার নতুন অনুরোধ পাঠাতে এবং নতুন সম্পূর্ণ উত্তর ফেচ করতে পারে। তবে, এটি অদক্ষ কারণ রিসোর্স পরিবর্তন না হলে, ক্যাশে আগে থেকেই থাকা একই তথ্য ডাউনলোড করার কোনও কারণ নেই!

ETag হেডারে উল্লেখ করা যাচাইকরণের টোকেন এই সমস্যার সমাধান করার জন্যই তৈরি করা হয়েছে। সার্ভার একটি আরবিট্রারি টোকেন তৈরি করে এবং ফেরত দেয়, যা সাধারণত ফাইলের কন্টেন্টের হ্যাশ বা অন্য কোনও ফিঙ্গারপ্রিন্ট হয়। ফিঙ্গারপ্রিন্ট কীভাবে তৈরি হয় তা ব্রাউজারকে জানতে হয় না; পরবর্তী অনুরোধে এটি শুধু সার্ভারে পাঠাতে হয়। ফিঙ্গারপ্রিন্ট একই থাকলে, রিসোর্স পরিবর্তন হয়নি এবং ব্রাউজার ডাউনলোড করা এড়িয়ে যেতে পারে।

ETag বা Last-Modified সেট করলে, অনুরোধের হেডার-এ উল্লেখ করা If-Modified-Since বা If-None-Match অনুরোধের হেডার ট্রিগার করার মাধ্যমে, আবার যাচাই করার অনুরোধ অনেক বেশি কার্যকর হয়।

সঠিকভাবে কনফিগার করা ওয়েব সার্ভার যখন এইসব ইনকামিং রিকোয়েস্ট হেডার দেখে, তখন এটি কনফার্ম করতে পারে যে ব্রাউজারের HTTP ক্যাশেতে আগে থেকেই থাকা রিসোর্সের ভার্সন ওয়েব সার্ভারের লেটেস্ট ভার্সনের সাথে ম্যাচ করছে কিনা। যদি মিলে যায়, তাহলে সার্ভার 304 Not Modified HTTP রেসপন্স দিয়ে উত্তর দিতে পারে, যার অর্থ হল "আপনার কাছে যা আছে তা ব্যবহার করতে থাকুন!" এই ধরনের উত্তর পাঠানোর সময় খুব কম ডেটা ট্রান্সফার করতে হয়, তাই অনুরোধ করা আসল রিসোর্সের কপি পাঠানোর চেয়ে এটি অনেক দ্রুত হয়।

কোনও ক্লায়েন্ট রিসোর্সের অনুরোধ করছে এবং সার্ভার ৩০৪ হেডার সহ উত্তর দিচ্ছে, তার একটি ভিজ্যুয়ালাইজেশন।
ব্রাউজার সার্ভার থেকে /file-এর অনুরোধ করে এবং If-None-Match হেডার অন্তর্ভুক্ত করে যাতে সার্ভারকে নির্দেশ দেওয়া যায় যে সার্ভারে থাকা ফাইলের ETag ব্রাউজারের If-None-Match ভ্যালুর সাথে ম্যাচ না করলে তবেই যেন সম্পূর্ণ ফাইলটি ফেরত পাঠানো হয়। এই ক্ষেত্রে, ২টি ভ্যালু ম্যাচ করেছে, তাই সার্ভার 304 Not Modified রেসপন্স ফিরিয়ে দেয় এবং ফাইলটি কতক্ষণ ক্যাশে করা উচিত (Cache-Control: max-age=120) সেই সংক্রান্ত নির্দেশাবলী দেয়।

সারাংশ

HTTP ক্যাশে হল লোড পারফর্ম্যান্স উন্নত করার একটি কার্যকর উপায় কারণ এটি অপ্রয়োজনীয় নেটওয়ার্ক অনুরোধ কমায়। এটি সব ব্রাউজারে কাজ করে এবং সেট-আপ করতে বেশি সময় লাগে না।

নিম্নলিখিত Cache-Control কনফিগারেশনগুলি একটি ভাল শুরু:

  • রিসোর্সের জন্য Cache-Control: no-cache যা প্রতিবার ব্যবহারের আগে সার্ভারের সাথে আবার যাচাই করা উচিত।
  • রিসোর্সের জন্য Cache-Control: no-store যা কখনই ক্যাশে করা উচিত নয়।
  • ভার্সন করা রিসোর্সের জন্য Cache-Control: max-age=31536000।

এবং ETag বা Last-Modified হেডার আপনাকে মেয়াদ শেষ হয়ে যাওয়া ক্যাশে রিসোর্স আরও দক্ষতার সাথে আবার যাচাই করতে সাহায্য করতে পারে।

আরও জানুন

আপনি যদি Cache-Control হেডার ব্যবহারের প্রাথমিক বিষয়গুলি ছাড়াও আরও কিছু জানতে চান, তাহলে জেক আর্চিবল্ডের ক্যাশিং সংক্রান্ত পেশাদার পদ্ধতি এবং max-age gotchas নির্দেশিকা দেখুন।

ফিরে আসা দর্শকদের জন্য আপনার ক্যাশে ব্যবহার কীভাবে অপ্টিমাইজ করবেন সেই বিষয়ে নির্দেশিকার জন্য আপনার ক্যাশে ভালোবাসুন দেখুন।

পরিশিষ্ট: আরও পরামর্শ

আপনার কাছে আরও সময় থাকলে, HTTP ক্যাশের ব্যবহার অপ্টিমাইজ করার আরও উপায় এখানে দেওয়া হল:

  • একই URL ব্যবহার করুন। আপনি যদি বিভিন্ন URL-এ একই কন্টেন্ট পরিবেশন করেন, তাহলে সেই কন্টেন্ট একাধিকবার ফেচ এবং স্টোর করা হবে।
  • গ্রাহক সংখ্যা কমে যাওয়া আটকান। কোনও রিসোর্সের অংশ (যেমন, CSS ফাইল) ঘন ঘন আপডেট হলে, কিন্তু ফাইলের বাকি অংশ (যেমন, লাইব্রেরি কোড) আপডেট না হলে, ঘন ঘন আপডেট হওয়া কোডটি আলাদা ফাইলে ভাগ করে নেওয়ার কথা বিবেচনা করুন। ঘন ঘন আপডেট হওয়া কোডের জন্য স্বল্প মেয়াদী ক্যাশিং স্ট্র্যাটেজি এবং ঘন ঘন পরিবর্তন না হওয়া কোডের জন্য দীর্ঘ মেয়াদী ক্যাশিং স্ট্র্যাটেজি ব্যবহার করুন।
  • আপনার Cache-Control নীতিতে কিছুটা পুরনো ডেটা গ্রহণযোগ্য হলে, নতুন stale-while-revalidate নির্দেশিকা দেখুন।

অ্যাপেনডিক্স: Cache-Control ফ্লোচার্ট

ফ্লোচার্ট
আপনার Cache-Control হেডার সেট করার জন্য সিদ্ধান্ত নেওয়ার প্রসেস।

পরিশিষ্ট: Cache-Controlটি উদাহরণ

Cache-Controlটি ব্যাখ্যা
max-age=86400 ব্রাউজার এবং মধ্যবর্তী ক্যাশে সর্বাধিক ১ দিন (৬০ সেকেন্ড x ৬০ মিনিট x ২৪ ঘণ্টা) পর্যন্ত উত্তর ক্যাশে করা যেতে পারে।
private, max-age=600 ব্রাউজার (কিন্তু ইন্টারমিডিয়ারি ক্যাশে নয়) সর্বাধিক ১০ মিনিট (৬০ সেকেন্ড x ১০ মিনিট) পর্যন্ত রেসপন্স ক্যাশে করতে পারে।
public, max-age=31536000 যেকোনও ক্যাশে ১ বছরের জন্য উত্তর স্টোর করতে পারে।
no-store রেসপন্স ক্যাশে করা যাবে না এবং প্রতিটি অনুরোধের জন্য সম্পূর্ণ রেসপন্স ফেচ করতে হবে।