only-if-cached প্রক্সি থেকে সংরক্ষিত প্রতিক্রিয়া চায়

এমন অনুরোধের জন্য যা আগে সংরক্ষিত প্রতিক্রিয়া ব্যবহার করবে, HTTP Cache-Control: only-if-cached নির্ধারণ করে।

ক্লায়েন্ট এটি HTTP ক্যাশিং প্রক্সির মাধ্যমে পাঠাতে পারে:

curl --proxy http://127.0.0.1:3128 \
  --header 'Cache-Control: only-if-cached' \
  --include http://www.example.org/report

এই নির্দেশ মানা ক্যাশের উচিত অনুরোধের অন্যান্য সীমাবদ্ধতার সঙ্গে সামঞ্জস্যপূর্ণ সংরক্ষিত প্রতিক্রিয়া ফেরানো, অথবা অনুরোধ পূরণ করতে না পারলে 504 Gateway Timeout দেওয়া। এখানে 504 প্রক্সিতে ব্যর্থ TCP সংযোগের বদলে ক্যাশ নীতি বোঝাতে পারে।

নির্দেশটি পুরোনো বিষয়বস্তুকে স্বয়ংক্রিয়ভাবে অনুমোদন করে না। সতেজতা, বৈধকরণের প্রয়োজনীয়তা এবং সামঞ্জস্যপূর্ণ Vary ক্ষেত্র এখনও গুরুত্বপূর্ণ। no-cache অনুরোধ নির্দেশ বরং পুনরায় ব্যবহারের আগে সফল মূল বৈধকরণ দাবি করতে পারে।

এটি ক্যাশের অফলাইন বৈধকরণ মোড সেট করার থেকেও আলাদা। only-if-cached পৃথক অনুরোধে বহন করা হয় এবং ক্লায়েন্ট কী গ্রহণ করতে রাজি তা প্রকাশ করে।

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

সাধারণ HTTPS CONNECT প্রক্সি এনক্রিপ্ট করা HTTP হেডার দেখে না এবং ওই টানেল থেকে পৃষ্ঠা বস্তু সংরক্ষণ করে না। উদাহরণটি ইচ্ছাকৃতভাবে সাধারণ HTTP সম্পদ ব্যবহার করে যা ক্যাশ প্রক্রিয়া করতে পারে।