302 और 307 पुनर्निर्देशित के बीच क्या अंतर है?

208

एक में क्या अंतर है 302 FOUNDऔर एक 307 TEMPORARY REDIRECTHTTP प्रतिक्रिया?

W3 कल्पना से प्रतीत होता है कि वे दोनों अस्थायी पुनर्निर्देश के लिए उपयोग किए जाते हैं, और न ही कैश किया जा सकता है जब तक कि प्रतिक्रिया विशेष रूप से अनुमति नहीं देती है।

http redirect

— Zach Hirsch
स्रोत

99

अंतर चिंताओं पुनः निर्देशित POST, PUTऔर DELETEअनुरोध और क्या सर्वर की उम्मीदों उपयोगकर्ता एजेंट के व्यवहार के लिए कर रहे हैं ( RFC 2616):

नोट: RFC 1945 और RFC 2068 निर्दिष्ट करते हैं कि क्लाइंट को पुनर्निर्देशित अनुरोध पर विधि को बदलने की अनुमति नहीं है। हालाँकि, अधिकांश मौजूदा उपयोगकर्ता एजेंट कार्यान्वयन 302 को मानते हैं जैसे कि यह 303 प्रतिक्रिया थी, मूल अनुरोध पद्धति की परवाह किए बिना स्थान फ़ील्ड-मान पर GET का प्रदर्शन करना। स्थिति कोड 303 और 307 उन सर्वरों के लिए जोड़े गए हैं जो स्पष्ट रूप से स्पष्ट करना चाहते हैं कि क्लाइंट को किस तरह की प्रतिक्रिया की उम्मीद है।

इसके अलावा, 30x पुनर्निर्देशन कोड पर विकिपीडिया लेख पढ़ें ।

— फ्रैंकी पेनोव
स्रोत

तो, एक पार्सर / एजेंट / ब्राउज़र के नजरिए से, हम बस 302 और 307 को समान अधिकार मान सकते हैं? ( कोड के ठीक उसी टुकड़े का उपयोग बिना किसी और अंतर के दोनों मामलों को संभालने के लिए किया जा सकता है?)

— पेसियर

नहीं - आप 302 और 303 को समान मान सकते हैं, लेकिन 307 अलग है।

— क्वेंटिन स्कूसन

@kkhugs, कोई रास्ता नहीं, एक 1.0 ब्राउज़र प्राप्त करने के लिए आवश्यक है -302 उसी तरह जैसे कि गेट -307 1.1 ब्राउज़र में किया जाता है। एक 1.0 ब्राउज़र को पोस्ट -302 को उसी तरह से करना आवश्यक है, जैसे कि यह 302 प्राप्त करता है, इसके अलावा इसे आगे बढ़ने के लिए पहले उपयोगकर्ता की पुष्टि की आवश्यकता होती है, और विधि को पोस्ट होना चाहिए।

— पैशियर

1.1 ब्राउजर को गेट -302 की तरह करना जरूरी है, क्योंकि यह 307 मिलता है।

— पैशियर

161

307 के बारे में आया क्योंकि उपयोगकर्ता एजेंटों ने POST अनुरोधों को लेने के लिए एक वास्तविक व्यवहार के रूप में अपनाया, जो 302 प्रतिसाद प्राप्त करता है और स्थान प्रतिक्रिया हैडर को GET अनुरोध भेजता है।

यह गलत व्यवहार है - केवल 303 के कारण POST को GET में बदलना चाहिए। यदि मूल POST अनुरोध 302 लौटाया जाता है तो नए URL का अनुरोध करते समय उपयोगकर्ता एजेंटों को POST विधि के साथ रहना चाहिए (लेकिन नहीं)।

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

— क्रिस्टोफर ओर
स्रोत

3

उपयोगकर्ता एजेंटों का कोई भी उदाहरण जो गलत तरीके से प्रतिक्रिया करता है? क्या यह आमतौर पर आगंतुकों का एक बहुत छोटा प्रतिशत है?

— goodguys_activate

6

@ makerofthings7 सभी ब्राउजर 302गलत तरीके से हैंडल करते हैं । क्रोम 30, IE10। यह वास्तव में गलत कार्यान्वयन हो गया; इसे बदला नहीं जा सकता क्योंकि इतने सारे वेब-साइट गलती से 302 जारी करते हैं। वास्तव में ASP.net MVC 302 को गलत तरीके से जारी करता है , इस तथ्य के आधार पर कि ब्राउज़र इसे गलत तरीके से संभालते हैं।

