আমার কখন জিইটি বা পোষ্ট পদ্ধতি ব্যবহার করা উচিত? তাদের মধ্যে পার্থক্য কী?

Question

ব্যবহার GETবা POSTপদ্ধতি ব্যবহার করার সময় পার্থক্য কী ? কোনটি আরও সুরক্ষিত? তাদের প্রত্যেকের (ডিস) সুবিধাগুলি কী?

( একই প্রশ্ন )

Comments

গেটের কোনও দেহ নেই তাই অনুশীলনের অর্থ আপনি আরও জটিল কাঠামোর জন্য কোনও ক্যোয়ারী স্ট্রিং এনকোডিং বিন্যাসের অভাবে ডেটা কাঠামো হিসাবে নাম -> মান জোড়ের মধ্যে সীমাবদ্ধ Get আপনার অনুরোধগুলিতে আরও জটিল ডেটা স্ট্রাকচার হ্যান্ডেল করার প্রয়োজন হলে (যেমন একটি অ্যারে, অবজেক্ট ইত্যাদি) আপনার পোষ্ট এবং সম্ভবত আরও উন্নত ফর্ম্যাটগুলি (জেসন / এক্সএমএল) ব্যবহার করা দরকার। সংক্ষেপে বলা হয়েছে: আপনার সত্যিকারের না হলে GET ব্যবহার করবেন না (যেমন URL / উত্স অবশ্যই আবিষ্কারযোগ্য হবে)।

— থিশাইহাই

সম্ভাব্য সদৃশ আপনি কখন পোষ্ট ব্যবহার করেন এবং কখন আপনি জিইটি ব্যবহার করেন?

— ইমরান আলি খান

Answer 1

এটি সুরক্ষার বিষয় নয়। HTTP প্রোটোকলের সংজ্ঞায়িত পেতে টাইপ হচ্ছে অনুরোধ idempotent , পোস্ট পার্শ্ব প্রতিক্রিয়া হতে পারে না। সরল ইংরেজিতে, এর অর্থ হ'ল জিইটি কিছু পরিবর্তন করার পরিবর্তে কিছু দেখার জন্য ব্যবহৃত হয়, অন্যদিকে পিওএসটি কিছু পরিবর্তন করার জন্য ব্যবহৃত হয়। উদাহরণস্বরূপ, একটি অনুসন্ধান পৃষ্ঠায় জিইটি ব্যবহার করা উচিত, যখন এমন একটি ফর্ম যা আপনার পাসওয়ার্ড পরিবর্তন করে সেটিকে POST ব্যবহার করা উচিত।

এছাড়াও, নোট করুন যে পিএইচপি ধারণাগুলি কিছুটা বিভ্রান্ত করে। একটি পোস্ট অনুরোধ ক্যোয়ারী স্ট্রিং থেকে এবং অনুরোধের অংশের মাধ্যমে ইনপুট পায়। একটি জিইটি অনুরোধ সবেমাত্র ক্যোয়ারী স্ট্রিং থেকে ইনপুট পায়। সুতরাং একটি পোষ্ট অনুরোধ হ'ল জিইটি অনুরোধের সুপারস্টার; আপনি ব্যবহার করতে পারেন $_GETএকটি POST রিকোয়েস্ট, এবং এটা এমনকি জানার জন্য হতে পারে একই নামের পরামিতি আছে $_POSTএবং $_GETমানে ভিন্ন জিনিস।

উদাহরণস্বরূপ, ধরা যাক আপনার নিবন্ধ সম্পাদনা করার জন্য একটি ফর্ম রয়েছে have আর্টিকেল-আইডি কোয়েরি স্ট্রিং (এবং, সুতরাং এর মাধ্যমে উপলব্ধ $_GET['id']) হতে পারে, তবে ধরা যাক আপনি নিবন্ধ-আইডি পরিবর্তন করতে চান। নতুন আইডি এর পরে অনুরোধের বডিটিতে উপস্থিত থাকতে পারে ( $_POST['id'])। ঠিক আছে, সম্ভবত এটি সর্বোত্তম উদাহরণ নয়, তবে আমি আশা করি এটি দুজনের মধ্যে পার্থক্য তুলে ধরেছে।

Comments

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

— ফ্র্যাঙ্ক শ্যুইটারম্যান 22

