HTTP रीडायरेक्ट

यह क्यों ज़रूरी है

Redirects अहम रास्तों पर होते हैं: HTTP से HTTPS, redesign के बाद पुराने links, login और logout, payment से वापसी, API version बदलना। कोई redirect गलत हो तो लक्षण उलझाने वाले होते हैं: form का data खो जाना क्योंकि POST, GET बन गया; ऐसा page जो browser के हार मानने तक redirect करता रहे; पुराने links जो 404 पर ख़त्म हों; या गलत permanent redirect जिसे browser fix के बाद भी follow करता रहे, क्योंकि उसने उसे cache कर लिया।

Redirects security का विषय भी हैं: जो application किसी parameter में आए किसी भी URL पर redirect करता है, वह किसी को भी आपके भरोसेमंद domain पर ऐसा link बनाने देता है जो phishing page पर पहुँचाए। Browser redirects चुपचाप follow करता है, इसलिए ये defects तब तक छिपे रहते हैं जब तक tester हर hop न देखे।

पाँच codes, दो सवाल

RFC 9110 redirect codes परिभाषित करता है। Permanent (301, 308) का मतलब है कि resource को नया permanent URL मिल गया है और आगे के सभी references उसी को इस्तेमाल करें: search engines और दूसरे crawlers अपने links उस पर update कर लेते हैं, और caches redirect को caching headers के बिना भी store कर सकते हैं। Temporary (302, 307) का मतलब है original URL valid रहता है। 303 दोनों में से कोई नहीं: यह ऐसे दूसरे resource की ओर इशारा करता है जिसमें इस request का जवाब है। Temporary codes और 303 सिर्फ़ तभी cache होते हैं जब caching headers इसकी अनुमति दें।

Method के बारे में RFC 9110 कहता है कि ऐतिहासिक कारणों से client 301 या 302 follow करते समय POST को GET में बदल सकता है, और browsers Fetch Standard के तहत यही करते हैं, body हटाकर। 307 और 308 इसकी इजाज़त नहीं देते: client को वही method उसी body के साथ दोहराना होता है।

• 301 Moved Permanently: permanent; POST, GET बन सकता है। हमेशा के लिए move हुए pages के लिए।
• 302 Found: temporary; POST, GET बन सकता है। छोटे detour के लिए, जैसे login page पर भेजना।
• 303 See Other: अगली request GET होती है (HEAD, HEAD ही रहता है)। Form POST के बाद result page के लिए (Post/Redirect/Get), ताकि refresh करने पर form दोबारा submit न हो।
• 307 Temporary Redirect: temporary; method और body वही रहते हैं। POST endpoint के temporary move के लिए।
• 308 Permanent Redirect: permanent; method और body वही रहते हैं। हमेशा के लिए move हुए API endpoint के लिए।
• 304 Not Modified भी 3xx code है, पर यह client को किसी नए URL पर नहीं भेजता: इसमें Location नहीं होता, और यह conditional request के बाद client से अपनी cached copy दोबारा इस्तेमाल करने को कहता है (RFC 9110 इसे पहले से stored result पर redirection कहता है), जैसा caching वाले lesson में देखा।

आज़माएँ: HTTP स्टेटस कोड लुकअप

Worked example: redirect में खोया order

यह defect आप HTTP status codes वाली exercise में row R8 के रूप में देख चुके हैं: ऐप ने 301 को GET से follow किया और chain एक भ्रामक 200 पर ख़त्म हुई। यहाँ देखें कि browser में यह एक-एक hop पर कैसा दिखता है। एक web shop अपनी order API को /api/v1/orders से /api/v2/orders पर ले जाता है और customers के browsers में अभी भी खुले pages के लिए पुराने path से 301 जोड़ देता है। फिर वे customers "Place order" दबाते हैं और "Something went wrong" देखते हैं। DevTools में "Preserve log" चालू करने पर Network panel एक click के लिए दो requests दिखाता है (इस section के अंत का trace)।

Browser ने 301 को वैसे follow किया जैसा Fetch Standard POST के लिए कहता है: उसने body के बिना GET भेजा, और page ने सिर्फ़ आख़िरी 405 देखा। Bug report दोनों hops लिखती है और संभावित कारण बताती है: 308 की जगह 301। Fix के बाद confirmation test जाँचता है कि POST अपनी body के साथ v2 तक पहुँचे, 201 Created लौटाए और ठीक एक order बने।

Browser के बाहर, curl -i redirect response ख़ुद दिखाता है, क्योंकि curl redirects सिर्फ़ -L के साथ follow करता है; Redirect Checker किसी public URL का हर hop दिखाता है, और हर hop GET से request करता है। हर redirect में जाँचें:

• Status: requirement को जो exact code चाहिए, सिर्फ़ कोई भी 3xx नहीं।
• Location: सही target, https पर, ज़रूरत हो तो path और query string बनाए रखते हुए (/old?id=7 → /new?id=7)।
• Hops: जितने कम हो सकें, बेहतर हो तो एक।
• End: अपेक्षित page या resource, 404 या login page नहीं।
• Method और body: redirected POST के बाद असल में क्या पहुँचा।

