क्या उपयोगकर्ता एजेंट अपने अनुरोध में शून्य से अधिकतम आयु निर्धारित कर सकता है?

Question

मुझे एचटीपी कैश rfc पढ़ने के बाद max-age व्यवहार के बारे में संदेह है।

परिदृश्य:

उपयोगकर्ता एजेंट

GET /foo 

उत्पत्ति सर्वर प्रतिक्रिया हेडर

cache-control: max-age=120 

सर्वर उपयोगकर्ता एजेंट है कि संसाधन का अनुरोध किया 2 मिनट के बाद दोबारा सत्यापित किया जाना चाहिए बताता है।

1 मिनट और कुछ सेकंड बाद, उपयोगकर्ता एजेंट, एक और अनुरोध करता है एक 1 के max-age मिनट को निर्दिष्ट:

उपयोगकर्ता एजेंट

cache-control: max-age=60 
GET /foo 

मैं क्या समझ से, इस अनुरोध को उपयोगकर्ता को बायपास करना चाहिए एजेंट कैश
क्यों?
हालांकि मूल सर्वर ने क्लाइंट को बताया कि संसाधन को 2 मिनट के लिए कैश किया जाना चाहिए, उपयोगकर्ता एजेंट को ऐसे संसाधन की आवश्यकता है जो 1 मिनट पुरानी (max-age = 60) हो।
पहले GET से 1 मिनट और कुछ सेकंड के बाद, वह संसाधन वैध नहीं है (उपयोगकर्ता एजेंट बिंदु से) और अनुरोध सीधे मूल सर्वर (या किसी अन्य कैश परतों) पर जाना चाहिए।

क्या मैं सही हूँ? क्या उपयोगकर्ता एजेंट से, max-age शून्य से अधिक निर्दिष्ट करना संभव है? क्या यह सामान्य ब्राउज़र द्वारा समर्थित/सम्मानित है?

जहां मैं काम करता हूं, हमारे पास एक .NET कस्टम कैशिंग तंत्र है जो इस तरह काम करता है; क्लाइंट max-age निर्दिष्ट कर सकते हैं जब उन्हें कैश से संसाधन की आवश्यकता होती है जो "अधिकतम" X सेकेंड पुरानी है।

Answer 1

कोई संदेह के लिए कोई जरूरत नहीं है। RFC7234 Section 5.2.1.1 में एक उदाहरण max-age=5 शामिल है जो शून्य से अधिक है। परिभाषा भी स्पष्ट (जोर मेरा) है:

"अधिकतम उम्र" अनुरोध निर्देश इंगित करता है कि ग्राहक एक प्रतिक्रिया जिनकी उम्र सेकंड की निर्दिष्ट संख्या से अधिक है स्वीकार करने के लिए तैयार नहीं है।

"निर्दिष्ट संख्याओं की संख्या" किसी भी गैर-ऋणात्मक पूर्णांक (Section 1.2.1 में परिभाषित) हो सकती है। तो उत्तर एक निश्चित हां है।

इसके अतिरिक्त, मैंने उद्धृत परिभाषा भी आपके परिदृश्य में कैश व्यवहार को समझाती है। लेकिन इससे पहले कि मैं उस पर आते हैं, मैं निम्नलिखित ठीक हो जानी चाहिए:

सर्वर उपयोगकर्ता एजेंट संसाधन अनुरोध किया है कि 2 मिनट के बाद दोबारा सत्यापित किया जाना चाहिए बताता है।

गलत।

max-age=120 निर्देश का अर्थ है कि सर्वर सभी कैश बताता है, उपयोगकर्ता एजेंट नहीं, कि प्रतिक्रिया को 2 मिनट के बाद बासी माना जाना चाहिए। Section 5.2.2.8 (जोर मेरा) से:

"अधिकतम उम्र" प्रतिक्रिया निर्देश इंगित करता है कि प्रतिक्रिया बासी विचार किया जाना है के बाद अपनी उम्र सेकंड की निर्दिष्ट संख्या से अधिक है।

जैसा कि आप देख सकते हैं, कोई पुनर्मूल्यांकन आवश्यकता नहीं है। यदि 10 मिनट बाद तक उसी संसाधन के लिए कोई अनुरोध नहीं है, तो 10 मिनट बाद तक कोई पुनर्मूल्यांकन नहीं होगा।

इसके अलावा, से Section 5.2 (जोर मेरा):

"कैश-नियंत्रण" हेडर फ़ील्ड कैश अनुरोध/प्रतिक्रिया श्रृंखला के साथ के लिए निर्देशों निर्दिष्ट करने के लिए प्रयोग किया जाता है।

बस कैश, उपयोगकर्ता एजेंट नहीं।

