HTTP এর কেন POST পুনর্নির্দেশ হয় না?

162

এইচটিটিপি পুনঃনির্দেশগুলি HTTP কোড 301, এবং 302 (সম্ভবত অন্যান্য কোডগুলিও) এবং "অবস্থান" নামে পরিচিত একটি শিরোলেখ ক্ষেত্রের মাধ্যমে করা হয় যেখানে যেতে নতুন জায়গার ঠিকানা রয়েছে। তবে, ব্রাউজারগুলি সর্বদা সেই URL এ "GET" অনুরোধ প্রেরণ করে।

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

web-development web-applications http

— সা Saeedদ নেমতি
সূত্র

স্থিতি কোড 307 আপনি যা খুঁজছেন তা কি? আমার উত্তর নীচে দেখুন।

— ডেভিড রত্তকা

উত্তর:

180

HTTP 1.1 এ আসলে একটি স্থিতি কোড রয়েছে ( 307 ) যা অনুরোধ করে যে অনুরোধটি একই পদ্ধতি এবং পোস্ট ডেটা ব্যবহার করে পুনরাবৃত্তি করা উচিত ।

অন্যরা যেমন বলেছে, এখানে অপব্যবহারের সম্ভাবনা রয়েছে যার কারণেই অনেকগুলি ফ্রেমওয়ার্কগুলি তার বিমূর্ততায় 301 এবং 302 তে লেগে থাকে। তবে সঠিক বোঝাপড়া এবং দায়বদ্ধ ব্যবহারের সাথে আপনি যা সন্ধান করছেন তা অর্জন করতে সক্ষম হবেন।

মনে রাখবেন যে, অনুযায়ী W3.org বৈশিষ্ট , যখন METHODনয় HEADবা GET, ব্যবহারকারী এজেন্ট ব্যবহারকারী চটপট উচিত নতুন অবস্থানে অনুরোধ পুনরায় চালানোর আগে। এছাড়াও আপনি উচিত একটি নোট এবং একটি ফলব্যাক প্রক্রিয়া প্রদান ক্ষেত্রে ব্যবহারকারীর জন্য পুরাতন ব্যবহারকারী এজেন্ট একটি 307 নিয়ে কী করবেন নিশ্চিত নয়।

এই ফর্মটি ব্যবহার করে:

<form action="Test307.aspx" method="post">
    <input type="hidden" name="test" value="the test" />
    <input type="submit" value="test" />    
</form>

এবং টেস্ট 307.aspx থাকার পরে কেবল 307 অবস্থানের সাথে ফিরে আসে: http://google.com , ক্রোম 13 এবং ফিডলার নিশ্চিত করে যে "পরীক্ষা = পরীক্ষা" গুগলে পোস্ট হয়েছে। অবশ্যই পরবর্তী প্রতিক্রিয়া একটি 405, যেহেতু গুগল পোস্টের অনুমতি দেয় না, তবে এটি মেকানিক্স দেখায়।

আরও তথ্যের জন্য দেখুন HTTP স্থিতি কোডের তালিকা এবং W3.org বৈশিষ্ট ।

307 অস্থায়ী পুনঃনির্দেশ (যেহেতু HTTP / 1.1) এই উপলক্ষে, অনুরোধটি অন্য ইউআরআইয়ের সাথে পুনরাবৃত্তি করা উচিত, তবে ভবিষ্যতের অনুরোধগুলি এখনও মূল ইউআরআই ব্যবহার করতে পারে। 2 303 এর বিপরীতে, মূল অনুরোধটি পুনরায় প্রকাশ করার সময় অনুরোধের পদ্ধতিটি পরিবর্তন করা উচিত নয়। উদাহরণস্বরূপ, একটি POST অনুরোধটি অন্য একটি POST অনুরোধ ব্যবহার করে পুনরাবৃত্তি করতে হবে।

— ডেভিড রটকা
সূত্র

@ ডেভিডরট্টকা, বুনো ব্রাউজার সমর্থন কি ?

— পেসারিয়ার

@ ডেভিডরট্টকা আপনি নিজের উত্তরটি আরএফসি 7231 অ্যাকাউন্টে গ্রহণ করার জন্য আপডেট করতে চান (আরফসি 2616 অপ্রচলিত)। ব্যবহারকারীকে প্রম্পট করা rfc2616 এ একটি প্রয়োজনীয়তার উপর ভিত্তি করে। এই প্রয়োজনীয়তাটি আরএফসি 7231 এ ফেলে দেওয়া হয়েছে এবং আরএফসি 7231 এছাড়াও প্রয়োজনীয়তার পরিচয় দেয় যে 307 পুনর্নির্দেশগুলি অবশ্যই অনুরোধের পদ্ধতিটি পরিবর্তন করতে হবে না (যা আপনি আপনার উক্তির উত্তরটির শেষে উল্লেখ করেছেন)।