— इयान बॉयड

1

@IanBoyd केवल कारण फ्रेमवर्क ऐसा करते हैं, क्योंकि 303इसे 307HTTP 1.1 विनिर्देश में भी पेश किया गया था और इसलिए HTTP 1.0 उपयोगकर्ता एजेंटों के साथ पीछे की संगतता की अनुमति देता है। बेशक, असली सवाल यह है कि क्या हमें अभी भी HTTP 1.0 उपयोगकर्ता एजेंटों को संभालना चाहिए?

— इवानमॉ

1

@ ewanm89 ऐसा लगता है कि रूपरेखा ठीक से नामित प्रतिक्रिया विधि (जैसे Response.RedirectSeeOther) बना सकती है, और यदि क्लाइंट 1.1 (जैसे ) नहीं है GET /foo.html, GET /foo.html HTTP/1.0तो विरासत जारी करें 302।

— इयान बॉयड

पुनर्निर्देशित होने पर यह 302 = 303 जैसा दिखता है।

— vee

60

307 Internal Redirectकार्रवाई का एक अच्छा उदाहरण यह है कि जब Google Chrome एक ऐसे डोमेन पर HTTP कॉल का सामना करता है, जिसे वह सख्त परिवहन सुरक्षा की आवश्यकता के रूप में जानता है।

मूल कॉल के समान विधि का उपयोग करके, ब्राउज़र मूल रूप से रीडायरेक्ट करता है।

HTST 307 आंतरिक पुनर्निर्देश

— क्रिस्टियन विलियम्स
स्रोत

2

क्या आप जानते हैं कि Google ने इस सुविधा को कब लागू किया था?

— तैजमे

2

हां, यह वह जगह है जहां मैं इसे देख रहा हूं - हमारा सर्वर यह नहीं भेज रहा है - क्रोम डेविटूल में ऐसा लग रहा है कि यह ऐसा है, लेकिन यह क्रोम केवल रीडायरेक्ट कर रहा है क्योंकि हमारे पास एक सख्त परिवहन सुरक्षा हेडर है

— माइक नेल्सन

16

301: स्थायी पुनर्निर्देशित: URL पुराना है और इसे बदला जाना चाहिए। ब्राउज़र इसे कैश कर देंगे।
उदाहरण उपयोग: URL से ले जाया /register-form.htmlगया signup-form.html।
RFC 7231 के अनुसार, विधि GET में बदल जाएगी: "ऐतिहासिक कारणों से, एक उपयोगकर्ता एजेंट MAY, बाद के अनुरोध के लिए POST से GET में अनुरोध विधि को बदल देता है।"
302: अस्थायी पुनर्निर्देश। केवल HTTP / 1.0 क्लाइंट के लिए उपयोग करें। इस स्थिति कोड को विधि में परिवर्तन नहीं करना चाहिए, लेकिन ब्राउज़रों ने इसे वैसे भी किया। RFC कहता है: "कई प्री-HTTP / 1.1 उपयोगकर्ता एजेंट समझ नहीं पाते [303]। जब इस तरह के क्लाइंट के साथ इंटरऑपरेबिलिटी एक चिंता का विषय है, तो इसके बजाय 302 स्टेटस कोड का उपयोग किया जा सकता है, क्योंकि अधिकांश उपयोगकर्ता एजेंट यहां बताए गए अनुसार 302 प्रतिक्रिया देते हैं। 303 के लिए। " बेशक, कुछ क्लाइंट इसे कल्पना के अनुसार लागू कर सकते हैं, इसलिए यदि ऐसे प्राचीन ग्राहकों के साथ इंटरऑपरेबिलिटी वास्तविक चिंता नहीं है, तो 303 लगातार परिणाम के लिए बेहतर है।
303: अस्थायी पुनर्निर्देशन, विधि को GET में बदलना।
उदाहरण उपयोग: यदि ब्राउज़र ने POST को भेजा है /register.php, तो अब लोड करें (GET) /success.html।
307: अस्थायी पुनर्निर्देशित, अनुरोध को पहचान के रूप में दोहराते हुए।
उदाहरण का उपयोग: यदि ब्राउज़र ने POST भेजा है /register.php, तो यह POST को फिर से करने के लिए कहता है /signup.php।
308: स्थायी पुनर्निर्देशित, अनुरोध को पहचान के साथ दोहराते हुए। जहाँ 307 303 का "नो मेथड चेंज" समकक्ष है, वहीं यह 308 स्टेटस 301 का "नो मेथड चेंज" प्रतिरूप है।