अनुरोध/प्रतिक्रिया श्रृंखला में प्रत्येक प्रतिभागी को उसी कैश-कंट्रोल हेडर के साथ समान प्रतिक्रिया प्राप्त होती है, लेकिन कैश-कंट्रोल हेडर के इच्छित प्राप्तकर्ता केवल कैश होते हैं। याद रखें, सिर्फ इसलिए कि आप इसे प्राप्त करते हैं, इसका मतलब यह नहीं है कि यह आपके लिए है।

आपके बाकी परिदृश्य के लिए, आपका मूल्यांकन सही है। ,

के बाद 1 मिनट और कुछ ही सेकंड, प्रयोक्ता एजेंट एक और अनुरोध करता है एक 1 मिनट की max-age को निर्दिष्ट: मैं यहाँ यह बोली जाएगा

...

मैं क्या समझ से, इस अनुरोध को उपयोगकर्ता एजेंट कैश को बाईपास करना चाहिए। क्यों?

क्योंकि अनुरोध के समय, संग्रहित प्रतिक्रिया की उम्र 60 सेकंड से अधिक है। यह स्पष्ट होना चाहिए कि यदि संग्रहित प्रतिक्रिया की उम्र 65 सेकंड कहती है, तो इसका उपयोग max-age=60 निर्देश के साथ अनुरोध को पूरा करने के लिए नहीं किया जा सकता है। इस प्रकार, कैश बस प्राप्त होने वाले निर्देश का पालन करता है।

वास्तव में, किसी भी मानकों के अनुरूप HTTP कैश कि क्या किसी ब्राउज़र में एकीकृत या अलग निर्देश उसे प्राप्त होने की आज्ञा का पालन करने की आवश्यकता है के रूप में Section 5.2 (स्रोत से अपरकेस जोर, मेरा नहीं) में कहा गया है:

एक कैश इस खंड में परिभाषित कैश-नियंत्रण निर्देशों की आवश्यकताओं का पालन करना होगा।

आपके द्वारा वर्णित कस्टम कैशिंग तंत्र के आधार पर आपके पास काम करने वाले कस्टम कैशिंग तंत्र मानक मानते हैं। तो, डेवलपर्स के लिए मेरा पूरक, खासकर अगर "कस्टम" से आपका मतलब है "घर में विकसित"।

Answer 2

RFC2616 अधिकतम उम्र

When an intermediate cache is forced, by means of a max-age=0 
    directive, to revalidate its own cache entry, and the client has 
    supplied its own validator in the request, the supplied validator 
    might differ from the validator currently stored with the cache 
    entry. In this case, the cache MAY use either validator in making 
    its own request without affecting semantic transparency. 

    However, the choice of validator might affect performance. The 
    best approach is for the intermediate cache to use its own 
    validator when making its request. If the server replies with 304 
    (Not Modified), then the cache can return its now validated copy 
    to the client with a 200 (OK) response. If the server replies with 
    a new entity and cache validator, however, the intermediate cache 
    can compare the returned validator with the one provided in the 
    client's request, using the strong comparison function. If the 
    client's validator is equal to the origin server's, then the 
    intermediate cache simply returns 304 (Not Modified). Otherwise, 
    it returns the new entity with a 200 (OK) response. 

    If a request includes the no-cache directive, it SHOULD NOT 
    include min-fresh, max-stale, or max-age. 

आरएफसी के अंतिम लाइनों से से

:

एक अनुरोध नहीं-कैश निर्देश शामिल है तो उसका नहीं को शामिल करना चाहिए min- ताजा, अधिकतम-बासी, या अधिकतम आयु।

से 13.2.6 Disambiguating Multiple Responses section

When a client tries to revalidate a cache entry, 
and the response it receives contains a Date header that 
appears to be older than the one for the existing entry, 
then the client SHOULD repeat the request 
unconditionally, and include 

    Cache-Control: max-age=0 

to force any intermediate caches to validate their copies directly with the origin server, or 

    Cache-Control: no-cache 

to force any intermediate caches to obtain a new copy from the origin server. 

If the Date values are equal, then the client MAY use either response 
(or MAY, if it is being extremely prudent, request a new response). 
Servers MUST NOT depend on clients being able to choose 
deterministically between responses generated during the same 
second, if their expiration times overlap. 

मेरे समझ है कि ग्राहक के पक्ष (user agent) से max-age=0, no-cache के विपरीत नवीनतम संग्रहीत संस्करण का उपयोग कर, के लिए एक तंत्र के रूप में इस्तेमाल किया जा सकता है कि फिर से लाएं जाएगा संसाधन।

curl -I -H 'Cache-Control: no-cache' http://example.com 

इसलिए अगर शून्य से भी बड़ा एक मूल्य के साथ max-age उपयोग करने के बजाय यह हेडर एक मूल्य max-age में परिभाषित में प्राप्त की तारीख के बीच का अंतर मिलान संग्रहीत संस्करण का उपयोग करना चाहिए।

यकीन नहीं है कि अगर मैं राघ हूं लेकिन जैसा कि मैं अवांछित हूं।

समान प्रश्न के साथ पूरक: What's the difference between Cache-Control: max-age=0 and no-cache?