কিভাবে একটি HTTP POST অনুরোধ পাঠানো পরামিতি হয়?



parameters request (6)

একটি HTTP GET অনুরোধে, পরামিতিগুলি একটি ক্যোয়ারী স্ট্রিং হিসাবে পাঠানো হয়:

http://example.com/page?parameter=value&also=another

একটি HTTP পোষ্ট অনুরোধে, পরামিতিগুলি URI বরাবর পাঠানো হয় না।

মান কোথায়? অনুরোধ হেডারে? অনুরোধ শরীরের মধ্যে? এটা দেখতে কেমন?


Answer #1

HTTP POST- এ ফর্মের মানগুলি অনুরোধ শরীরের মধ্যে, querystring হিসাবে একই বিন্যাসে পাঠানো হয়।

আরো তথ্যের জন্য, spec


Answer #2

POST অনুরোধে ডিফল্ট মিডিয়া টাইপটি হল application/x-www-form-urlencoded । এটি কী-মান জোড়া জোড়া এনকোডিংয়ের জন্য একটি বিন্যাস। কী সদৃশ হতে পারে। প্রতিটি কী-মান জোড়াটি একটি অক্ষর দ্বারা পৃথক করা হয় এবং প্রতিটি কী তার মানের থেকে একটি = চরিত্র দ্বারা পৃথক করা হয়।

উদাহরণ স্বরূপ:

Name: John Smith
Grade: 19

এনকোড করা হয়েছে:

Name=John+Smith&Grade=19

এই HTTP হেডারের পরে অনুরোধ শরীরের মধ্যে স্থাপন করা হয়।


Answer #3

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

POST অনুরোধটি semantically এইরকম দেখতে পারে:

POST /?AuthId=YOURKEY&Action=WebServiceAction&Signature=rcLXfkPldrYm04 HTTP/1.1
Content-Type: text/tab-separated-values; charset=iso-8859-1
Content-Length: []
Host: webservices.domain.com
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: identity
User-Agent: Mozilla/3.0 (compatible; Indy Library)

name    id
John    G12N
Sarah   J87M
Bob     N33Y

এই পদ্ধতিটি যৌক্তিকভাবে একটি ওয়েব-সার্ভারের জন্য একটি "প্যারিসিং-নির্দেশনা" যা একটি Content-Type ব্যবহার করে কোয়েরি স্ট্রিং এবং শারীরিক-পোস্টকে একত্রিত করে।

অনুগ্রহ করে মনে রাখবেন: HTTP / 1.1 বামদিকে #32 (স্পেস) এবং ডানদিকে #10 (লাইন ফিড) দিয়ে মোড়ানো


Answer #4

বিষয়বস্তু HTTP হেডারের পরে রাখা হয়। একটি HTTP পোষ্টের বিন্যাস HTTP শিরোলেখগুলির জন্য, একটি ফাঁকা লাইন অনুসরণ করে, অনুরোধ সংস্থা অনুসরণ করে। POST ভেরিয়েবলগুলি শরীরের কী-মান জোড়া হিসাবে সংরক্ষণ করা হয়।

আপনি নীচের দেখানো HTTP পোস্টের কাঁচামালগুলিতে এটি দেখতে পারেন:

POST /path/script.cgi HTTP/1.0
From: [email protected]
User-Agent: HTTPTool/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 32

home=Cosby&favorite+flavor=flies

আপনি এটি Fiddler মত একটি সরঞ্জাম ব্যবহার করে দেখতে পারেন, যা আপনি কাঁচা HTTP অনুরোধ এবং তারের জুড়ে পাঠানো প্রতিক্রিয়া পেলलोडগুলি দেখতে ব্যবহার করতে পারেন।


Answer #5

সর্বোপরি, আসুন GET এবং POST এর মধ্যে পার্থক্য করি

পান: এটি ডিফল্ট HTTP অনুরোধ যা সার্ভারে তৈরি করা হয় এবং এর পরে সার্ভার এবং ক্যোয়ারী স্ট্রিং থেকে ডেটা পুনরুদ্ধার করতে ব্যবহৃত হয় ? একটি URI একটি অনন্য সম্পদ উদ্ধার করা হয়।