আমার অর্থ হ'ল $ _POST এর সামগ্রীগুলি দূষিত ব্যবহারকারীদের কাছ থেকে যাদুতে লুকানো নেই। সমস্ত জিনিস প্রোগ্রামিংয়ের স্পষ্টতই সুরক্ষার দিক রয়েছে।

— ট্রয়স্কেন

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

— আকরিকস

"একটি পোষ্ট অনুরোধ ক্যোয়ারী স্ট্রিং থেকে এবং অনুরোধের অংশের মাধ্যমে ইনপুট পায়" " আইএমএইচও এটি ভুল। উভয়ই ইনপুট ব্যবহার করতে আপনার $ _REQUEST ব্যবহার করতে হবে। _P _POST টি url এন্ট্রি পায় না get

— গুনার বার্নস্টেইন

@ ফ্র্যাঙ্ক শ্যুইটারম্যান আমি জানি এই পোস্টটি পুরানো, তবে আমার অ্যাকাউন্টটি মুছে ফেলা আদর্শবান নয় এবং প্রাপ্তিটি ব্যবহার করা উচিত নয়।

— হিমশীতল

Answer 2

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

জিইটি পদ্ধতিটি, যা আগে উদাহরণে ব্যবহৃত হয়েছিল, ইউআরএলে নাম / মান জোড় যুক্ত করে। দুর্ভাগ্যক্রমে, একটি ইউআরএল এর দৈর্ঘ্য সীমিত, সুতরাং কেবলমাত্র কয়েকটি পরামিতি থাকলে এই পদ্ধতিটি কেবলমাত্র কাজ করে। যদি ফর্মটি প্রচুর পরিমাণে প্যারামিটার ব্যবহার করে বা পরামিতিগুলিতে প্রচুর পরিমাণে ডেটা থাকে তবে URL কেটে যাবে tr এছাড়াও, URL- এ পাস করা প্যারামিটারগুলি ব্রাউজারের ঠিকানা ক্ষেত্রে দৃশ্যমান হয় কোনও পাসওয়ার্ড প্রদর্শনের জন্য সেরা জায়গা নয়।

জিইটি পদ্ধতির বিকল্প হ'ল পোষ্ট পদ্ধতি। এই পদ্ধতিটি HTTP অনুরোধের শরীরে নাম / মান জুটি প্যাকেজ করে, যা একটি ক্লিনার URL তৈরি করে এবং ফর্ম আউটপুটে কোনও আকারের সীমাবদ্ধতা আরোপ করে না। এটি আরও সুরক্ষিত।

Comments

কীভাবে এটি আরও "সুরক্ষিত"?

— জুলিয়ান রেজচকে ২২ শে

কারণ এটি পরিবর্তন করা শক্ত? আপনি ঠিকানা বারে জিইটি পরিবর্তন করতে পারেন তবে এটি পোস্টের সাথে এতটা সহজ নয়।

— আইএডাপ্টার 23

সার্ভার ক্লায়েন্টকে বিশ্বাস করতে পারে না। মিথ্যা অনুমানের আশেপাশে আপনার অ্যাপ্লিকেশনটির নকশা তৈরি করা নিরাপদ far

— আফ্রোসकन

ওপেনিডেও সেভ হয় না, কারণ এটি ভেঙে যেতে পারে?

— আইএডাপ্টার

আমি বিশ্বাস করি এটি সবচেয়ে স্পষ্ট ব্যাখ্যা - প্রেরিত ডেটার স্থান নির্ধারণের বিষয়ে পার্থক্য। ধন্যবাদ.

— গ্রিনোল্ডম্যান

Answer 3

সেরা উত্তরটি প্রথমটি ছিল।

আপনি ব্যবহার করছেন:

• আপনি যখন তথ্য পুনরুদ্ধার করতে চান তখন পান (ডেটা পান)।
• পোস্ট আপনি ডাটা পাঠানোর জন্য (পোস্ট তথ্য) চান।

Comments

অনুরোধ / প্রতিক্রিয়া পরিষেবা প্যাটার্নটি কী ব্যবহৃত হয় এবং আপনি উভয়ই করতে চান? ;) যখন আমার কোনও প্রতিক্রিয়া ফিরে পাওয়া দরকার তখন আমি বেশিরভাগ ক্ষেত্রেই পোষ্ট ব্যবহার করতে পছন্দ করব।

— দিমিত্রি পাভলভ

