only-if-cached ப்ராக்ஸியிடம் சேமிக்கப்பட்ட பதிலைக் கேட்கிறது
ஒத்துழைக்கும் HTTP தேக்ககத்திடம் ஏற்கனவே உள்ள பதிலைக் கேட்டு, 504-ஐ நெட்வொர்க் நிலைக் கட்டுப்பாடாகக் கருதாமல் தேக்ககத் தவறாகப் புரிந்துகொள்ளுங்கள்.
ஏற்கனவே சேமிக்கப்பட்ட பதிலைப் பயன்படுத்த வேண்டிய கோரிக்கைக்கு 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 வளத்தை வேண்டுமென்றே பயன்படுத்துகிறது.