--- request 1 (the click) ---
POST /api/v1/orders HTTP/1.1
Host: shop.example.com
Content-Type: application/json

{"sku":"A-100","qty":2}

HTTP/1.1 301 Moved Permanently
Location: /api/v2/orders

--- request 2 (sent by the browser: method changed, body dropped) ---
GET /api/v2/orders HTTP/1.1
Host: shop.example.com

HTTP/1.1 405 Method Not Allowed
Allow: POST

आज़माएँ: cURL जनरेटर आज़माएँ: HTTP हेडर पार्सर

Redirect chains और loops

Redirect chain लगातार कई redirects हैं: http://example.com/shoes → https://example.com/shoes → https://www.example.com/shoes → https://www.example.com/shoes/। हर hop एक extra round trip है और एक और rule जो टूट सकता है। Chains परतों में बढ़ती हैं: load balancer HTTPS पर upgrade करता है, web server www जोड़ता है, application trailing slash जोड़ता है। इसकी जगह हर पुराना URL सीधे अपने final address पर भेजें।

Redirect loop ऐसी chain है जो कभी ख़त्म नहीं होती। Browsers हार मान लेते हैं (Fetch Standard 20 redirects पर रुक जाता है) और Chrome में ERR_TOO_MANY_REDIRECTS जैसा error दिखाते हैं। Loops दो ऐसे components से बनते हैं जो आपस में असहमत हों:

• Proxy या load balancer request HTTPS पर लेता है पर application को plain HTTP पर आगे भेजता है; application भी HTTPS ज़रूरी करता है, उसे HTTP दिखता है और वह हर request पर फिर उसी https address पर redirect कर देता है।
• Web server trailing slash जोड़ता है और application उसे हटा देता है।
• Login page signed-in users को dashboard पर भेजता है, और dashboard जिन्हें signed-out मानता है उन्हें वापस login पर भेजता है, जैसे इसलिए कि session cookie किसी दूसरे domain या path के लिए set हुई थी।

आज़माएँ: रीडायरेक्ट चेकर

Open redirect का जोखिम

कई applications request से लिए गए URL पर redirect करते हैं: login के बाद ?next=/orders/15 user को उस page पर लौटाता है जो वह चाहता था। अगर कोई भी value मान ली जाए, तो https://shop.example.com/login?next=https://example.org/ users को आपके भरोसेमंद domain से किसी भी site पर भेज देता है। यह open redirect है, जिसे unvalidated redirect भी कहते हैं, और attackers इसे phishing में इस्तेमाल करते हैं क्योंकि link आपके असली domain से शुरू होता है।

Unvalidated redirects पर OWASP cheat sheet सलाह देती है कि user के दिए targets से बचें, server पर रखे URL से एक छोटी id map करें, या target को allow-list से जाँचें। सिर्फ़ वही systems टेस्ट करें जो आपके हों या जिनकी लिखित अनुमति हो, test environment में, और बाहरी target के रूप में reserved domain example.org रखें। नीचे की हर value parameter में आज़माएँ; expected result हमेशा आपकी अपनी site का कोई page या safe default है।

• Absolute URL: https://example.org/।
• Protocol-relative URL, जिसे browser बाहरी मानता है: //example.org/।
• आपके domain से शुरू होने वाला lookalike: https://shop.example.com.example.org/।
• @ से पहले user info के रूप में आपका domain, जो फिर भी example.org पर ले जाता है: https://shop.example.com@example.org/।
• दूसरी जगहें: returnUrl या redirect जैसे parameters, logout और payment-return pages।

आज़माएँ: URL पार्सर

अक्सर पूछे जाने वाले सवाल

संदर्भ

• RFC 9110: HTTP SemanticsIETF · 2022HTTP मेथड, हेडर फ़ील्ड, स्टेटस कोड और कंटेंट निगोशिएशन के अर्थ, वायर वर्ज़न से स्वतंत्र।
• Fetch StandardWHATWGCORS को परिभाषित करता है: प्रीफ़्लाइट रिक्वेस्ट, Access-Control-* हेडर और कौन-से रिस्पॉन्स ब्राउज़र पेज को दिखा सकता है।
• OWASP Cheat Sheet Series: Unvalidated Redirects and ForwardsOWASP FoundationOpen redirects: redirect का गंतव्य उपयोगकर्ता के input से क्यों नहीं आना चाहिए, और बचाव — server पर identifiers को URLs से जोड़ना, allow-lists और पुष्टि पेज।
• Redirections in HTTP — MDNMDN Web Docs (Mozilla)HTTP redirects: Location header के साथ 3xx status codes, स्थायी (301, 308) बनाम अस्थायी (302, 303, 307), और redirect loops कैसे बनते हैं।