সাধারণত এটি সত্য। GETডেটাও 'প্রেরণ' করতে পুরোপুরি সক্ষম, তাই খুব সঠিক উত্তর নয়।

— প্যাট্রিক হফম্যান

Answer 4

ব্যবহারে দুটি সাধারণ "সুরক্ষা" জড়িত রয়েছে GET। যেহেতু ইউআরএল স্ট্রিংয়ে ডেটা প্রদর্শিত হচ্ছে তার সম্ভাব্য কেউ অ্যাড্রেস বার / ইউআরএলে আপনার কাঁধের উপর নজর দিচ্ছে এমন কিছু কিছু সেটিকে দেখতে সক্ষম হতে পারে যেমন সেশন কুকি যা আপনার সেশন হাইজ্যাক করার জন্য ব্যবহার করা যেতে পারে। সবার মনে ক্যামেরা ফোন রয়েছে Keep

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

কিছু ক্লায়েন্ট / ফায়ারওয়ালস / আইডিএস সিস্টেমগুলি GETঅতিরিক্ত পরিমাণে ডেটা থাকার অনুরোধের ভিত্তিতে ভ্রান্ত হতে পারে এবং তাই অবিশ্বাস্য ফলাফল সরবরাহ করতে পারে।

POST উন্নত কার্যকারিতা যেমন ওয়েব সার্ভারে ফাইল আপলোডের জন্য ব্যবহৃত মাল্টি-পার্ট বাইনারি ইনপুট সমর্থন হিসাবে সমর্থন করে।

POSTএকটি সামগ্রীর দৈর্ঘ্যের শিরোনামের প্রয়োজন যা কোনও অ্যাপ্লিকেশন নির্দিষ্ট ক্লায়েন্টের প্রয়োগের জটিলতা বাড়িয়ে তুলতে পারে কারণ জমা দেওয়া ডেটার আকারটি কোনও ক্লায়েন্টের অনুরোধটিকে এককভাবে পাসের ইনক্রিমেন্টাল মোডে গঠন হতে আটকাতে হবে আগাম জানা উচিত। HTTPএটি কোনও RPC (রিমোট প্রক্রিয়া কল) পরিবহন হিসাবে ব্যবহার করে অপব্যবহার করা বেছে নেওয়ার ক্ষেত্রে একটি ছোট্ট সমস্যা ।

অন্যরা ইতিমধ্যে অর্থগত পার্থক্য এবং এই প্রশ্নের "কখন" অংশটি coveringাকতে একটি ভাল কাজ করেছেন।

Answer 5

আমি পেতে যখন আমি তথ্য পুনরুদ্ধার করছি ব্যবহার থেকে একটি URL এবং পোষ্ট যখন আমি তথ্য পাঠাচ্ছি করার একটি URL।

Comments

তবে আপনি প্রেরণ করতে জিইটি ব্যবহার করতে পারেন। পার্থক্যটি হ'ল ফর্ম্যাট (ইউআরএল (জিইটি) বা অনুরোধে (পোষ্ট))।

— এরিক

যদি শেষ পয়েন্টটি কোনও ফাইল গ্রহণ করে এবং ফাইলটি থেকে কোনও লাইন ফিরে আসে (কোনও ডেটা তৈরি বা পরিবর্তন বা ডেটাবেস জড়িত না), তবে শেষ পয়েন্টটি জিইটি বা পোষ্ট হওয়া উচিত?

— পরিবর্তনশীল

Answer 6

যদি প্রচুর ডেটা থাকে বা সংবেদনশীল তথ্য বাছাই করে থাকে (তবে সত্যিই সংবেদনশীল জিনিসগুলিরও একটি সুরক্ষিত সংযোগ প্রয়োজন) আপনার পোষ্টটি ব্যবহার করা উচিত।

আপনি যদি চান যে লোকেরা আপনার পৃষ্ঠাগুলি বুকমার্ক করতে সক্ষম হন তবে GET ব্যবহার করুন, কারণ সমস্ত ডেটা বুকমার্কের সাথে অন্তর্ভুক্ত।

জিইটি পদ্ধতিতে লোকেদের রিফ্রেশ করার জন্য কেবল সাবধান হন, কারণ ব্যবহারকারীকে সতর্ক না করেই প্রতিবার ডেটা পাঠানো হবে (পোস্ট কখনও কখনও ব্যবহারকারীকে ডেটা পুনরায় বিক্রয় সম্পর্কে সতর্ক করে দেয়))