RFC 7231 (2014 से) बहुत पठनीय है और अत्यधिक क्रिया नहीं है। यदि आप सटीक उत्तर जानना चाहते हैं, तो यह एक अनुशंसित रीड है। कुछ अन्य उत्तर 1999 से RFC 2616 का उपयोग करते हैं, लेकिन कुछ भी नहीं बदला।

RFC 7238 308 की स्थिति निर्दिष्ट करता है। इसे प्रायोगिक माना जाता है, लेकिन यह 2016 में सभी प्रमुख ब्राउज़रों द्वारा पहले से ही समर्थित था ।

— ल्यूक
स्रोत

302 को पदावनत नहीं किया गया है।

— जूलियन रेसके ने

@JulianReschke विकिपीडिया का कहना है कि "302 को 303 और 307 ने खत्म कर दिया।" हो सकता है कि क्योंकि मैं एक देशी वक्ता नहीं हूं, लेकिन मेरे लिए (इस संदर्भ में) अलिखित और पदावनत का मतलब एक ही है: या तो 303 या 307 का उपयोग करें, लेकिन 302 का नहीं। क्या मैं इसे गलत पढ़ रहा हूं?

— ल्यूक

यह गलत है कि विकिपीडिया का इस बारे में क्या कहना है। यदि 302 को हटा दिया गया था, तो HTTP ऐसा कहेगा।

— जूलियन रेसके ने

@JulianReschke फेयर काफी, मैं स्रोत और waddayaknow के लिए ले लिया? आप पूरी तरह से सही हैं। आरएफसी वास्तव में बहुत ही समझ में आता है, और वास्तव में वे कुछ शर्तों के तहत 302 की सिफारिश भी करते हैं। शीर्ष पर उल्लिखित "RFC" द्वारा "अपडेटेड" और "ऑबस्लेटेड" में से कोई भी स्थिति कोड के बारे में नहीं है, इसलिए मुझे लगता है कि यह 1999 का दस्तावेज़ वास्तव में नवीनतम है, जो हमारे पास है। मैं अपना जवाब अपडेट करूंगा।

— लुक

प्रासंगिक क्या है IANA स्थिति कोड रजिस्ट्री, और इस प्रकार, इस मामले में, RFC 7231.

— जूलियन

8

302 के लिए अपेक्षित: पुनर्निर्देशन NEW_URL पर समान अनुरोध विधि POST का उपयोग करता है

CLIENT POST OLD_URL -> SERVER 302 NEW_URL -> CLIENT POST NEW_URL

302, 303 के लिए ACTUAL: NEW_URL पर POST से GET तक पुनर्निर्देशन परिवर्तन विधि

CLIENT POST OLD_URL -> SERVER 302 NEW_URL -> CLIENT GET NEW_URL (redirect uses GET)
CLIENT POST OLD_URL -> SERVER 303 NEW_URL -> CLIENT GET NEW_URL (redirect uses GET)

307 के लिए वास्तविक: पुनर्निर्देशन NEW_URL पर समान अनुरोध विधि POST का उपयोग करता है

CLIENT POST OLD_URL -> SERVER 307 NEW_URL -> CLIENT POST NEW_URL

— रॉय ह्युनजिन हन
स्रोत

2

