ইউআরএল টুকরা এবং 302 পুনর্নির্দেশগুলি


136

এটি সুপরিচিত যে ইউআরএল টুকরা (তার পরে অংশ #) সার্ভারে প্রেরণ করা হয়নি।

যখন কোনও সার্ভার পুনর্নির্দেশ করা হয় (HTTP স্থিতি 302 এবং Location:শিরোলেখের মাধ্যমে ) জড়িত থাকে তখন কীভাবে টুকরো টুকরাক কাজ করে তা অবাক করি I

আমার প্রশ্নটি আসলে দ্বিগুণ:

  1. যদি মূল ইউআরএলটির একটি টুকরো ( /original.php#foo) থাকে এবং এটি পুনর্নির্দেশ করা হয় /new.phpতবে মূল ইউআরএলটির খণ্ডাংশটি কি সহজেই হারিয়ে যায়? বা এটি কখনও কখনও নতুন ইউআরএলে প্রয়োগ হয়?
    নতুন ইউআরএল কি কখনও /new.php#fooএই ক্ষেত্রে থাকবে?

  2. আসল ইউআরএল নির্বিশেষে, সার্ভারটি যদি কোনও খণ্ড ( /new.php#foo) দিয়ে একটি নতুন ইউআরএলে পুনঃনির্দেশ করে তবে খণ্ডটি কী "সম্মানিত" হবে? বা সার্ভারের আসলেই খণ্ডটির সাথে কোনও ব্যবসায় হস্তক্ষেপ করছে না - এবং তাই ব্রাউজারটি কেবল এটিকে এড়িয়ে যাবেন /new.php??


1
এখানে আপনি ডাব্লু 3 সি দ্বারা নির্দিষ্ট সন্ধান করতে পারেন: w3.org/TR/cuap#uri ধারা ৪.১। পুনঃনির্দেশে টুকরোটি সংরক্ষণ করা উচিত।
মার্সিন

1
@ মার্সিন: ডাব্লু 3 সি ট্যাগ আলাদাভাবে পরামর্শ দেয়: सूেলটি.ডব্লু । সম্পর্কিত প্রশ্ন: কোনও 302 টি পুনর্নির্দেশ সম্পর্কিত URL টি বৈধ, বা অবৈধ?
হ্যাক্রে

উত্তর:


135

আপডেট 2014-জুন -27 :

আরএফসি 7231, হাইপারটেক্সট ট্রান্সফার প্রোটোকল (HTTP / 1.1): শব্দার্থক ও বিষয়বস্তু , একটি প্রোপোজড স্ট্যান্ডার্ড হিসাবে প্রকাশিত হয়েছে। চেঞ্জলগ থেকে :

অবস্থান শিরোনাম ক্ষেত্রটির বাক্য গঠনটি ইউআরআই রেফারেন্সগুলি সহ আপেক্ষিক রেফারেন্স এবং টুকরো টুকরো সহ কিছু স্পষ্টকরণের পাশাপাশি টুকরোগুলির ব্যবহার কখন উপযুক্ত হবে না সে বিষয়ে অনুমতি দেওয়ার জন্য পরিবর্তন করা হয়েছে। (বিভাগ 7.1.2)

বিভাগ 7.1.2 থেকে গুরুত্বপূর্ণ পয়েন্ট অবস্থান :

যদি 3xx (পুনর্নির্দেশ) প্রতিক্রিয়াতে প্রদত্ত অবস্থানের মানটি কোনও খণ্ড উপাদান না থাকে তবে কোনও ব্যবহারকারী এজেন্ট পুনঃনির্দেশটি প্রক্রিয়া করতে হবে যেন মানটি অনুরোধের লক্ষ্যটি উত্পন্ন করার জন্য ব্যবহৃত ইউআরআই রেফারেন্সের খণ্ড উপাদানটিকে উত্তরাধিকার সূত্রে প্রাপ্ত করে (যেমন, পুনঃনির্দেশ উত্তরাধিকার সূত্রে প্রাপ্ত হয়) মূল রেফারেন্সের টুকরা, যদি থাকে)।

উদাহরণস্বরূপ, ইউআরআই রেফারেন্সের জন্য উত্পন্ন একটি জিইটি অনুরোধ " http://www.example.org/~tim " এর ফলে 303 (অন্যান্য দেখুন) শিরোনামের ক্ষেত্রটি থাকতে পারে:

Location: /People.html#tim

যা পরামর্শ দেয় যে ব্যবহারকারী এজেন্ট " http://www.example.org/People.html#tim " এ পুনঃনির্দেশ করুন

তেমনি, ইউআরআই রেফারেন্সের জন্য উত্পন্ন একটি জিইটি অনুরোধ " http://www.example.org/index.html#larry " এর ফলে 301 (স্থায়ীভাবে স্থানান্তরিত) প্রতিক্রিয়া শিরোনাম ক্ষেত্রটি ধারণ করে:

Location: http://www.example.net/index.html

যা পরামর্শ দেয় যে ব্যবহারকারীর এজেন্টটি মূল টুকরা সনাক্তকারীকে সংরক্ষণ করে " http://www.example.net/index.html#larry " এ পুনঃনির্দেশ করে ।

এটি আপনার প্রশ্নের স্পষ্ট উত্তর দিতে হবে।

আপডেট শেষ

এটি বর্তমান এইচটিটিপি স্পেসিফিকেশন সহ একটি উন্মুক্ত (নির্দিষ্ট নেই) সমস্যা । এটি আইইটিএফ httpbis ওয়ার্কিং গ্রুপের 2 ইস্যুতে সম্বোধন করা হয়েছে :

# 6 Locationশিরোনামে টুকরো টুকরো করতে দেয় । # 43 এটি বলে:

আমি বিভিন্ন ব্রাউজারের সাহায্যে এটি পরীক্ষা করেছি।

  • ফায়ারফক্স এবং সাফারি লোকেশন শিরোনামে টুকরোটি ব্যবহার করে।
  • অপেরা ওআরআইআরটি উত্স ইউআরআই থেকে টুকরোটি ব্যবহার করে, যখন উপস্থিত থাকে অন্যথায় পুনঃনির্দেশের অবস্থান থেকে খণ্ড
  • আইআই (8) ইউআরআই অবস্থানের টুকরোটিকে উপেক্ষা করে, সুতরাং উপস্থিত ইউআরআই থেকে এই অংশটি ব্যবহার করবে

প্রস্তাব:

"দ্রষ্টব্য: মূল ইউআরআই থেকে টুকরা শনাক্তকারী এবং পুনঃনির্দেশকে একত্রিত করার প্রয়োজন হয় এমন আচরণটি অপরিজ্ঞাত; বর্তমান ব্যবহারকারী এজেন্টরা প্রকৃতপক্ষে কোন অংশকে অগ্রাধিকার দেয় তার চেয়ে আলাদা হয়।"

[...]

এটা তোলে IE8 প্রদর্শিত করে থেকে টুকরা idenfitier ব্যবহার Location(আচরণ দেখলাম স্থানীয় হোস্ট সীমাবদ্ধ হতে পারে)।

সুতরাং আমাদের কাছে সাফারি / আইই / ফায়ারফক্স / ক্রোমের (কেবলমাত্র পরীক্ষিত) জন্য ধারাবাহিক আচরণ রয়েছে বলে মনে হচ্ছে যে অবস্থানের শিরোনাম থেকে খণ্ডটি ব্যবহৃত হয়ে যায়, আসল ইউআরআই কি তা বিবেচনা না করেই।

আমি তাই দস্তাবেজে আমার প্রস্তাব পরিবর্তন যে প্রত্যাশিত আচরণ হিসাবে।

এটি আপনার ব্রাউজারের সামঞ্জস্যপূর্ণ এবং ভবিষ্যতের প্রমাণের দিকে পরিচালিত করে (কারণ এই ইস্যুটি শেষ পর্যন্ত প্রমিত হবে) আপনার প্রশ্নের উত্তর:

উত্তর: মূল ইউআরএলগুলি থেকে টুকরোগুলি বাতিল হয়ে যায়।

বি:Location শিরোনাম থেকে টুকরা সম্মানিত হয়।


1
আমি HTTP সার্ভারগুলিতে সেট করা কিছু "পুনর্লিখন" বিধি সম্পর্কে ভুলে গিয়েছিলাম, সম্ভবত 301 পুনঃনির্দেশ হিসাবে প্রয়োগ করা হয়েছিল। ফলস্বরূপ আইআই খণ্ড শনাক্তকারীকে হারাতে থাকে কারণ আপনার যখন একাধিক পুনঃনির্দেশ হয়, তখন প্রথম পুনর্নির্দেশ দ্বারা সেট করা খণ্ডগুলি দ্বিতীয়টিতে উত্স ইউআরআইর অংশ হয়ে যায় ।
ইউজিন ইয়োকোটা

অপেরা 12.12 উপস্থিত থাকাকালীন লোকেশন শিরোনামে টুকরোটিকে সম্মান করে।
ছাগল

4
ক্রোম এবং ফায়ারফক্স উভয়ের বর্তমান সংস্করণে: সত্য নয়। ফায়ারফক্সের বর্তমান সংস্করণে: বি সত্য নয়। এই মুহুর্তে, আপনার যদি হ্যাশগুলি ব্যবহার করতে হয় (যেমন, ব্যাকবোনগুলির রাউটিং ব্যবহার করে) মনে হচ্ছে জাভাস্ক্রিপ্ট-ভিত্তিক পুনর্নির্দেশই আপনার একমাত্র আসল বিকল্প।
a.real.human.being

উদ্ধৃত ব্লকটি নিজেকে বিপরীত বলে মনে হচ্ছে। প্রথমে এটি বলে যে "আইআই (8) অবস্থান ইউআরআই-তে অংশটিকে অবহেলা করে, এভাবে ইউআরআই উত্স থেকে টুকরাটি ব্যবহার করবে, যখন উপস্থিত থাকবে", পরে এটি বলে যে "আইআই 8 লোকেশন থেকে খণ্ডটি সনাক্তকারী ব্যবহার করে"। প্রথমটি কি দ্বিতীয়টির থেকে আলাদা কিছু উল্লেখ করছে?
ডেভিডটবার্নাল

বি Chome 45.0.2454.85 এর জন্য সত্য নয়। ফায়ারফক্স 40.0.3 এর ক্ষেত্রে বি সত্য B
জিংগুও ইয়াও

44

যদি কোনও HTTP / 3xx পুনঃনির্দেশ দেখা দেয় তবে সাফারি 5 এবং আই 9 এবং নীচে মূল ইউআরআইয়ের টুকরোটি ফেলে দিন। প্রতিক্রিয়াতে অবস্থান শিরোনাম যদি কোনও খণ্ডকে নির্দিষ্ট করে তবে এটি ব্যবহৃত হবে।

আইই 10 +, ক্রোম 11+, ফায়ারফক্স 4+, এবং অপেরা 3 এক্সএক্সএক্স পুনঃনির্দেশ অনুসরণ করে মূল ইউআরআইয়ের টুকরোটিকে "পুনরায় সংযুক্ত" করবে।

পরীক্ষার পৃষ্ঠা: http://www.webdbg.com/test/redir/fraament/

এই সমস্যাটির আরও আলোচনা দেখুন http://blogs.msdn.com/b/ieinternals/archive/2011/05/17/url-frations-and-redirects-anchor-hash-missing.aspx


2
আসলে IE10 এখনও সর্বশেষতম ফায়ারফক্স এবং ক্রোম সংস্করণ থেকে আলাদা আচরণ করে। কোনও সরল পুনঃনির্দেশের ক্ষেত্রে উত্স URL থেকে এই খণ্ডটি সংরক্ষণ করা হবে বলে মনে হয়। এবং যদি পুনঃনির্দেশে Locationকোনও খণ্ড থাকে তবে এটি এটি সঠিকভাবে রাখবে। কিন্তু যদি কোনও Locationখণ্ডের সাথে পুনঃনির্দেশিত যদি অন্য 3xx পুনর্নির্দেশের মধ্য দিয়ে যায় তবে এটি অনিবার্যভাবে প্রথম পুনঃনির্দেশ থেকে খণ্ডটিকে অগ্রাহ্য করবে, এটি পূর্ববর্তী 2 টি আচরণের সাথে সামঞ্জস্যপূর্ণ নয়। ক্রোম এবং ফায়ারফক্স এটি ধারাবাহিকভাবে সংরক্ষণ করে।
অদ্ভুত

আমি নিশ্চিত হয়েছি যে আপনি সঠিক বলেছেন। এই পৃষ্ঠায় চূড়ান্ত পরীক্ষার লিঙ্কটি দেখুন: webdbg.com/test/redir/fraament
এরিকলও

11

শুধু আপনাকে জানাতে, এখানে আপনি সঠিক অনুমান খুঁজে পেতে পারেন। সকলের আচরণ কী করা উচিত তা ডাব্লু 3 সি দ্বারা নির্ধারণ করে: http://www.w3.org/TR/cuap#uri - ধারা ৪.১ - নীচে দেখুন:

যখন কোনও সংস্থান (ইউআরআই 1) স্থানান্তরিত হয়, তখন একটি এইচটিটিপি পুনর্নির্দেশ তার নতুন অবস্থান (ইউআরআই 2) নির্দেশ করতে পারে।

যদি ইউআরআই 1 এর একটি খণ্ড শনাক্তকারী # ফ্র্যাগ থাকে তবে ব্যবহারকারী এজেন্ট যে নতুন টার্গেটে পৌঁছানোর চেষ্টা করা উচিত তা হবে ইউআরআই 2 # ভঙ্গুর। যদি ইউআরআই 2 এর মধ্যে ইতিমধ্যে একটি খণ্ড সনাক্তকারী রয়েছে, তবে # ফ্রেগ অবশ্যই যুক্ত করা উচিত নয় এবং নতুন লক্ষ্যটি ইউআরআই 2।

ভুল: বেশিরভাগ বর্তমান ব্যবহারকারী এজেন্টরা এইচটিটিপি পুনঃনির্দেশগুলি প্রয়োগ করে তবে নতুন ইউআরআইতে টুকরা শনাক্তকারীকে যুক্ত করে না, যা সাধারণত ব্যবহারকারীকে বিভ্রান্ত করে কারণ তারা ভুল সংস্থান দিয়ে শেষ হয়।

তথ্যসূত্র:

এইচটিটিপি পুনঃনির্দেশগুলি HTTP / 1.1 নির্দিষ্টকরণ [আরএফসি 2616] এর 10.3 বিভাগে বর্ণিত হয়েছে। প্রয়োজনীয় আচরণটি "পুনর্নির্দেশিত ইউআরএলগুলিতে টুকরা শনাক্তকারীদের পরিচালনা করা" [আরআরএল] এ বিশদে বর্ণিত হয়। "পার্সেন্ট্যান্ট ইউনিফর্ম রিসোর্স লোকেটার (পিআরএল)" শব্দটি একটি ইউআরএল (একটি ইউআরআইয়ের একটি বিশেষ কেস) নির্ধারণ করে যা এইচটিটিপি পুনর্নির্দেশের মাধ্যমে অন্যটিকে নির্দেশ করে। আরও তথ্যের জন্য, "নিয়মিত ইউনিফর্ম রিসোর্স লোকেটারগুলি" [পিআরএল] দেখুন। উদাহরণ:

মনে করুন যে কোনও ব্যবহারকারী http://www.w3.org/TR/WD-ruby/# পরিবর্তনগুলিতে সংস্থানটির অনুরোধ করে এবং সার্ভারটি ব্যবহারকারী এজেন্টকে http://www.w3.org/TR/ruby/ এ পুনঃনির্দেশ করে । এই উত্তরোত্তর ইউআরআই আনার আগে, ব্রাউজারটিকে খণ্ড শনাক্তকরণ # পরিবর্তন এতে যুক্ত করতে হবে: http://www.w3.org/TR/ruby/# পরিবর্তনসমূহ


0

সমাধান সহ অনুরূপ ইস্যু পোস্ট করাআমার সম্মুখীন ।

আশা করি এটি এর অনুরূপ প্রয়োজনীয়তার সাথে কাউকে সহায়তা করবে preserving hash in IE 302 পুনর্নির্দেশের ।

একা লিঙ্কের পরিবর্তে উত্তরের প্রয়োজনীয় অংশগুলি যুক্ত করা

আমরা ব্যাবহার করি SiteMinder আমাদের অ্যাপ্লিকেশনটিতে প্রমাণীকরণ ।

আমি মূর্ত আউট সফল প্রমাণীকরণ পর SiteMinderকরছে 302 redirectionব্যবহার করে ব্যবহারকারী অনুরোধকৃত অ্যাপ্লিকেশান পৃষ্ঠা থেকে আপনাকে লগইন ফর্ম গোপন পরিবর্তনশীলvalue (যেখানে এটা সঞ্চয় করে ব্যবহারকারী অনুরোধ করা URL /myapp/- without hash fragmentযেহেতু এটি সার্ভারে পাঠানো হবে না) অনুরূপ নাম দিয়ে redirect। নীচে নমুনা ফর্ম

নমুনা লগইন ফর্ম

যেহেতু redirectগোপন পরিবর্তনশীল মান শুধুমাত্র রয়েছে /myapp/হ্যাশ টুকরা ছাড়া এবং এটি একটি 302 পুনর্নির্দেশ এর হ্যাশ টুকরা স্বয়ংক্রিয়ভাবে এমনকি আমাদের আবেদন এবং যাই হোক না কেন সমাধান আমরা আমাদের আবেদন কোডে চেষ্টা করছেন আউট কাজ করছে না আসার আগে ইন্টারনেট দ্বারা মুছে ফেলা হবে।

আইই কেবল পুনঃনির্দেশ করছে /myapp/এবং এটি আমাদের অ্যাপ্লিকেশনের ডিফল্ট হোম পৃষ্ঠায় অবতরণ করছে https://ourapp.com/myapp/#/home

এই আচরণটি বের করতে প্রায় এক দিন নষ্ট করেছেন।

সমাধানটি হ'ল:

পরিবর্তিত হয়েছে লগইন ফর্ম গোপন পরিবর্তনশীল ( redirect) মান সংযোজন করে হ্যাশ টুকরা রাখা window.location.hashবিদ্যমান মান করেন। নীচের কোডের মতো

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

এই পরিবর্তনের পরে, redirectলুকানো ভেরিয়েবল ব্যবহারকারী হিসাবে অনুরোধ করা ইউআরএল মানটি সংরক্ষণ করছে /myapp/#/pending/requestsএবং SiteMinderএটি আইইতে পুনর্নির্দেশ করছে /myapp/#/pending/requests

উপরের সমাধানটি তিনটি ব্রাউজারে ঠিকঠাক কাজ করছে Chrome, Firefox and IE

এই সমস্যাটির বিস্তারিত ব্যাখ্যা এবং সমাধান দেওয়ার জন্য @ অ্যালেক্সফোর্ডকে ধন্যবাদ জানাই ।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.