— নিবারিয়াস

মনে রাখবেন যে, অনুযায়ী tools.ietf.org/id/draft-hunt-http-rest-redirect-00.html "HTTP- র ফেরৎ কোড 301-306 ব্যবহার করা উচিত নয় যদি না পরিষেবা প্রদানকারীর সচেতন ক্লায়েন্ট আসলে একটি user- হয় এজেন্ট "সুতরাং মনে হচ্ছে রিস্টাল সেবাটি 301 এর পরিবর্তে 308 ব্যবহার করা উচিত However তবে এটি কেবল একটি খসড়া।

— ব্রুস অ্যাডামস

আমি এখানে এই পৃষ্ঠায় একটি ভাল ব্যাখ্যা পেয়েছি ।

ডাব্লুডাব্লুডাব্লুতে সহজ পরিস্থিতিগুলি হ'ল "আইডেম্পোটেন্ট" লেনদেন, যার অর্থ কোনও ক্ষতি না করেই পুনরাবৃত্তি করা যেতে পারে। এগুলি সাধারণত "জিইটি" লেনদেন হয়, কারণ তারা সরাসরি ইউআরএল রেফারেন্সগুলি (যেমন href = বা src = বৈশিষ্ট্যগুলিতে এইচটিএমএল মধ্যে বৈশিষ্ট্য) পুনরুদ্ধার, বা কারণ তারা GET পদ্ধতি ব্যবহার করে ফর্ম জমা দেওয়া হয়। এই জাতীয় লেনদেনের পুনর্নির্দেশ সোজা হয় এবং কোনও প্রশ্ন জিজ্ঞাসা করা হয়নি: ক্লায়েন্ট একটি অবস্থান: নতুন ইউআরএল নির্দিষ্ট করে এমন শিরোনাম পুনঃনির্দেশ প্রতিক্রিয়া গ্রহণ করে এবং ক্লায়েন্ট নতুন ইউআরএলে লেনদেনটিকে পুনরায় ইস্যু করে তাতে প্রতিক্রিয়া জানায়। তাদের নির্দেশিত ক্যাশেবিলিটিগুলিতে এই পুনর্নির্দেশগুলির সাথে যুক্ত বিভিন্ন 30x স্থিতির কোডের মধ্যে পার্থক্য রয়েছে, তবে অন্যথায় তারা জিইটি অনুরোধের প্রতিক্রিয়ায় মূলত একই রকম (301 এবং 302)।

নীতিগতভাবে, নন-আদর্শবান (যেমন পিজ্জার অর্ডার দেওয়া, ভোটদান করা বা কোনও কিছু দেওয়া) হিসাবে পোষ্ট লেনদেনগুলি আলাদা, কারণ এগুলি নির্বিচারে পুনরাবৃত্তি করা উচিত নয়।

এই পার্থক্যটি বিবেচনায় নেওয়ার জন্য এইচটিটিপি প্রোটোকল স্পেসিফিকেশনগুলি তৈরি করা হয়েছে: জিইটি পদ্ধতিটি অন্তর্নিহিত আদর্শবান হিসাবে সংজ্ঞায়িত করা হয়েছে, যেখানে পিওএসটি পদ্ধতিটি কমপক্ষে সম্ভাব্য, নন-আদর্শবান হিসাবে সংজ্ঞায়িত হয়েছে; স্পেসিফিকেশনগুলিতে ক্লায়েন্ট এজেন্টদের (যেমন ব্রাউজারগুলি) অনাচ্ছাকৃতভাবে ব্যবহারকারীদের সুরক্ষা দেওয়ার জন্য তাদের অনেকগুলি সাবধানতা অবলম্বন করার আহ্বান জানানো হয়েছে (পুনরায়) কোনও পোষ্ট লেনদেন যা তারা ইচ্ছা করেনি সেগুলি জমা দেয়, বা কোনও পোস্টে তারা চান না এমন প্রসঙ্গে জমা দিতে পারে ।

যদিও আমি তাদের প্রযুক্তিগতভাবে ব্যবহারকারীদের অনাকাঙ্ক্ষিত মারামারি সৃষ্টি করতে বা তাদের অ্যাপ্লিকেশনগুলিতে অযাচিত ক্ষতি করতে বাধা দেওয়ার জন্য প্রযুক্তিগতভাবে সীমাবদ্ধ রাখার অনুরাগী নই, আমি বিষয়টি বুঝতে পারি এবং এটি উপলব্ধি করে।

— বাজপাখি
সূত্র

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

— zzzzBov

@ ফ্যালকন, "দর্শনার্থী কাউন্টার" বৃদ্ধি করা কি আদর্শহীন হিসাবে বিবেচিত হবে? যদি তা হয় তবে আজকাল প্রায় কোনও ওয়েবসাইটই

— আদর্শবানী জিইটিগুলি করে