এই বিন্যাস

GET /someweb.asp?data=value HTTP/1.0

এখানে data=value ক্যোয়ারী স্ট্রিং মান পাস করা হয়।

পোষ্ট: এটি সার্ভারে নিরাপদে ডেটা পাঠানোর জন্য ব্যবহৃত হয় যাতে প্রয়োজন হয়, এটি একটি POST অনুরোধের ফর্ম্যাট

POST /somweb.aspHTTP/1.0
Host: localhost
Content-Type: application/x-www-form-urlencoded //you can put any format here
Content-Length: 11 //it depends
Name= somename

কেন পেতে পোস্ট?

সার্ভারে পাঠানো মান সাধারণত ক্যোয়ারী স্ট্রিংয়ের বেস URL এ যুক্ত করা হয়, এটি আপনার ডেটা হ্যাক করতে সক্ষম করে (এটি আপনার ফেসবুকের জন্য এমন একটি সমস্যা ছিল যেখানে আপনার প্রমাণপত্রাদি প্রকাশ করা হয়েছিল) তাই POST হল সার্ভারে ডেটা পাঠাতে ব্যবহৃত হয়েছে যা Request Body আপনার ডেটা সার্ভারে পাঠানোর জন্য ব্যবহৃত যা বেশি নিরাপদ কারণ এটি আপনার ডেটা লুকিয়ে রাখে এবং ক্ষেত্র থেকে আপনার তথ্য তাদের দৈর্ঘ্য গণনা করে এবং content-length জন্য header যোগ করে এবং কোন গুরুত্বপূর্ণ তথ্য সরাসরি URL যোগ করা হয়

এখন আপনার অনুরোধটি সুরক্ষিত করা হয়েছে সার্ভারে যেকোনো মান প্রেরণ করা হচ্ছে Request Body পাঠানো যেতে পারে যেমন নামটি বোঝায় যে এতে ডেটা ব্যবহারকারী পাঠাতে চেয়েছিল (এবং এটি URL Encoded ফর্ম্যাটে পাঠানো হবে) এবং Request Headers করবে Request Headers সাথে Request Headers মানগুলি তুলনা করে অনুরোধটি সুরক্ষিত রাখুন

সার্ভারগুলিতে অনুরোধগুলি কীভাবে করা হয় সে সম্পর্কে মৌলিক তথ্য দেখতে আপনি Google বিকাশকারী সরঞ্জামগুলির নেটওয়ার্ক বিভাগটি ব্যবহার করতে পারেন।

এবং আপনি সর্বদা আপনার Request Headers Cache-Control , Origin , Accept মত আরো মান যুক্ত করতে পারেন।


Answer #6

সংক্ষিপ্ত উত্তর: POST অনুরোধে, অনুরোধগুলি "শরীরের" অনুরোধে পাঠানো হয়। ওয়েব ফর্মগুলির সাথে তারা সম্ভবত মিডিয়া টাইপের application/x-www-form-urlencoded বা multipart/form-data সহ পাঠানো হয়। ওয়েব অনুরোধগুলি পরিচালনা করার জন্য ডিজাইন করা হয়েছে এমন প্রোগ্রামিং ভাষা বা ফ্রেমওয়ার্কগুলি সাধারণত এই অনুরোধগুলির সাথে "দ্য রাইট থিং ™" করে এবং সহজেই ডিকোডেড মানগুলির (যেমন $_REQUEST বা $_POST , পিএইচপি, বা cgi.FieldStorage() , পাইথন মধ্যে flask.request.form )।

এখন আসুন একটি বিট digress, যা পার্থক্য বুঝতে সাহায্য করতে পারে;)

GET এবং POST অনুরোধের মধ্যে পার্থক্য মূলত অর্থাত্। তারাও ভিন্নভাবে "ব্যবহৃত" হয়, যা মানগুলি কিভাবে গৃহীত হয় তাতে পার্থক্য ব্যাখ্যা করে।

GET ( প্রাসঙ্গিক RFC বিভাগ )

