HTTP त्रुटि कोड्स की इच्छित उद्देश्य के संदर्भ में, मैं निश्चित रूप से, 403 Forbidden साथ जाना, क्योंकि वह पृष्ठ मौजूद है जाएगा (404 बाहर है), लेकिन उपयोगकर्ता मना अब के लिए इसे उपयोग करने (और यह प्रतिबंध नहीं है एक संसाधन संघर्ष के कारण नहीं है, समवर्ती संशोधन की तरह, लेकिन उपयोगकर्ता की खाता स्थिति के कारण, यानी 40 9 मेरी राय में भी बाहर है)। इसके इरादे के उद्देश्य के आधार पर एक और समझदार विकल्प 401 हो सकता था, लेकिन जैसा कि नाली ने पहले ही अपनी टिप्पणी में नोट किया था, यह कोड कुछ लोगों को ट्रिगर करता है, यदि सभी नहीं, तो ब्राउज़र एक लॉगिन संवाद प्रदर्शित करने के लिए, जैसा कि इसका तात्पर्य है कि मानक वेब-प्रमाणीकरण तंत्र का उपयोग कर सकते हैं मामले को हल करो। तो, यह निश्चित रूप से यहां आपके लिए एक विकल्प नहीं होगा।
दो बातें एक छोटे से "misfitting" 403 के विवरण में लग रहे हैं, इसलिए मुझे उन्हें सुलझाने करते हैं:
- प्राधिकरण में मदद नहीं करेगा ...: यह HTTP के अंदर प्राधिकरण तंत्र के बारे में केवल वार्ता प्रोटोकॉल और 401 से 403 अंतर करने के लिए है।यह कथन कस्टम प्राधिकरण या सत्र राज्य प्रबंधन के किसी भी रूप पर लागू नहीं होता है।
- ... अनुरोध दोहराया नहीं जाना चाहिए ...: सत्र संदर्भ में हमेशा एक अनुरोध देखा जाना चाहिए, इसलिए यदि उपयोगकर्ता का सत्र संदर्भ बदलता है (वह एक सुविधा को अनलॉक करता है) और फिर वह उस तक पहुंचने के लिए पुनः प्रयास करता है एक ही संसाधन, यह एक अलग अनुरोध है, यानी इस सुझाव का कोई उल्लंघन नहीं है।
बेशक
, आप भी अपनी खुद की त्रुटि कोड निर्धारित कर सकते हैं, लेकिन जब से यह शायद कोई आधिकारिक तरह से आरक्षित नहीं किया जाएगा, वहाँ कोई गारंटी नहीं है कि कुछ ब्राउज़र निर्माता जानबूझकर या गलती से वास्तव में उपयोग करने के लिए नहीं जा रहा है है वह कोड एक विशिष्ट (डीबगिंग) क्रिया को ट्रिगर करने के लिए। यह असंभव है, लेकिन अस्वीकृत नहीं है।
418 हालांकि, ठीक भी हो सकता है। :)
बेशक, यदि आप विशेष रूप से सुविधाओं की संभावित उपलब्धता को अस्पष्ट करना चाहते हैं, तो आप 404 का उपयोग करने का भी निर्णय ले सकते हैं क्योंकि यह एकमात्र तरीका है जो किसी भी उपयोगकर्ता को कोई संकेत नहीं देता है।
अब, अपने कैशिंग मुद्दे पर:
न तो ये स्थिति कोड (403, 404, 409, 418) चाहिए ट्रिगर ब्राउज़र अपने किसी अन्य की तुलना में अधिक इच्छा के विरुद्ध पेज कैश करने के लिए में से एक। समस्या यह है कि कई ब्राउज़र पागल जैसे सब कुछ अतिरिक्त स्नैपी होने के लिए बस कोशिश करते हैं। मेरी राय में ओपेरा सबसे खराब है। मैं इन चीजों पर कई बार अपने बालों को खींच रहा हूं। इसे सही शीर्षलेख सेटिंग्स के साथ काम करना संभव होना चाहिए, लेकिन मेरे पास ऐसी स्थितियां थीं जहां ब्राउज़र या सर्वर या कुछ मध्यवर्ती प्रॉक्सी ने उन्हें अनदेखा करने और किसी भी तरह से अपना पृष्ठ तोड़ने का फैसला किया था।
एकमात्र निश्चित-अग्नि तरीका जिसे मैंने अभी तक पाया है कि पूरी तरह से एक रीलोड की गारंटी देता है, एक डमी अनुरोध पैरामीटर जैसे/फ़ील्ड? टी = 2 9 873, जहां 2 9 873 एक ऐसा नंबर है जो आपके द्वारा किए गए हर अनुरोध के लिए अद्वितीय है किसी भी संभावित समय के पैमाने के भीतर। सर्वर पर, ज़ाहिर है, तो आप बस इस पैरामीटर को अनदेखा कर सकते हैं। ध्यान दें कि केवल 1 से शुरू करने के लिए पर्याप्त नहीं है जब आपका उपयोगकर्ता पहले आपका पृष्ठ खोलता है और फिर निम्न अनुरोधों के लिए गिनती करता है, क्योंकि ब्राउज़र पृष्ठ-रीलोड में कैश रख सकते हैं।
मैं जावा (दोनों सर्वर और क्लाइंट साइड GWT का उपयोग) में अपने वेब विकास करते हैं और मैं इस कोड का उपयोग डमी "संख्या" उत्पन्न करने के लिए:
private static final char[] base64chars = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz_.".toCharArray();
private static int tagIndex = 0;
/**
* Generates a unique 6-character tag string that is guaranteed to not repeat
* for about 400 days, if this function is, on average, not called more often
* than twice every millisecond.
*
* @return the tag string
*/
public static String nowTag() {
int tag = (int) ((System.currentTimeMillis() >>> 5)); // adjust
char[] result = new char[6];
result[5] = base64chars[(tagIndex++) & 63];
result[4] = base64chars[tag & 63];
tag >>>= 6;
result[3] = base64chars[tag & 63];
tag >>>= 6;
result[2] = base64chars[tag & 63];
tag >>>= 6;
result[1] = base64chars[tag & 63];
tag >>>= 6;
result[0] = base64chars[tag & 63];
return new String(result);
}
यह साथ संयोजन में सिस्टम की घड़ी का उपयोग करता है एक काउंटर प्रत्येक एमएस के बारे में दो गारंटीकृत अद्वितीय मूल्य प्रदान करने में सक्षम होने के लिए सक्षम है। आपको इस गति की आवश्यकता नहीं हो सकती है, इसलिए आप >>> 5 को बदलने के लिए स्वतंत्र महसूस कर सकते हैं जिसे मैंने आपकी आवश्यकताओं के अनुसार "समायोजित" के साथ चिह्नित किया है। यदि आप इसे 1 तक बढ़ाते हैं, तो आपकी दर दो के कारक और आपकी विशिष्टता समय-अवधि युगल से नीचे जाती है। तो, उदाहरण के लिए, यदि आप इसके बजाय >>> 8 डालते हैं, तो आप प्रत्येक 4 एमएस के बारे में 1 मान उत्पन्न कर सकते हैं और मान 3200 दिनों के लिए दोहराना नहीं चाहिए। बेशक, यह गारंटी है कि उपयोगकर्ता दोहराना नहीं होगा अगर उपयोगकर्ता सिस्टम घड़ी के साथ गड़बड़ कर देता है। लेकिन चूंकि ये मान अनुक्रमिक रूप से उत्पन्न नहीं होते हैं, फिर भी यह बहुत ही असंभव है कि आप एक ही संख्या को दो बार मार देंगे। यूआरएल जितना संभव हो उतना छोटा रखने के लिए कोड दशमलव संख्या के बजाय 6-वर्ण टेक्स्ट-स्ट्रिंग (बेस 64) उत्पन्न करता है।
उम्मीद है कि इससे मदद मिलती है।:)
मुझे सही उत्तर नहीं पता है, लेकिन निम्न पोस्ट कुछ दिलचस्प तर्क प्रदान करता है: http://stackoverflow.com/questions/3297048/403-forbidden-vs-401-unuthorized-http-responses – RobJohnson
क्यों नहीं बस उस पृष्ठ पर रीडायरेक्ट करें जिस पर उन्हें अनुमति है? यह भी पॉप-अप कह सकता है कि यह सुविधा अभी तक उपलब्ध नहीं है। –
वैसे, '401 अनधिकृत 'एक बुरा विचार होगा, क्योंकि यह स्थिति कोड केवल HTTP प्रमाणीकरण के लिए है और ब्राउज़र विशेष रूप से इस स्थिति कोड को संभालते हैं। – nalply