302 अस्थायी पुनर्निर्देशित है, जो सर्वर द्वारा उत्पन्न होता है जबकि 307 ब्राउज़र द्वारा उत्पन्न आंतरिक पुनर्निर्देशन प्रतिक्रिया है। आंतरिक पुनर्निर्देशन का अर्थ है कि आंतरिक रूप से ब्राउज़र द्वारा रीडायरेक्ट स्वचालित रूप से किया जाता है, मूल रूप से ब्राउज़र HTTP से https में प्रवेश किए गए url को बदल देता है, जिससे अनुरोध करने से पहले खुद से अनुरोध प्राप्त किया जा सके ताकि असुरक्षित कनेक्शन के लिए अनुरोध कभी भी इंटरनेट पर न किया जाए। क्या ब्राउज़र url को https में बदल देगा या नहीं, यह ब्राउज़र के साथ प्रीस्टाइप की गई hsts प्रीलोड सूची पर निर्भर करता है। आप किसी भी साइट को जोड़ सकते हैं जो अपने ही ब्राउजर की hsts प्रीलोड सूची में डोमेन में प्रवेश करके सूची में https का समर्थन करती है जो क्रोम पर है: //net-internals/#hsts.One अधिक बात वेबसाइट डोमेन अपने मालिकों द्वारा जोड़ी जा सकती है https://hstspreload.org/ पर फॉर्म भरकर सूची को प्रीलोड करने के लिएताकि यह प्रत्येक उपयोगकर्ता के लिए ब्राउज़रों में पहले से इंस्टॉल हो जाए, हालांकि मैं उल्लेख करता हूं कि आप विशेष रूप से खुद के लिए भी कर सकते हैं।

मुझे एक उदाहरण के साथ समझाता
हूं : मैंने http://www.pentesteracademy.com पर एक अनुरोध किया, जो केवल https का समर्थन करता है और मेरे पास अपने ब्राउज़र में मेरे hsts प्रीलोड सूची में वह डोमेन नहीं है क्योंकि साइट के मालिक ने इसके लिए पंजीकरण नहीं कराया है। प्रीस्टैंडेड hsts प्रीलोड सूची के साथ आने के लिए। साइट के असुरक्षित संस्करण के लिए GET अनुरोध को सुरक्षित संस्करण पर पुनर्निर्देशित किया गया है (ऊपर की छवि में प्रतिक्रिया के लिए http हेडर नामित स्थान देखें)। अब मैं क्रोम में // hsts डोमेन फॉर्म में अपना डोमेन जोड़कर साइट को अपने खुद के ब्राउजर प्रीलोड सूची में जोड़ देता हूं: // net-internals / # hsts, जो मेरी क्रोम ब्राउजर पर मेरी व्यक्तिगत प्रीलोड सूची को संशोधित करता है। चयन करने के लिए सुनिश्चित करें कि उप-डोमेन शामिल करें वहां एसटीएस का विकल्प। आइए अब इसे उसी वेबसाइट के लिए अनुरोध और प्रतिक्रिया देखें, इसे hsts सूची में जोड़ने के बाद।

आप प्रतिसाद हेडर में आंतरिक पुनर्निर्देशित 307 देख सकते हैं, वास्तव में यह प्रतिक्रिया सर्वर द्वारा नहीं आपके ब्राउज़र द्वारा बनाई गई है।
इसके अलावा एचएसटीएस प्रीलोड सूची उपयोगकर्ताओं को साइट के असुरक्षित संस्करण तक पहुंचने से रोकने में मदद कर सकती है क्योंकि 302 रीडायरेक्ट माइटम हमलों का खतरा है।
आशा है कि मैंने कुछ हद तक आपको रीडायरेक्ट के बारे में समझने में मदद की।

— सिमरनजीत सिंह
स्रोत

2

मूल रूप से बस था 302

| Response               | What browsers should do   |
|------------------------|---------------------------|
| 302 Found              | Redo request with new url |

विचार यह है कि:

यदि आप GETकिसी स्थान पर कर रहे थे , तो आप अपने GETनए URL पर फिर से भेजेंगे
यदि आप POSTकिसी स्थान पर कर रहे थे , तो आप अपने POSTनए URL पर फिर से भेजेंगे
यदि आप PUTकिसी स्थान पर कर रहे थे , तो आप अपने PUTनए URL पर फिर से भेजेंगे
यदि आप DELETEकिसी स्थान पर कर रहे थे , तो आप अपने DELETEनए URL पर फिर से भेजेंगे
आदि

दुर्भाग्य से हर ब्राउज़र ने गलत किया। जब एक हो रहा है 302, वे हमेशा एक ही क्रिया ( जैसे ; ) के GETसाथ अनुरोध को फिर से लेने के बजाय नए URL पर स्विच करेंगे :POST

मोज़ेक ने गलत किया
नेटस्केप ने मोज़ेक में कीड़े की नकल की; इसलिए वे गलत हो गए
इंटरनेट एक्सप्लोरर ने नेटस्केप में कीड़े की नकल की; इसलिए वे गलत हो गए

यह बन गया जिस वास्तविक गलत।