GET অনুরোধটি কার্যকর করার সময়, আপনি সার্ভারকে এক, বা সংস্থার একটি সেটের জন্য জিজ্ঞাসা করেন। ক্লায়েন্ট ফলাফল ফিল্টার করার অনুমতি দিতে, এটি URL এর তথাকথিত "ক্যোয়ারী স্ট্রিং" ব্যবহার করতে পারে। প্রশ্ন পরে স্ট্রিং অংশ ? । এটি ইউআরআই সিনট্যাক্স অংশ।

সুতরাং, আপনার অ্যাপ্লিকেশন কোড (অনুরোধটি গ্রহণকারী অংশটি) এর দৃষ্টিকোণ থেকে, আপনাকে এই মানগুলিতে অ্যাক্সেস পেতে URI প্রশ্ন অংশটি পরিদর্শন করতে হবে।

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

POST ( প্রাসঙ্গিক RFC বিভাগ )

POST অনুরোধটি কার্যকর করার সময়, ক্লায়েন্ট প্রকৃতপক্ষে রিমোট হোস্টে একটি নতুন নথি জমা দিচ্ছে। সুতরাং, একটি প্রশ্ন স্ট্রিং (semantically) ইন্দ্রিয় তোলে না। আপনি আপনার অ্যাপ্লিকেশন কোড তাদের অ্যাক্সেস কেন না কেন।

POST একটু জটিল (এবং আরও বেশি নমনীয়):

একটি POST অনুরোধ প্রাপ্ত করার সময়, আপনাকে সর্বদা একটি "পেলलोड" বা HTTP শর্তাবলীতে: একটি বার্তা সংস্থা আশা করা উচিত। বার্তাটি নিজেই বেশ নিরর্থক, কারণ কোনও মান নেই (যতদূর আমি বলতে পারি। সম্ভবত অ্যাপ্লিকেশন / অক্টেট-স্ট্রিম?) বিন্যাস। শরীরের বিন্যাস Content-Type শিরোনাম দ্বারা সংজ্ঞায়িত করা হয়। method="POST" সহ একটি HTML FORM উপাদান ব্যবহার করার সময়, এটি সাধারণত application/x-www-form-urlencoded । আপনি যদি ফাইল আপলোড ব্যবহার করেন তবে আরেকটি সাধারণ ধরনের multipart/form-data । কিন্তু text/plain , application/json বা এমনকি একটি কাস্টম application/octet-stream থেকেও কিছু হতে পারে।

কোনও ক্ষেত্রে, যদি কোনও POST অনুরোধটি এমন Content-Type সাথে তৈরি করা হয় যা আবেদন দ্বারা পরিচালনা করা যায় না তবে এটি 415 স্থিতি-কোডটি ফেরত দিতে হবে।

সর্বাধিক প্রোগ্রামিং ভাষাগুলি (এবং / অথবা ওয়েব-ফ্রেমওয়ার্কগুলি) মেসেজ শরীরে / সবচেয়ে সাধারণ প্রকার থেকে (যেমন application/x-www-form-urlencoded , multipart/form-data বা application/json ) বার্তা প্রেরণ / এনকোড করার উপায় প্রদান করে। । তাই যে সহজ। কাস্টম ধরনের সম্ভাব্য একটি বিট আরো কাজ প্রয়োজন।

উদাহরণস্বরূপ একটি স্ট্যান্ডার্ড এইচটিএমএল ফর্ম এনকোড করা নথি ব্যবহার করে, অ্যাপ্লিকেশন নিম্নলিখিত ধাপগুলি সম্পাদন করতে হবে:

  1. Content-Type ক্ষেত্র পড়ুন
  2. মান সমর্থিত মিডিয়া-প্রকারগুলির মধ্যে একটি না হলে, 415 স্থিতি কোডের সাথে একটি প্রতিক্রিয়া ফেরত দিন
  3. অন্যথায়, বার্তা শরীর থেকে মান ডিকোড।

আবার, পিএইচপি মত ভাষা, বা অন্যান্য জনপ্রিয় ভাষার জন্য ওয়েব ফ্রেমওয়ার্ক সম্ভবত আপনার জন্য এটি পরিচালনা করবে। এই ব্যতিক্রমটি 415 ত্রুটি। কোনও কাঠামোর ভবিষ্যদ্বাণী করতে পারে না কোন সামগ্রী-ধরনের আপনার অ্যাপ্লিকেশন সমর্থন করে এবং / অথবা সমর্থন করে না। এটি সম্পূর্ণভাবে আপনার জন্য।