Comments

যদি শেষ পয়েন্টটি কোনও ফাইল গ্রহণ করে এবং ফাইলটি থেকে কোনও লাইন ফিরে আসে (কোনও ডেটা তৈরি বা পরিবর্তন বা ডেটাবেস জড়িত না), তবে শেষ পয়েন্টটি জিইটি বা পোষ্ট হওয়া উচিত?

— পরিবর্তনশীল

@ পরিবর্তনশীল পোস্ট এই ক্ষেত্রে, বেশিরভাগ কারণেই পিওএসটি ফাইল আপলোডগুলি হ্যান্ডেল করার জন্য নির্মিত এবং মানক জিইটি হয় না। প্রতিবার পৃষ্ঠাটি লোড হওয়ার সময় আপনাকে ফাইলটি প্রেরণ করতে হবে, সুতরাং এটি জিইটি + ফাইলের পরিবর্তে স্ট্যান্ডার্ড পোষ্ট ব্যবহার করা বোধগম্য হবে যা জিইটি-র প্রত্যাশা ভঙ্গ করবে যে প্রতিবারের মতো একটি ইউআরএল কম-বেশি একই ফলাফল দেয়।

— গ্রান্ট

Answer 7

এই ডাব্লু 3 সি নথিটি এইচটিটিপি জিইটি এবং পোষ্টের ব্যবহারের ব্যাখ্যা দেয়।

আমি মনে করি এটি একটি অনুমোদিত উত্স।

সংক্ষিপ্তসারটি (নথির 1.3 অংশ):

• ইন্টারঅ্যাকশনটি যদি কোনও প্রশ্নের মতো হয় তবে জিইটি ব্যবহার করুন (যেমন, এটি একটি নিরাপদ অপারেশন যেমন ক্যোয়ারী, রিড অপারেশন বা লুকআপ)।
• পোস্ট ব্যবহার করুন যদি:
  • ইন্টারঅ্যাকশনটি আরও একটি আদেশের মতো, বা
  • মিথস্ক্রিয়াটি এমনভাবে সংস্থানটির অবস্থার পরিবর্তন করে যা ব্যবহারকারী বুঝতে পারে (যেমন, কোনও পরিষেবার সাবস্ক্রিপশন), বা
  • মিথস্ক্রিয়া ফলাফলের জন্য ব্যবহারকারীকে দায়বদ্ধ রাখা হবে।

Comments

আমি মনে করি এটি আরও সংক্ষেপে এই হিসাবে সংক্ষিপ্ত করা যেতে পারে: সার্ভারের স্থিতি পরিবর্তিত না হলে GET করুন, যখন হয় তখন পোস্ট করুন।

— ইয়ামচা

Answer 8

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

Answer 9

ডেটা পরিবর্তন করার সময় POST ব্যবহার করার কারণ:

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

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

আশা করি এটি ব্যাখ্যা করে কেন লোকেরা POST 'সুরক্ষিত' বলে। আপনি যদি সংবেদনশীল ডেটা প্রেরণ করছেন তবে আপনাকে অবশ্যই এসএসএল ব্যবহার করতে হবে।

Answer 10

GETএবং POSTএইচটিটিপি পদ্ধতিগুলি যা একই লক্ষ্য অর্জন করতে পারে

GETমূলত ডেটা পাওয়ার (পুনরুদ্ধার) করার জন্য, এ এর GETকোনও দেহ থাকা উচিত নয়, তাই কুকিজ বাদে তথ্য প্রেরণের একমাত্র জায়গাটি ইউআরএল এবং ইউআরএলগুলির দৈর্ঘ্য সীমিত, GETতুলনায় কম সুরক্ষিত POSTকারণ প্রেরিত ডেটার অংশ ইউআরএল

GETপাসওয়ার্ড, ক্রেডিট কার্ড বা অন্যান্য সংবেদনশীল তথ্য প্রেরণের সময় কখনই ব্যবহার করবেন না ! ইউআরএলটিতে প্রত্যেকের জন্য ডেটা দৃশ্যমান, ডেটা ক্যাশে করা যায়। GETক্ষতিগ্রস্থ যখন আমরা পুনরায় লোড করছি বা ফিরে বোতামটি কল করছি তখন এটি চিহ্নিত চিহ্নিত হবে, পরামিতিগুলি ব্রাউজারের ইতিহাসে থাকবে, কেবলমাত্র ASCII অক্ষর অনুমোদিত।

