আপনি Apigee Edge ডকুমেন্টেশন দেখছেন।
Apigee X ডকুমেন্টেশন দেখুন। তথ্য
আপনি ResponseCache নীতি ব্যবহার করার সময় Edge কীভাবে HTTP/1.1 ক্যাশিং হেডার ম্যানেজ করে তা এই বিষয়ে বর্ণনা করা হয়েছে। Apigee Edge বর্তমানে HTTP/1.1 ক্যাশিং হেডার এবং ডাইরেক্টিভের একটি সাবসেট (এই টপিকে কাজ করে না এমন ফিচার তালিকাভুক্ত করা আছে) গ্রহণ করে যা ব্যাকএন্ড টার্গেট (অরিজিন) সার্ভার থেকে পাওয়া যায়।
এছাড়াও, নির্দিষ্ট কিছু হেডার থাকলে, Edge সেগুলির নির্দেশিকা অনুযায়ী ব্যবস্থা নেয়। কিছু ক্ষেত্রে,
এইসব HTTP/1.1 ক্যাশে হেডার, ResponseCache নীতিতে নির্দিষ্ট করা যেকোনও আচরণকে ওভাররাইড করে।
যেমন, কোনও ব্যাকএন্ড সার্ভার থেকে Cache-Control হেডার রিটার্ন করা হলে, আপনি
হেডারের s-maxage ডাইরেক্টিভ হয়ত নীতির
অন্যান্য মেয়াদ শেষ হওয়ার সেটিংসকে ওভাররাইড করতে পারবেন।
| শিরোনাম | সহায়তা |
|---|---|
| ক্যাশে-কন্ট্রোল | ব্যাকএন্ড অরিজিন সার্ভার থেকে পাওয়া রেসপন্সে কাজ করে, তবে ক্লায়েন্টের অনুরোধে কাজ করে না। Edge-এ নির্দেশাবলীর একটি সাবসেট কাজ করে। |
| মেয়াদ শেষ হওয়ার তারিখ | কাজ করে। ওভাররাইড করা যেতে পারে। |
| এনটিটি ট্যাগ (ETags) | If-Match এবং If-None-Match-এর জন্য নির্দিষ্ট আচরণ। |
| If-Modified-Since | GET অনুরোধে, সঠিক ক্যাশে এন্ট্রি থাকলেও, হেডারটি অরিজিন সার্ভারে পাস করা হয়। |
| Accept-Encoding | ইনকামিং হেডার অনুযায়ী Edge কম্প্রেস করা বা না করা উত্তর পাঠায়। |
ক্যাশে কন্ট্রোল
Apigee Edge শুধুমাত্র ব্যাকএন্ড অরিজিন সার্ভার থেকে পাওয়া রেসপন্সে Cache-Control হেডার কাজ করে (HTTP/1.1 স্পেসিফিকেশন ক্লায়েন্ট অনুরোধ ও অরিজিন সার্ভার রেসপন্স, দু'টিতেই Cache-Control হেডার কাজ করে
) অরিজিন সার্ভারে Apigee Edge API প্রক্সিতে সংজ্ঞায়িত টার্গেট এন্ডপয়েন্ট
এবং TargetServer API কল ব্যবহার করে তৈরি করা এন্ডপয়েন্ট, দু'টিই অন্তর্ভুক্ত থাকতে পারে।
Cache-Control সংক্রান্ত সহায়তা সম্পর্কিত সীমাবদ্ধতা
Apigee Edge, HTTP/1.1 স্পেসিফিকেশনে সংজ্ঞায়িত Cache-Control রেসপন্স হেডার ক্ষমতার একটি সাবসেট
সমর্থন করে। নিম্নলিখিত বিষয়গুলি মনে রাখবেন:
- Apigee Edge ইনবাউন্ড
ক্লায়েন্ট অনুরোধের সাথে আসা
Cache-Controlহেডারকে সাপোর্ট করে না। - Apigee Edge শুধুমাত্র পাবলিক ক্যাশের ধারণা সমর্থন করে। (HTTP স্পেসিফিকেশন অনুযায়ী,
Cache-Controlসর্বজনীন (শেয়ার করা) বা ব্যক্তিগত (একক ব্যবহারকারী) হতে পারে।) - Apigee Edge-এ HTTP/1.1 স্পেসিফিকেশনের মধ্যে থাকা
Cache-Controlরেসপন্স ডাইরেক্টিভের শুধুমাত্র একটি সাবসেট কাজ করে। বিস্তারিত জানতে Cache-Control রেসপন্স হেডার ডাইরেক্টিভের জন্য সহায়তা দেখুন।
Cache-Control রেসপন্স হেডার ডাইরেক্টিভের জন্য সহায়তা
Apigee, অরিজিন সার্ভার থেকে পাওয়া রেসপন্সে HTTP/1.1 স্পেসিফিকেশন থেকে ডাইরেক্টিভের একটি সাবসেট কাজ করে। নিচের সারণীতে HTTP Cache-Control response header নির্দেশাবলীর জন্য Apigee Edge-এর সহায়তা বর্ণনা করা হয়েছে।
এখানে তালিকাভুক্ত নির্দেশাবলী সম্পর্কে আরও বিস্তারিত তথ্য পেতে, HTTP/1.1 স্পেসিফিকেশনে Cache-Control দেখুন।
| ক্যাশে-কন্ট্রোল ডাইরেক্টিভ | Apigee Edge কীভাবে ডাইরেক্টিভ প্রসেস করে |
cache-extension |
কাজ করে না। |
max-age |
আপনার ResponseCache নীতি এই ডাইরেক্টিভ |
must-revalidate |
কাজ করে না। Apigee Edge-এ সবকটি ক্যাশে এন্ট্রি মেয়াদ শেষ হয়ে যাওয়ার সাথে সাথেই মুছে দেওয়া হয়। |
no-cache |
Edge অরিজিন রেসপন্স ক্যাশে করে, কিন্তু পরবর্তীকালে ক্লায়েন্টের কোনও অনুরোধ পূরণ করার জন্য ব্যবহার করার আগে অরিজিন সার্ভারের সাথে এটি আবার যাচাই করিয়ে নিতে হবে। এই নিয়মের মাধ্যমে অরিজিন ৩০৪ পরিবর্তিত নয় উত্তর রিটার্ন করতে পারে, এর মাধ্যমে এটি বোঝানো হয় যে উত্তরটি ক্যাশে থেকে রিটার্ন করা উচিত, এর ফলে সম্পূর্ণ উত্তর রিটার্ন করার জন্য প্রয়োজনীয় প্রসেসিং সেভ করা যায়। অরিজিন সার্ভার সম্পূর্ণ উত্তর পাঠালে, এটি আগে থেকে থাকা ক্যাশে এন্ট্রিকে সরিয়ে দেয়। এই নির্দেশাবলী সহ নির্দিষ্ট করা যেকোনও ফিল্ডের নাম উপেক্ষা করা হয়। |
no-store |
কাজ করে না। |
no-transform |
কাজ করে না। |
private |
কাজ করে না। এই নির্দেশিকা পেলে, অরিজিন রেসপন্স ক্যাশে করা হয় না। যেকোনও ফিল্ডের নাম উপেক্ষা করা হয়। |
proxy-revalidate |
কাজ করে না। Apigee Edge-এর মাধ্যমে সবকটি ক্যাশে এন্ট্রি মুছে দেওয়া হয়, সেগুলি এক্সপায়ার হয়ে গেলেই এই কাজটি করা হয়। |
public |
অন্যান্য ডাইরেক্টিভ অন্য কিছু নির্দেশ করলেও, Edge অরিজিন রেসপন্স ক্যাশে করে। HTTP/1.1 স্পেসিফিকেশন অনুযায়ী, এই নিয়মের একমাত্র ব্যতিক্রম হল, যদি উত্তরে কোনও অনুমোদন হেডার থাকে। |
s-maxage |
আপনার ResponseCache নীতি এই ডাইরেক্টিভটি |
মেয়াদ শেষ হওয়ার তারিখ
ResponseCache নীতিতে UseResponseCacheHeaders ফ্ল্যাগটি
true হিসেবে সেট করা থাকলে, Edge কোনও ক্যাশে করা এন্ট্রির টাইম টু লিভ
(TTL) নির্ধারণ করতে Expires হেডার ব্যবহার করতে পারে। এই হেডার একটি তারিখ/সময় নির্দিষ্ট করে যার পরে কোনও উত্তরের ক্যাশে এন্ট্রি
পুরনো হয়ে গেছে বলে বিবেচনা করা হয়। এই হেডার সার্ভারকে সিগন্যাল দিতে দেয় যে কখন টাইম স্ট্যাম্পের
উপর ভিত্তি করে ক্যাশে করা ভ্যালু রিটার্ন করা যাবে।
Expires হেডারের জন্য গ্রহণযোগ্য তারিখ ফর্ম্যাট HTTP/1.1
স্পেসিফিকেশনে বর্ণনা করা আছে। যেমন:
মেয়াদ শেষ হওয়ার তারিখ: বৃহস্পতিবার, ০১ ডিসেম্বর ১৯৯৪ ১৬:০০:০০ GMT
HTTP তারিখ/সময় ফর্ম্যাট সম্পর্কে বিস্তারিত তথ্য পেতে, HTTP/1.1 স্পেসিফিকেশনে তারিখ/সময় ফর্ম্যাট দেখুন।
Expires হেডার সম্পর্কে আরও জানতে, HTTP/1.1 স্পেসিফিকেশনে
হেডার ফিল্ডের সংজ্ঞা
দেখুন।
ETag
কোনও এন্টিটি ট্যাগ (ETag) হল অনুরোধ করা রিসোর্সের সাথে যুক্ত একটি শনাক্তকারী। ETag ব্যবহার করে, কোনও অনুরোধ করা রিসোর্স এবং সংশ্লিষ্ট ক্যাশে করা রিসোর্স ম্যাচ করছে কিনা তা সার্ভার নির্ধারণ করতে পারে। যেমন, সার্ভার যদি দেখে যে বর্তমানে ক্যাশে করা ডেটা, সেটির সাথে মিলছে না, তাহলে সেটি আবার ক্যাশে করতে পারে। ETags মিলে গেলে এটি ক্যাশে করা রিসোর্স রিটার্ন করতে পারে।
টার্গেট এন্ডপয়েন্ট ETag সহ Edge-এ উত্তর পাঠালে, Edge উত্তর সহ ETag ক্যাশে করে।
আপনি HTTP/1.1 স্পেসিফিকেশনে প্রোটোকল প্যারামিটার থেকে এন্টিটি ট্যাগ সম্পর্কে আরও জানতে পারবেন।
If-Match
If-Match অনুরোধ হেডার সহ, কোনও ক্যাশে করা এন্টিটি তখনই বর্তমান থাকে যদি হেডার
এর ETag ক্যাশে করা ETag-এর সাথে ম্যাচ করে। GET ছাড়া অন্য কোনও অনুরোধে If-Match
হেডার উল্লেখ করা থাকলে, তা অরিজিন সার্ভারে পাঠানো হয়। এর ফলে অরিজিন ক্যাশিংয়ের সুবিধাগুলি অনুরোধ প্রসেস করার
সুযোগ পায়।
HTTP/1.1 স্পেসিফিকেশন থেকে If-Match in
হেডার ফিল্ডের সংজ্ঞা
সম্পর্কে আরও জানতে পারবেন।
Edge যদি কোনও ক্লায়েন্টের থেকে ইনবাউন্ড GET অনুরোধ পায় যার মধ্যে If-Match
হেডার থাকে:
| যদি | তারপর |
|---|---|
If-Match হেডারে এক বা একাধিক ETag উল্লেখ করা থাকে |
|
If-Match হেডারে "*" উল্লেখ করা আছে |
অনুরোধটি অরিজিন সার্ভারে পাঠানো হয় যাতে কোনও অরিজিন ক্যাশিং সুবিধা অনুরোধটি প্রসেস করতে পারে |
| একই অনুরোধ URI সহ একটি ক্যাশে এন্ট্রি পাওয়া গেছে, কিন্তু এতে শুধুমাত্র দুর্বল ETags আছে | ক্লায়েন্টকে ফেরত পাঠানোর আগে এন্ট্রিটি অরিজিন সার্ভারকে আবার যাচাই করতে হবে |
| ETag অরিজিন সার্ভার থেকে আসে। | ETag অপরিবর্তিত অবস্থায় ক্লায়েন্টকে ফেরত দেওয়া হয় |
If-None-Match
If-None-Match হেডার সহ, কোনও ক্যাশে করা এন্টিটি তখনই বর্তমান হিসেবে বিবেচিত হয় যদি হেডার ক্যাশে করা ETag-এর সাথে না মেলে।
এই
হেডার আছে এমন GET ছাড়া অন্য অনুরোধ অরিজিন সার্ভারে পাঠানো হয়।
Edge এই হেডার সহ কোনও ইনবাউন্ড GET অনুরোধ পেলে:
| যদি | তারপর |
|---|---|
If-None-Match হেডারে এক বা একাধিক ETag উল্লেখ করা থাকে |
|
|
|
Edge 304 Not Modified স্ট্যাটাস কোড রিটার্ন করে |
| একই অনুরোধ URI সহ একটি ক্যাশে এন্ট্রি পাওয়া গেছে, কিন্তু এতে শুধুমাত্র দুর্বল ETags আছে | Edge ক্লায়েন্টকে এটি ফেরত দেওয়ার আগে অরিজিন সার্ভারকে এন্ট্রিটি আবার যাচাই করে নিতে হবে |
| Edge কোনও অরিজিন সার্ভার থেকে ETag পায় | ETag অপরিবর্তিত অবস্থায় ক্লায়েন্টকে ফেরত দেওয়া হয় |
If-Modified-Since
Apigee Edge যদি GET অনুরোধে If-Modified-Since হেডার পায়, তাহলে সেটি
অরিজিন সার্ভারে পাঠিয়ে দেওয়া হয়, এমনকি সঠিক ক্যাশে এন্ট্রি থাকলেও এটি করা হয়।
এটি নিশ্চিত করে যে Apigee Edge-এর মাধ্যমে পাস করেনি এমন কোনও রিসোর্সে করা যেকোনও আপডেট
হিসেবে গণ্য করা হয়। অরিজিন সার্ভার যদি নতুন এন্টিটি রিটার্ন করে, তাহলে Edge আগে থেকে থাকা ক্যাশে
এন্ট্রির জায়গায় নতুন ভ্যালু বসিয়ে দেয়। সার্ভার যদি 304 Not Modified স্ট্যাটাস কোড রিটার্ন করে, তাহলে Edge রেসপন্স ভ্যালু রিটার্ন করে।
যদি ক্যাশে করা রেসপন্সের Last-Modified হেডার থেকে বোঝা যায় যে এটি
পরিবর্তিত হয়নি।
Accept-Encoding
ইনকামিং অনুরোধে Accept-Encoding হেডার থাকলে এবং তার ভ্যালু
gzip, deflate বা compress হলে, অরিজিন সার্ভার
কম্প্রেস করা ডেটা দিয়ে উত্তর দেয়। পরবর্তী অনুরোধে Accept-Encoding হেডার না থাকলে,
সেটি আনকমপ্রেসড উত্তর আশা করে। Apigee-এর রেসপন্স ক্যাশিং মেকানিজম ইনকামিং হেডারের উপর নির্ভর করে কম্প্রেস করা ও কম্প্রেস না করা, দুই ধরনের উত্তরই
পাঠাতে পারে। এর জন্য অরিজিন সার্ভারে
ফিরে যেতে হয় না।
প্রতিটি ক্যাশে করা আইটেমের জন্য কীগুলিকে আরও অর্থপূর্ণ করে তুলতে, আপনি ক্যাশে কীগুলির সাথে Accept হেডার ভ্যালু যোগ করতে পারেন। আরও বিবরণের জন্য, রেসপন্স ক্যাশে নীতিতে "ক্যাশে কী কনফিগার করা" দেখুন।