@ পেসারিয়র: সাধারণত আদর্শবানকে "অর্থবহ উপায়ে আদর্শবান" হিসাবে ব্যাখ্যা করা হয়, উদাহরণস্বরূপ, একই জিনিস দুটিবার কেনা, দুটি দর্শন আটকে না রেখে। অন্যথায়, আপনি বেশ সঠিক হতে চাই। তবে প্রকৃতপক্ষে, চশমাটির প্রয়োজন অনুযায়ী সার্ভারগুলি অর্থপূর্ণভাবে আদর্শবান হওয়া উচিত, যেমন অনুলিপি প্রতিরোধের জন্য পৃষ্ঠাতে কোনও আইডি এম্বেড করা - ব্যবহারকারীকে কোনও প্রশ্ন জিজ্ঞাসা করার জন্য ব্রাউজারের প্রয়োজন হয় না, যাতে তাদের কোনও নির্ভুলতার সাথে উত্তর দেওয়ার উপায় নেই। নির্বিশেষে, একটি POST পুনর্নির্দেশ প্রতিরোধ আইডেম্পোটেন্সি প্রভাবিত করে না; এটি কেবল একটি বার্তা যা অনুরোধের লক্ষ্যটি সেখানে আসলে শেষ over

— লরেন্স ডল

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

— বি

@ ফ্ল্যাঙ্কন, আমার প্রমাণ দরকার যে পোষ্টের সাথে পুনঃনির্দেশকে সীমাবদ্ধ করা যে কোনও ক্ষেত্রে মারামারি রোধ করতে পারে। যেহেতু আমাকে প্রথমে আমার ডেটা সহ অ্যাপ্লিকেশনটিতে বিশ্বাস করতে হবে, তারা যখনই ডেটা পেয়েছে তখন তারা এটিকে যা করতে চাইবে তা করতে পারে। এবং আমি মনে করি না যে পুনঃনির্দেশগুলি পোষ্টের সাথে অনুরোধের চেয়ে বেশি দুর্বল।

— বি

জিইটি (এবং কয়েকটি অন্যান্য পদ্ধতি) এইচটিপি স্পেকে ( আরএফসি 2616 ) 'নিরাপদ' হিসাবে সংজ্ঞায়িত করা হয়েছে :

9.1.1 নিরাপদ পদ্ধতি

প্রয়োগকারীদের সচেতন হওয়া উচিত যে সফ্টওয়্যারটি ইন্টারনেটের মাধ্যমে তাদের ইন্টারঅ্যাকশনগুলিতে ব্যবহারকারীকে উপস্থাপন করে এবং তাদের নিজেরাই বা অন্যের কাছে অপ্রত্যাশিত তাত্পর্যপূর্ণ হতে পারে এমন কোনও পদক্ষেপ সম্পর্কে ব্যবহারকারীকে সচেতন হওয়ার পক্ষে যত্নবান হওয়া উচিত।

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

স্বাভাবিকভাবেই, এটি নিশ্চিত করা সম্ভব নয় যে জিইটি অনুরোধ সম্পাদনের ফলে সার্ভারটি পার্শ্ব-প্রতিক্রিয়া সৃষ্টি করে না; আসলে, কিছু গতিশীল সংস্থানগুলি একটি বৈশিষ্ট্য হিসাবে বিবেচনা করে। এখানে গুরুত্বপূর্ণ পার্থক্য হ'ল ব্যবহারকারী পার্শ্ব-প্রতিক্রিয়াগুলির জন্য অনুরোধ করেন নি, সুতরাং তাদের জন্য দায়বদ্ধ হতে পারে না।

এর অর্থ হ'ল জিইটি অনুরোধের ব্যবহারকারীর পক্ষে তারা দেখতে চায় না এমন কিছু দেখার বাইরে কখনও কোনও গুরুতর পরিণতি না ঘটানো উচিত, তবে একটি পোষ্ট অনুরোধ তাদের বা অন্য ব্যক্তির কাছে গুরুত্বপূর্ণ এমন একটি সংস্থান পরিবর্তন করতে পারে।

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

আমি এটিও মনে করি না যে কোনও পোস্টে পুনর্নির্দেশ করা কখনও প্রয়োজন হবে না। সার্ভার সাইড কোডের মধ্যে একটি ফাংশন কল করে, বা যদি এটি অন্য কোনও সার্ভারে ঘটতে হয় তবে কোনও সার্ভারের ব্রাউজারে একটি ইউআরএল সম্বলিত একটি পুনর্নির্দেশ না করে সার্ভারে প্রেরণ করার পরিবর্তে যে কোনও ক্রিয়াকলাপ সম্পাদন করা প্রয়োজন তা করা যেতে পারে uma ব্যবহারকারীর জন্য প্রক্সিটির মতো কাজ করে নিজেই সেই সার্ভারটিতে একটি অনুরোধ জানাতে পারে।

— bdsl
সূত্র