POSTডেটা সংরক্ষণ বা আপডেট করা বা কোনও পণ্য অর্ডার করা বা ইমেল প্রেরণের মতো কোনও কিছুতে জড়িত থাকতে পারে। POSTপদ্ধতি একটি শরীর আছে।

POSTসংবেদনশীল এবং গোপনীয় তথ্য সার্ভারের কাছে দেওয়ার জন্য পদ্ধতিটি সুরক্ষিত যা এটি ইউআরএলে কোয়েরি পরামিতিতে দৃশ্যমান হবে না এবং ব্রাউজারের ইতিহাসে পরামিতি সংরক্ষণ করা হয় না। ডেটা দৈর্ঘ্যের উপর কোনও বিধিনিষেধ নেই। যখন আমরা ব্রাউজারটি পুনরায় লোড করছি তখন ব্যবহারকারীকে সতর্ক করা উচিত যে ডেটা আবার জমা দেওয়ার কথা রয়েছে। POSTপদ্ধতিটি বুকমার্ক করা যায় না

Answer 11

1. GET পদ্ধতিটি সংবেদনশীল ডেটা প্রেরণের জন্য ব্যবহার করা হয় যেখানে সংবেদনশীল ডেটা প্রেরণের জন্য POST পদ্ধতি ব্যবহার করা হয়।
2. পোষ্ট পদ্ধতিটি ব্যবহার করে আপনি জিইটি পদ্ধতির তুলনায় প্রচুর পরিমাণে ডেটা পাঠাতে পারবেন।
3. জিইটি পদ্ধতি দ্বারা প্রেরিত ডেটা ব্রাউজার শিরোনাম বারে দৃশ্যমান হয় যেখানে POST পদ্ধতি দ্বারা প্রেরিত ডেটা অদৃশ্য।

Answer 12

আপনি URL থেকে সংস্থানগুলি পুনরুদ্ধার করতে চাইলে GET পদ্ধতিটি ব্যবহার করুন। আপনি যদি আপনার ব্রাউজারের পিছনের বোতামটি চাপান তবে আপনি সর্বদা শেষ পৃষ্ঠাটি দেখতে পেতেন এবং এটি বুকমার্ক করা যেতে পারে, সুতরাং এটি পোস্টের পদ্ধতির মতো নিরাপদ নয়।

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

Answer 13

GETপদ্ধতি:

• এটি কেবল 256 অক্ষরের তারিখ প্রেরণের জন্য ব্যবহৃত হয়

• এই পদ্ধতিটি ব্যবহার করার সময়, তথ্যটি ব্রাউজারে দেখা যায়

• এটি ফর্মগুলির দ্বারা ব্যবহৃত ডিফল্ট পদ্ধতি

• এটি এতটা সুরক্ষিত নয়।

---

POSTপদ্ধতি:

• এটি সীমাহীন ডেটা প্রেরণের জন্য ব্যবহৃত হয়।

• এই পদ্ধতির সাহায্যে, তথ্যটি ব্রাউজারে দেখা যায় না

• আপনি POSTপদ্ধতিটি স্পষ্টভাবে উল্লেখ করতে পারেন

• এটি GETপদ্ধতির চেয়ে বেশি সুরক্ষিত

• এটি আরও উন্নত বৈশিষ্ট্য সরবরাহ করে

Comments

"এটি কেবল 256 টি অক্ষরের তারিখ প্রেরণের জন্য ব্যবহৃত হয়" - সত্য নয়। "এই পদ্ধতিটি ব্যবহার করার সময়, তথ্যটি ব্রাউজারে দেখা যায়" - পোস্ট ডেটা ব্রাউজারগুলিতেও দৃশ্যমান হয়, এটি ঠিক তেমন স্পষ্ট নয়। "এটি আরও উন্নত বৈশিষ্ট্যগুলি সরবরাহ করে" - যেমন?

— কোয়ান্টিন

এটি মারাত্মকভাবে কার্যকর উত্তর নয়। 'এটি এতটা সুরক্ষিত নয়' এবং 'আরও উন্নত বৈশিষ্ট্য সরবরাহ করে' এবং কোয়ান্টিনের দ্বারা উল্লিখিত অন্যান্য জিনিসগুলির মতো ভুল তথ্য।

— অ্যান্ড্রু বারবার