जब कोई उपयोगकर्ता लॉग इन नहीं होता है और लॉगिन की आवश्यकता वाले पृष्ठ तक पहुंचने का प्रयास करता है, तो लॉगिन पृष्ठ पर रीडायरेक्ट के लिए सही HTTP स्थिति कोड क्या है?
मैं पूछ रहा हूँ क्योंकि में से कोई भी 3xx प्रतिक्रिया कोड W3C द्वारा निर्धारित लग आवश्यकताओं फिट करने के लिए:
10.3.1 300 एकाधिक विकल्प
अनुरोधित संसाधन प्रतिनिधित्व के किसी एक सेट से मेल खाता है, प्रत्येक का अपना विशिष्ट स्थान है, और एजेंट द्वारा संचालित वार्ता जानकारी (खंड 12) प्रदान की जा रही है ताकि उपयोगकर्ता (या उपयोगकर्ता एजेंट) एक पसंदीदा प्रतिनिधित्व का चयन कर सके और उसका पुनर्निर्देशन कर सके। उस स्थान के लिए अनुरोध।
जब तक यह एक HEAD अनुरोध नहीं था, प्रतिक्रिया SHOULD में संसाधन विशेषताओं और स्थान (नों) की सूची वाली एक इकाई शामिल होती है जिसमें से उपयोगकर्ता या उपयोगकर्ता एजेंट सबसे उपयुक्त चुन सकते हैं। इकाई प्रारूप सामग्री प्रकार हेडर फ़ील्ड में दिए गए मीडिया प्रकार द्वारा निर्दिष्ट किया गया है। प्रारूप और की क्षमताओं पर निर्भर करता है
उपयोगकर्ता एजेंट, सबसे उपयुक्त विकल्प का चयन स्वचालित रूप से किया जा सकता है। हालांकि, यह विनिर्देश ऐसे स्वचालित चयन के लिए किसी भी मानक को परिभाषित नहीं करता है।
यदि सर्वर के पास प्रतिनिधित्व का पसंदीदा विकल्प है, तो वह स्थान क्षेत्र में उस प्रतिनिधित्व के लिए विशिष्ट URI को शामिल करता है; उपयोगकर्ता एजेंट स्वतः पुनर्निर्देशन के लिए स्थान फ़ील्ड मान का उपयोग करते हैं। जब तक अन्यथा इंगित न किया जाए, यह प्रतिक्रिया अस्वीकार्य है।
10.3.2 301 स्थायी रूप से स्थानांतरित
अनुरोधित संसाधन को एक नया स्थायी यूआरआई सौंपा गया है और भविष्य में इस संसाधन के किसी भी संदर्भ को लौटाए गए यूआरआई में से एक का उपयोग करना चाहिए। लिंक संपादन क्षमताओं वाले ग्राहकों को जहां संभव हो, सर्वर द्वारा वापस किए गए एक या अधिक नए संदर्भों के लिए अनुरोध-यूआरआई के संदर्भों को स्वचालित रूप से फिर से लिंक करना चाहिए। जब तक अन्यथा इंगित न किया जाए, यह प्रतिक्रिया अस्वीकार्य है।
नए स्थायी URI SHOULD को प्रतिक्रिया में स्थान फ़ील्ड द्वारा दिया जाएगा। जब तक अनुरोध विधि HEAD नहीं थी, प्रतिक्रिया की इकाई SHOULD में नए URI (s) के लिए हाइपरलिंक के साथ एक छोटा हाइपरटेक्स्ट नोट होता है।
यदि 301 स्थिति कोड GET या HEAD के अलावा किसी अन्य अनुरोध के जवाब में प्राप्त होता है, तो उपयोगकर्ता एजेंट को स्वचालित रूप से अनुरोध को पुनर्निर्देशित नहीं करना चाहिए जब तक कि उपयोगकर्ता द्वारा इसकी पुष्टि नहीं की जा सकती है, क्योंकि यह उन शर्तों को बदल सकता है जिनके तहत अनुरोध जारी किया गया था।
Note: When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP/1.0 user agents will erroneously change it into a GET request.10.3.3 302 मिला
अनुरोधित संसाधन अस्थायी रूप से एक अलग URI के तहत रहता है। चूंकि इस अवसर पर पुनर्निर्देशन में परिवर्तन किया जा सकता है, ग्राहक ग्राहक भविष्य के अनुरोधों के लिए अनुरोध-यूआरआई का उपयोग करना जारी रखेंगे। यदि कैश-कंट्रोल या समाप्ति शीर्ष लेख फ़ील्ड द्वारा इंगित किया गया है तो यह प्रतिक्रिया केवल देखने योग्य है।
प्रतिक्रिया में स्थान फ़ील्ड द्वारा अस्थायी URI SHOULD दिया जाना चाहिए। जब तक अनुरोध विधि HEAD नहीं थी, प्रतिक्रिया की इकाई SHOULD में नए URI (s) के लिए हाइपरलिंक के साथ एक छोटा हाइपरटेक्स्ट नोट होता है।
अगर GET या HEAD के अलावा किसी अन्य अनुरोध के जवाब में 302 स्टेटस कोड प्राप्त होता है, तो उपयोगकर्ता एजेंट को अनुरोध को स्वचालित रूप से तब तक रीडायरेक्ट नहीं करना चाहिए जब तक कि उपयोगकर्ता द्वारा इसकी पुष्टि नहीं की जा सकती है, क्योंकि यह उन शर्तों को बदल सकता है जिनके तहत अनुरोध जारी किया गया था।
Note: RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if itमूल अनुरोध विधि की परवाह किए बिना, स्थान फ़ील्ड-मान पर GET का प्रदर्शन करते हुए, 303 प्रतिसाद थे। स्थिति कोड 303 और 307 उन सर्वरों के लिए जोड़े गए हैं जो स्पष्ट रूप से स्पष्ट करना चाहते हैं कि क्लाइंट को किस तरह की प्रतिक्रिया की उम्मीद है।
10.3.4 303 अन्य देखें
अनुरोध की प्रतिक्रिया एक अलग URI के तहत मिल सकती है और उस संसाधन पर GET विधि का उपयोग करके पुनर्प्राप्त किया जा सकता है। यह विधि मुख्य रूप से एक चयनित संसाधन के लिए उपयोगकर्ता एजेंट को पुनर्निर्देशित करने के लिए POST- सक्रिय स्क्रिप्ट के आउटपुट की अनुमति देने के लिए मौजूद है। नया यूआरआई मूल रूप से अनुरोधित संसाधन के लिए एक स्थानापन्न संदर्भ नहीं है। 303 प्रतिसाद को कैश नहीं किया जाना चाहिए, लेकिन दूसरे (पुनर्निर्देशित) अनुरोध के प्रतिसाद अस्वीकार्य हो सकता है।
प्रतिक्रिया में स्थान फ़ील्ड द्वारा भिन्न URI SHOULD दिया जाना चाहिए। जब तक अनुरोध विधि HEAD नहीं थी, प्रतिक्रिया की इकाई SHOULD में नए URI (s) के लिए हाइपरलिंक के साथ एक छोटा हाइपरटेक्स्ट नोट होता है।
Note: Many pre-HTTP/1.1 user agents do not understand the 303 status. When interoperability with such clients is a concern, the 302 status code may be used instead, since most user agents react to a 302 response as described here for 303.10.3.5 304 संशोधित नहीं
यदि क्लाइंट ने सशर्त GET अनुरोध किया है और पहुंच की अनुमति है, लेकिन दस्तावेज़ को संशोधित नहीं किया गया है, तो सर्वर इस स्थिति कोड के साथ प्रतिक्रिया करेगा। 304 प्रतिसाद में एक संदेश-निकाय नहीं होना चाहिए, और इस तरह हमेशा शीर्ष लेख फ़ील्ड के बाद पहली खाली पंक्ति द्वारा समाप्त किया जाता है।
प्रतिक्रिया में निम्नलिखित हेडर फ़ील्ड शामिल होने चाहिए:
- Date, unless its omission is required by section 14.18.1 If aक्लॉकलेस ओरिजनल सर्वर इन नियमों का पालन करता है, और परदे के पीछे और क्लाइंट्स बिना किसी रिस्पॉन्स के अपनी डेट खुद जोड़ लेते हैं (जैसा कि पहले से ही [RFC 2068], सेक्शन 14.19 द्वारा निर्दिष्ट है), कैश सही तरीके से काम करेगा।
- ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request - Expires, Cache-Control, and/or Vary, if the field-value might differ from that sent in any previous response for the same variant If the conditional GET used a strong cache validator (seeखंड 13.3.3), प्रतिक्रिया में अन्य संस्था-प्रमुख शामिल नहीं हैं। अन्यथा (यानी, सशर्त GET ने एक कमजोर सत्यापनकर्ता का उपयोग किया), प्रतिक्रिया में अन्य इकाई-हेडर शामिल नहीं होने चाहिए; यह कैश्ड इकाई-निकायों और अद्यतन हेडर के बीच विसंगतियों को रोकता है।
यदि 304 प्रतिसाद इंगित करता है कि कोई इकाई वर्तमान में कैश नहीं है, तो कैश को प्रतिक्रिया की अवहेलना करनी चाहिए और सशर्त के बिना अनुरोध को दोहराना चाहिए।
यदि कोई कैश प्रविष्टि को अद्यतन करने के लिए प्राप्त 304 प्रतिसाद का उपयोग करता है, तो प्रतिक्रिया में दिए गए किसी भी नए मान को प्रतिबिंबित करने के लिए संचय प्रविष्टि को अद्यतन करना चाहिए।
10.3.6 305 उपयोग प्रॉक्सी
अनुरोधित संसाधन को स्थान फ़ील्ड द्वारा दिए गए प्रॉक्सी के माध्यम से एक्सेस किया जाना चाहिए। स्थान फ़ील्ड प्रॉक्सी का URI देता है। प्राप्तकर्ता को प्रॉक्सी के माध्यम से इस एकल अनुरोध को दोहराने की उम्मीद है। 305 प्रतिक्रियाओं केवल मूल सर्वर द्वारा उत्पन्न किया जाना चाहिए।
Note: RFC 2068 was not clear that 305 was intended to redirect a single request, and to be generated by origin servers only. Not observing these limitations has significant security consequences.10.3.7 306 (अप्रयुक्त)
विनिर्देश के पिछले संस्करण में 306 स्थिति कोड का उपयोग किया गया था, अब इसका उपयोग नहीं किया जाता है, और कोड आरक्षित है।
10.3.8 307 अस्थाई पुनर्निर्देश
अनुरोधित संसाधन अस्थायी रूप से एक अलग URI के तहत रहता है। चूंकि पुनर्निर्देशन मई के अवसर पर बदल दिया जाता है, ग्राहक ग्राहक भविष्य के अनुरोधों के लिए अनुरोध-यूआरआई का उपयोग करना जारी रखते हैं। यदि कैश-कंट्रोल या समाप्ति शीर्ष लेख फ़ील्ड द्वारा इंगित किया गया है तो यह प्रतिक्रिया केवल देखने योग्य है।
प्रतिक्रिया में स्थान फ़ील्ड द्वारा अस्थायी URI SHOULD दिया जाना चाहिए। जब तक अनुरोध विधि HEAD नहीं थी, प्रतिक्रिया की इकाई SHOULD में नए URI (s) के लिए हाइपरलिंक के साथ एक छोटा हाइपरटेक्स्ट नोट होता है, क्योंकि कई पूर्व HTTP / 1.1 उपयोगकर्ता एजेंट 307 स्थिति को नहीं समझते हैं। इसलिए, नोट SHOULD में नए URI पर मूल अनुरोध को दोहराने के लिए उपयोगकर्ता के लिए आवश्यक जानकारी होती है।
अगर G7 या HEAD के अलावा किसी अन्य अनुरोध के जवाब में 307 स्टेटस कोड प्राप्त होता है, तो उपयोगकर्ता एजेंट को अनुरोध को स्वचालित रूप से तब तक रीडायरेक्ट नहीं करना चाहिए जब तक कि उपयोगकर्ता द्वारा इसकी पुष्टि नहीं की जा सकती है, क्योंकि यह उन शर्तों को बदल सकता है जिनके तहत अनुरोध जारी किया गया था।
मैं अब तक 302 का उपयोग कर रहा हूं, जब तक मुझे सही उत्तर नहीं मिल जाता ।
अपडेट और निष्कर्ष:
HTTP 302 बेहतर है क्योंकि इसके ग्राहकों / ब्राउज़रों के साथ सर्वोत्तम अनुकूलता ज्ञात है।