URL फ़्रैगमेंट और 302 रीडायरेक्ट

136

यह अच्छी तरह से ज्ञात है कि URL टुकड़ा (के बाद का हिस्सा #) सर्वर पर नहीं भेजा जाता है।

मुझे आश्चर्य है कि जब सर्वर पुनर्निर्देशित होता है (HTTP स्थिति 302 और Location:शीर्ष लेख के माध्यम से ) तो कैसे काम करता है।

मेरा प्रश्न वास्तव में दो-गुना है:

यदि मूल URL में एक टुकड़ा ( /original.php#foo) था, और पुनर्निर्देशित किया जाता है /new.php, तो मूल URL का टुकड़ा भाग बस खो जाता है? या क्या यह कभी-कभी नए URL पर लागू होता है?
क्या नया URL /new.php#fooइस मामले में कभी आएगा ?
मूल URL के बावजूद, यदि सर्वर एक खंड ( /new.php#foo) के साथ एक नए URL पर पुनर्निर्देशित करता है, तो क्या टुकड़ा "सम्मानित" हो जाएगा? या क्या सर्वर में वास्तव में टुकड़े के साथ हस्तक्षेप करने वाला कोई व्यवसाय नहीं है - और क्या ब्राउज़र केवल इसलिए इसे अनदेखा करेगा /new.php??

redirect fragment-identifier http-redirect

— levik
स्रोत

1

यहां आप W3C: w3.org/TR/cuap#uri क्लॉज 4.1 द्वारा कल्पना पा सकते हैं । टुकड़े को पुनर्निर्देशित पर संरक्षित किया जाना चाहिए।

— मार्सिन

1

@Marcin: W3C TAG अलग से सुझाव देते हैं: lists.w3.org/Archives/Public/ietf-http-wg/2010OctDec/0504.html । संबंधित प्रश्न: क्या एक 302 पुनर्निर्देशन सापेक्ष URL के लिए वैध है, या अमान्य है?

— हकर्रे

135

अद्यतन 2014-जून -27 :

RFC 7231, हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल (HTTP / 1.1): शब्दार्थ और सामग्री , एक प्रमाणित मानक के रूप में प्रकाशित किया गया है। से चैंज :

स्थान के हेडर फ़ील्ड के सिंटैक्स को सभी यूआरआई संदर्भों की अनुमति देने के लिए बदल दिया गया है, जिसमें सापेक्ष संदर्भ और टुकड़े शामिल हैं, साथ ही कुछ स्पष्टीकरण भी हैं जब टुकड़ों का उपयोग उचित नहीं होगा। (धारा 7.1.2)

धारा 7.1.2 से महत्वपूर्ण बिंदु । स्थान :

यदि 3xx (पुनर्निर्देशन) प्रतिसाद में दिए गए स्थान मान में एक खंड घटक नहीं है, तो एक उपयोगकर्ता एजेंट जरूरी पुनर्निर्देशन की प्रक्रिया करता है जैसे कि मान अनुरोध लक्ष्य को उत्पन्न करने के लिए उपयोग किए गए URI संदर्भ के टुकड़े घटक को विरासत में मिला है (यानी, पुनर्निर्देशन विरासत में मिला है मूल संदर्भ का टुकड़ा, यदि कोई हो)।

उदाहरण के लिए, URI संदर्भ " http://www.example.org/~tim " के लिए जनरेट किया गया अनुरोध 303 हो सकता है (हेडर फ़ील्ड वाले अन्य) प्रतिक्रिया देखें:
Location: /People.html#tim
जो सुझाव देता है कि उपयोगकर्ता एजेंट " http://www.example.org/People.html#tim " पर पुनर्निर्देशित करता है

इसी तरह, URI संदर्भ " http://www.example.org/index.html#larry " के लिए उत्पन्न एक GET अनुरोध हेडर फ़ील्ड से युक्त 301 (स्थानांतरित स्थायी रूप से) प्रतिक्रिया हो सकती है:
Location: http://www.example.net/index.html
जिससे पता चलता है कि उपयोगकर्ता एजेंट " http://www.example.net/index.html#larry " पर पुनर्निर्देशित करता है , जो मूल टुकड़ा पहचानकर्ता को संरक्षित करता है।

यह स्पष्ट रूप से आपके सवालों का जवाब देना चाहिए।

अद्यतन करें END

यह वर्तमान HTTP विनिर्देशन के साथ एक खुला (निर्दिष्ट नहीं) मुद्दा है । इसे IETF httpbis वर्किंग ग्रुप के 2 मुद्दों में संबोधित किया गया है :

# 6 Locationहेडर में टुकड़े की अनुमति देता है । # 43 यह कहते हैं:

मैंने अभी विभिन्न ब्राउज़रों के साथ इसका परीक्षण किया है।

फ़ायरफ़ॉक्स और सफारी स्थान हेडर में टुकड़े का उपयोग करें।

ओपेरा स्रोत का टुकड़ा URI से उपयोग करता है, जब मौजूद होता है, अन्यथा अनुप्रेषित स्थान से खंड

IE (8) स्थान यूआरआई में टुकड़े की उपेक्षा करता है, इस प्रकार स्रोत यूआरआई से टुकड़े का उपयोग करेगा, जब मौजूद होगा

प्रस्ताव:

"नोट: व्यवहार जब मूल URI से टुकड़े की पहचान करता है और पुनर्निर्देशित की आवश्यकता संयुक्त है अपरिभाषित है; वर्तमान उपयोगकर्ता एजेंटों वास्तव में क्या टुकड़ा पूर्वता लेता है पर अलग है।"

[...]

ऐसा प्रतीत होता है कि IE8 खंड idenfitier का उपयोग करता है Location(जो व्यवहार मैंने देखा वह स्थानीयहोस्ट तक सीमित हो सकता है)।

इस प्रकार हम सफारी / IE / फ़ायरफ़ॉक्स / क्रोम (बस परीक्षण) के लिए लगातार व्यवहार करते हैं, इसमें लोकेशन हेडर से टुकड़े का उपयोग किया जाता है, कोई फर्क नहीं पड़ता कि मूल यूआरआई क्या था।

इसलिए मैं दस्तावेज़ में मेरे प्रस्ताव को बदलने कि अपेक्षित व्यवहार के रूप में।

यह आपके प्रश्न के उत्तर में सबसे अधिक ब्राउज़र संगत और भविष्य के प्रमाण की ओर जाता है (क्योंकि यह समस्या अंततः मानकीकृत हो जाएगी):

A: मूल URL के टुकड़े छूट जाते हैं।

बी:Location हेडर से टुकड़े सम्मानित किए जाते हैं।

— कुल्हाड़ी।
स्रोत

1

मैं HTTP सर्वर में सेट किए गए कुछ "रीराइट" नियमों के बारे में भूल गया था, जिन्हें संभवतः 301 रीडायरेक्ट के रूप में लागू किया गया था। परिणामस्वरूप IE ने खंड पहचानकर्ता को खोना जारी रखा क्योंकि जब आपके पास कई रीडायरेक्ट होते हैं, तो पहले रीडायरेक्ट द्वारा सेट किए गए टुकड़े दूसरे में स्रोत यूआरआई का हिस्सा बन जाते हैं ।

— यूजीन योकोटा

ओपेरा 12.12 लोकेशन हेडर में मौजूद होने पर उसके टुकड़े को सम्मानित करता है।

— बकरीद

4

क्रोम और फ़ायरफ़ॉक्स दोनों के वर्तमान संस्करणों पर: A सत्य नहीं है। फ़ायरफ़ॉक्स के वर्तमान संस्करण पर: बी सच नहीं है। फिलहाल, यदि आपको हैश का उपयोग करना है (जैसे, बैकबोन की राउटिंग का उपयोग करके) तो ऐसा लगता है कि जावास्क्रिप्ट-आधारित रीडायरेक्शन आपका एकमात्र वास्तविक विकल्प है।

— a.real.human.being

उद्धृत खंड अपने आप में विरोधाभास लगता है। पहले यह कहता है कि "IE (8) स्थान URI में टुकड़े की उपेक्षा करता है, इस प्रकार स्रोत URI के टुकड़े का उपयोग करेगा, जब वर्तमान", तो बाद में यह कहता है कि "ऐसा प्रतीत होता है कि IE8 स्थान से पहचानकर्ता का उपयोग करता है"। क्या पहले का जिक्र दूसरे से कुछ अलग है?

— दाविदबरबल

B, Chome 45.0.2454.85 के लिए सही नहीं है। B फ़ायरफ़ॉक्स 40.0.3 के लिए सही है।

— जिंगुओ याओ

44

एक HTTP / 3xx पुनर्निर्देशित होने पर सफारी 5 और IE9 और नीचे मूल URI के टुकड़े को गिरा देता है। यदि प्रतिक्रिया पर स्थान शीर्षलेख एक खंड निर्दिष्ट करता है, तो इसका उपयोग किया जाता है।

IE10 +, क्रोम 11+, फ़ायरफ़ॉक्स 4+, और ऑपेरा 3xx पुनर्निर्देशन का पालन करने के बाद मूल यूआरआई के टुकड़े को "रीटेट" करेगा।

टेस्ट पेज: http://www.webdbg.com/test/redir/fragment/ ।

इस मुद्दे की और चर्चा देखें http://blogs.msdn.com/b/ieinternals/archive/2011/05/17/url-fragments-and-redirects-anchor-hash-missing.aspx

— EricLaw
स्रोत

2

वास्तव में IE10 अभी भी नवीनतम फ़ायरफ़ॉक्स और क्रोम संस्करणों से अलग तरह से व्यवहार करता है। यह एक साधारण पुनर्निर्देशन के मामले में स्रोत URL से टुकड़े को संरक्षित करने के लिए प्रतीत होता है। और अगर पुनर्निर्देशन Locationमें एक टुकड़ा होता है, तो यह इसे सही ढंग से रखेगा। लेकिन अगर एक Locationखंड के साथ पुनर्निर्देशित एक और 3xx पुनर्निर्देशित के माध्यम से चला जाता है, तो यह अनावश्यक रूप से पहले पुनर्निर्देशन से टुकड़े की अनदेखी करेगा, जो 2 पिछले व्यवहारों के अनुरूप नहीं है। क्रोम और फ़ायरफ़ॉक्स लगातार इसे संरक्षित करते हैं।

— ओडोनी

मैंने पुष्टि की है कि आप सही हैं। इस पृष्ठ पर अंतिम परीक्षा लिंक देखें: webdbg.com/test/redir/fragment

— EricLaw

11

बस आपको पता करने के लिए, यहाँ आप उचित युक्ति पा सकते हैं। w3c को परिभाषित करते हुए कि सभी को कैसे व्यवहार करना चाहिए: http://www.w3.org/TR/cuap#uri - खंड 4.1 - नीचे देखें:

जब कोई संसाधन (URI1) स्थानांतरित हो गया है, तो एक HTTP पुनर्निर्देशित अपना नया स्थान (URI2) इंगित कर सकता है।

यदि URI1 में एक टुकड़ा पहचानकर्ता #frag है, तो उपयोगकर्ता एजेंट को पहुंचने का प्रयास करने वाला नया लक्ष्य URI2 # सुगंध होगा। यदि URI2 में पहले से ही एक टुकड़ा पहचानकर्ता है, तो #frag को जोड़ा नहीं जाना चाहिए और नया लक्ष्य URI2 है।

गलत: अधिकांश वर्तमान उपयोगकर्ता एजेंट HTTP पुनर्निर्देशन को लागू करते हैं लेकिन नए URI के लिए खंड पहचानकर्ता को नहीं जोड़ते हैं, जो आम तौर पर उपयोगकर्ता को भ्रमित करता है क्योंकि वे गलत संसाधन के साथ समाप्त होते हैं।

संदर्भ:

HTTP पुनर्निर्देशन HTTP / 1.1 विनिर्देशन [RFC2616] की धारा 10.3 में वर्णित है। आवश्यक व्यवहार "पुनर्निर्देशित URL में टुकड़ा पहचानकर्ताओं से निपटने" [RURL] में विस्तार से वर्णित है। "परसेंट यूनिफ़ॉर्म रिसोर्स लोकेटर (PURL)" शब्द एक URL (एक यूआरआई का एक विशेष मामला) को डिज़ाइन करता है जो HTTP रीडायरेक्ट के माध्यम से दूसरे को इंगित करता है। अधिक जानकारी के लिए, "स्थायी यूनिफ़ॉर्म रिसोर्स लोकेटर" [PURL] देखें। उदाहरण:

मान लीजिए कि एक उपयोगकर्ता संसाधन का अनुरोध करता है http://www.w3.org/TR/WD-ruby/#changes और सर्वर उपयोगकर्ता एजेंट को http://www.w3.org/TR/ruby/ पर पुनर्निर्देशित करता है । उस बाद वाले URI को लाने से पहले, ब्राउज़र को खंड पहचानकर्ता को # इस पर भेजना चाहिए: http://www.w3.org/TR/ruby/#changes ।

— मार्सिन
स्रोत

0

समाधान के साथ इसी तरह की समस्या पोस्ट करनामेरे द्वारा प्रस्तुत करना।

आशा है कि यह समान आवश्यकता वाले किसी व्यक्ति की मदद करता है preserving hash in IE 302 रीडायरेक्ट ।

अकेले लिंक के बजाय उत्तर के आवश्यक भागों को जोड़ना

हम प्रयोग करते हैं SiteMinder अपने आवेदन में प्रमाणीकरण का करते हैं।

मुझे पता चला कि सफल प्रमाणीकरण के बाद, लॉगिन फ़ॉर्म हिडन चर (जहां यह उपयोगकर्ता द्वारा अनुरोधित URL को संग्रहीत करता है - चूंकि इसे सर्वर पर नहीं भेजा जाएगा) के समान नाम के साथ उपयोग करके आवेदन पृष्ठ का अनुरोध उपयोगकर्ता SiteMinderसे कर रहा है । नीचे नमूना फार्म302 redirectionvalue/myapp/without hash fragmentredirect

redirectछिपे हुए चर मूल्य के बाद से में केवल /myapp/हैश टुकड़ा के बिना होता है और यह 302 रीडायरेक्ट होता है, हैश टुकड़ा हमारे आवेदन में आने से पहले भी IE द्वारा स्वचालित रूप से हटा दिया जाता है और जो भी समाधान हम अपने आवेदन कोड में आज़मा रहे हैं, वह काम नहीं कर रहा है।

IE को पुनर्निर्देशित किया जा रहा है /myapp/ केवल और यह हमारे ऐप के डिफ़ॉल्ट होम पेज पर उतर रहा है https://ourapp.com/myapp/#/home।

इस व्यवहार का पता लगाने के लिए लगभग एक दिन बर्बाद किया है।

समाधान है:

मौजूदा मूल्य के साथ जोड़कर हैश के टुकड़े को पकड़ने के लिए लॉगिन फ़ॉर्म छिपे हुए चर ( redirect) मान को बदल दिया है window.location.hash। नीचे दिए गए कोड के समान

$(function () {
  var $redirect = $('input[name="redirect"]');
  $redirect.val($redirect.val() + window.location.hash);
});

इस परिवर्तन के बाद, redirectछिपे हुए चर उपयोगकर्ता द्वारा अनुरोधित URL मान को संग्रहीत कर रहा है /myapp/#/pending/requestsऔर SiteMinderइसे /myapp/#/pending/requestsIE में पुनर्निर्देशित कर रहा है।

उपरोक्त समाधान तीनों ब्राउज़रों में ठीक काम कर रहा है Chrome, Firefox and IE।

विस्तृत विवरण और इस समस्या के समाधान के लिए @AlexFord का धन्यवाद ।

— प्रताप रेड्डी
स्रोत