सभी ब्राउज़र 302गलत हो गए। तो 303और 307बनाया गया।

| प्रतिक्रिया | ब्राउज़र क्या करना चाहिए | ब्राउज़र वास्तव में क्या करते हैं | | ------------------------ | ------------------------ --- | --------------------------- | | 302 मिली | नए url के साथ Redo अनुरोध | नए url के साथ प्राप्त करें | | 303 अन्य देखें | नए url के साथ प्राप्त करें | नए url के साथ प्राप्त करें | | 307 अस्थायी रीडायरेक्ट | नए url के साथ Redo अनुरोध | नए url के साथ Redo अनुरोध |

चार्ट के रूप में

पुनर्निर्देश के 5 विभिन्न प्रकार:

╔═══════════╤════════════════════════════════════════════════╗
║           │                Switch to GET?                  ║
║ Temporary │          No            │         Yes           ║
╠═══════════╪════════════════════════╪═══════════════════════╣
║ No        │ 308 Permanent Redirect │ 301 Moved Permanently ║
╟───────────┼────────────────────────┼───────────────────────╢
║ Yes       │ 307 Temporary Redirect │ 303 See Other         ║
║           │ 302 Found (intended)   │ 302 Found (actual)    ║
╚═══════════╧════════════════════════╧═══════════════════════╝

वैकल्पिक रूप से:

| Response                 | Switch to get? | Temporary? |
|--------------------------|----------------|------------|
| 301 Moved Permanently    | No             | No         |
| 302 Found (intended)     | No             | Yes        |
| 302 Found (actual)       | Yes            | Yes        |
| 303 See Other            | Yes            | Yes        |
| 307 Temporary Redirect   | No             | Yes        |
| 308 Permanent Redirect   | No             | No         |

— इयान बॉयड
स्रोत

1

इसके अलावा, सर्वर व्यवस्थापक के लिए, यह नोट करना महत्वपूर्ण हो सकता है कि यदि आप 307 रीडायरेक्ट का उपयोग करते हैं तो ब्राउज़र उपयोगकर्ता के लिए एक संकेत प्रस्तुत कर सकता है।

उदाहरण के लिए *, फ़ायरफ़ॉक्स और ओपेरा उपयोगकर्ता को पुनर्निर्देशित करने की अनुमति के लिए कहेंगे, जबकि क्रोम, IE और सफारी पारदर्शी रूप से पुनर्निर्देशित करेंगे।

_{* प्रति बुलेटप्रूफ एसएसएल और टीएलएस (पृष्ठ 192)।}

— Pacerier
स्रोत

यह केवल असुरक्षित अनुरोधों जैसे POST के लिए सही है।

— जूलियन रेसके ने

0

कुछ उपयोग मामलों में, पीड़ित की साख जानने के लिए एक हमलावर द्वारा 307 रीडायरेक्ट का दुरुपयोग किया जा सकता है।

आगे की जानकारी OAuth 2.0 के एक व्यापक औपचारिक सुरक्षा विश्लेषण के खंड 3.1 में पाया जा सकता है ।

उपरोक्त पत्र के लेखक निम्नलिखित सुझाव देते हैं:

ठीक कर। OAuth मानक में वर्तमान शब्दों के विपरीत, रीडायरेक्ट की सटीक विधि एक कार्यान्वयन विवरण नहीं है, लेकिन OAuth की सुरक्षा के लिए आवश्यक है। HTTP मानक ( RFC 7231 ) में, HTTP POST अनुरोध के मुख्य भाग को छोड़ने के लिए केवल 303 रीडायरेक्ट को स्पष्ट रूप से परिभाषित किया गया है। अन्य सभी HTTP पुनर्निर्देशन स्थिति कोड, जिनमें सबसे अधिक उपयोग किया जाता है 302, ब्राउज़र को POST अनुरोध और प्रपत्र डेटा को संरक्षित करने का विकल्प छोड़ देता है। व्यवहार में, ब्राउज़र आमतौर पर एक GET अनुरोध को फिर से लिखते हैं, जिससे 307 रीडायरेक्ट को छोड़कर फॉर्म डेटा को छोड़ दिया जाता है। इसलिए, OAuth मानक को इस समस्या को ठीक करने के लिए ऊपर वर्णित चरणों के लिए 303 रीडायरेक्ट की आवश्यकता होनी चाहिए।

— एमएस डौस्ती
स्रोत