PUT ( প্রাসঙ্গিক RFC অধ্যায় )

একটি PUT অনুরোধ POST অনুরোধ হিসাবে ঠিক একই ভাবে পরিচালিত হয়। বড় পার্থক্য হল যে একটি POST অনুরোধ সার্ভারকে কীভাবে (এবং যদি সর্বদা) কোনও নতুন সংস্থান তৈরি করতে দেয় তা অনুমিত করা হয়। ঐতিহাসিকভাবে (এখন অপ্রচলিত RFC2616 থেকে এটি একটি নতুন সংস্থান তৈরি করতে হয়েছিল যেখানে অনুরোধটি পাঠানো হয়েছিল URI এর "অধস্তন" (শিশু))।

বিপরীতে একটি PUT অনুরোধটি অবশ্যই সেই URI একটি সংস্থান "জমা দেওয়ার" এবং ঠিক সেই সামগ্রীর সাথে অনুমিত হয়। বেশিও না, কমও না. ধারণাটি হল যে ক্লায়েন্টটি "পুটিং" করার আগে সম্পূর্ণ সংস্থানটি তৈরি করার জন্য দায়ী। প্রদত্ত URL- এ সার্ভারকে এটি স্বীকার করা উচিত।

ফলস্বরূপ, একটি বিদ্যমান অনুরোধটি প্রতিস্থাপনের জন্য সাধারণত একটি POST অনুরোধ ব্যবহার করা হয় না। একটি PUT অনুরোধ উভয় তৈরি এবং প্রতিস্থাপন করতে পারেন।

সাইড নোট

এছাড়াও " পট প্যারামিটার " রয়েছে যা রিমোটে অতিরিক্ত ডেটা পাঠাতে ব্যবহার করা যেতে পারে, তবে তারা এত অসাধারণ, যে আমি এখানে খুব বেশি বিস্তারিত জানব না। কিন্তু, রেফারেন্সের জন্য এখানে RFC থেকে একটি উদ্ধৃতি রয়েছে:

হায়ারার্কিক্যাল পাথগুলিতে বিন্দু-বিভাজনগুলির পাশাপাশি, একটি পথ বিভাগ জেনেরিক সিনট্যাক্স দ্বারা অপ্রকাশিত বলে মনে করা হয়। ইউআরআই উত্পাদক অ্যাপ্লিকেশনগুলি প্রায়ই একটি সেগমেন্টে অনুমোদিত নির্দিষ্ট অক্ষরগুলিকে স্কিম-নির্দিষ্ট বা ডিফারেন্স-হ্যান্ডলার-নির্দিষ্ট উপপাদ্যগুলি সীমিত করতে ব্যবহার করে। উদাহরণস্বরূপ, সেমিকোলন (";") এবং সমান ("=") সংরক্ষিত অক্ষরগুলি প্রায়ই সে সেগমেন্টে প্রমিত পরামিতি এবং প্যারামিটার মানগুলিকে সীমিত করতে ব্যবহার করা হয়। কমা (",") সংরক্ষিত চরিত্র প্রায়ই একই উদ্দেশ্যে ব্যবহৃত হয়। উদাহরণস্বরূপ, "ইউআরএল" এর সংস্করণ 1.1 এর একটি রেফারেন্স ইঙ্গিত করার জন্য একটি ইউআরআই প্রযোজক "নাম; v = 1.1" হিসাবে একটি সেগমেন্ট ব্যবহার করতে পারে, তবে অন্যটি "নাম, 1.1" হিসাবে সেগমেন্ট ব্যবহার করতে পারে। প্যারামিটার প্রকারগুলি প্রকল্প-ভিত্তিক সেমেটিক্স দ্বারা সংজ্ঞায়িত করা যেতে পারে, তবে বেশিরভাগ ক্ষেত্রেই একটি প্যারামিটারের সিনট্যাক্স URIs dereferencing অ্যালগরিদম বাস্তবায়নের জন্য নির্দিষ্ট।





uri