এইচটিএমএল ফর্মগুলিতে কেন কোনও পুট এবং ডিলিট পদ্ধতি নেই?


265

এইচটিএমএল 4 / এক্সএইচটিএমএল 1 কেবলমাত্র জিইটি এবং পোষ্টগুলিকে ফর্মগুলিতে অনুমতি দেয়, এখন মনে হচ্ছে এইচটিএমএল 5ও এটি করবে। নেই যোগ করার জন্য একটি প্রস্তাব এই দুটি কিন্তু এটা আকর্ষণ হত্তন হবে বলে মনে হচ্ছে না। এইচটিএমএল 5 স্পেসিফিকেশন খসড়ায় পুট এবং ডিলিট না অন্তর্ভুক্ত করার প্রযুক্তিগত বা রাজনৈতিক কারণগুলি কী কী ছিল?


7
এইচটিএমএল হ'ল মার্কআপ ল্যাঙ্গুয়েজ, এইচটিটিপি হ'ল প্রোটোকল
র‌্যাচেট ফ্রিক

51
@ র্যাচেট ফ্রিক: আমি এটি সম্পর্কে সচেতন। তবুও আমি বিশেষত এইচটিএমএল সম্পর্কে জিজ্ঞাসা করছি কারণ এটি কেবল GET এবং পোষ্টকে অনুমোদিত <form>পদ্ধতি হিসাবে সংজ্ঞায়িত করে।
ফিলিপকে

একটি সাধারণ দৃশ্যটি ট্যাবুলার ডেটাযুক্ত একটি ফর্ম, যেখানে ব্যবহারকারীকে "আরও লাইন" ব্যবহারকারীর সিদ্ধান্ত হিসাবে আরও লাইন বা না রাখার দরকার হয়। জাভাস্ক্রিপ্ট + পোস্ট ব্যবহার কৃত্রিম, সম্ভবত এইচটিএমএল 6 এই ধরণের অপারেশন করতে বিকল্প ফর্ম বৈশিষ্ট্য প্রদর্শন করবে।
পিটার ক্রাউস

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

4
এটি কি এখনও বৈধ? w3.org/TR/form-http-extensions/#http-delete-form
জেফ

উত্তর:


348

এটি একটি আকর্ষণীয় প্রশ্ন। এখানে অন্যান্য উত্তরগুলি সমস্ত অনুমানমূলক এবং কিছু ক্ষেত্রে ফ্ল্যাট-আউট ভুল। এখানে আমার মতে লেখার পরিবর্তে, আমি আসলে কিছু গবেষণা করেছেন এবং মূল সূত্র যে কেন আলোচনা পাওয়া মুছতে এবং করা HTML5 এর ফর্ম মান অংশ নয়।

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

খসড়া থেকে এই পদ্ধতিগুলি সরানোর যৌক্তিকতা কী ছিল? ডাব্লু 3 সি বাগ রিপোর্ট 10671 এ এই বিষয়ে আলোচনা করেছে । মাইক আমন্ডসেন এই সমর্থনের পক্ষে যুক্তি দেখিয়েছিলেন:

XMLHttpRequest অবজেক্ট ব্যবহার করে আধুনিক ওয়েব ব্রাউজারগুলির জন্য উত্স সার্ভারের রিসোর্সগুলি সংশোধন করতে PUT এবং মুছে ফেলুন straight লিখিত ব্রাউজার ইন্টারঅ্যাকশনগুলির জন্য এটি এত সহজ নয় simple [...]

এই প্যাটার্নটি প্রায়শই প্রয়োজন হয় যে বেশ কয়েকটি সাধারণভাবে ব্যবহৃত ওয়েব ফ্রেমওয়ার্ক / লাইব্রেরি একটি "অন্তর্নির্মিত" ওয়ার্ক-এভার তৈরি করেছে। [...]

অন্যান্য বিবেচ্য বিষয়:

  • PUT / DELETE ব্যবহারের পরিবর্তে পোড়ালটি টানেল হিসাবে ব্যবহার করলে ক্যাচগুলি মিস-মিলগুলি হতে পারে (যেমন পোস্টের প্রতিক্রিয়াগুলি ক্যাচযোগ্য , পুট প্রতিক্রিয়াগুলি (6) নয়, মুছুন প্রতিক্রিয়াগুলি (7))
  • আইডেম্পোটেন্ট অপারেশন (PUT / DELETE) সম্পাদন করার জন্য একটি অ-আদর্শবান পদ্ধতি (POST) ব্যবহার করা নেটওয়ার্ক ব্যর্থতার কারণে পুনরুদ্ধারকে জটিল করে তোলে (যেমন "এই ক্রিয়াটি পুনরাবৃত্তি করা কি নিরাপদ?")।
  • [...]

এটি তার পুরো পোস্টটি পড়ার মতো।

টম ওয়ার্ড্রপ একটি আকর্ষণীয় বিষয়ও তুলে ধরেছেন:

এইচটিএমএল নিখরচায় এইচটিটিপিতে আবদ্ধ। এইচটিএমএল এইচটিটিপি হিউম্যান ইন্টারফেস। এইচটিএমএল এইচটিটিপি নির্দিষ্টকরণে সমস্ত প্রাসঙ্গিক পদ্ধতি সমর্থন করে না কেন এটি স্বয়ংক্রিয়ভাবে প্রশ্নবিদ্ধ। কেন মেশিনগুলি পুট এবং সংস্থান মুছে ফেলতে পারে, কিন্তু মানুষ পারে না? [...]

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

নিম্নলিখিত তর্ক যুক্ত করে বাগটি শেষ পর্যন্ত ইয়ান হিকসন কর্তৃক উইন্ট ফিক্স হিসাবে বন্ধ করা হবে :

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

তবে গল্পের শেষ নেই! ইস্যু W3C এর বাগ যে ব্যক্তি অনুসরণ করে সালে বন্ধ ছিল ছড়ানোর এইচটিএমএল ওয়ার্কিং গ্রুপ ইস্যু যে ব্যক্তি অনুসরণ করে হবে:

https://www.w3.org/html/wg/tracker/issues/195

এই মুহুর্তে, এটি মনে হয় যে এই পদ্ধতির কোনও সমর্থন না থাকার মূল কারণটি হ'ল কেউই এর জন্য একটি বিস্তৃত বিশদ লিখতে সময় নেয়নি।


70
গবেষণার প্রচেষ্টাটি স্থানে রাখা এবং প্রশ্নের যথাযথ উত্তর দিতে বেশ কয়েকটি বাহ্যিক রেফারেন্স খনন করার জন্য +1।

6
@ শিবকুমার আমার মনে হয় আপনি যা সত্যিই জিজ্ঞাসা করছেন তা হল যখন জাভাস্ক্রিপ্ট ইতিমধ্যে কাজ করতে পারে তখন এইচটিএমএলকে কেন বিরক্ত করবেন? এটা মোটামুটি প্রশ্ন। আমার ধারণা, ওপির প্রশ্নটি বাস্তবতার চেয়ে কৌতূহলের জায়গা থেকে বেশি আসে। এইচটিএমএল এবং এইচটিটিপি একে অপরের জন্য তৈরি দুটি মান, এবং এখনও এইচটিএমএল বেশিরভাগ প্রাথমিক HTTP- র সম্পর্কে অজানা বলে মনে হয়। "কেন?" জিজ্ঞাসা করা একটি প্রাকৃতিক প্রশ্ন।
মার্ক ই। হাজেস

23
অবশ্যই আপনাকে পিটিউটের জন্য একটি পেওড অন্তর্ভুক্ত করতে হবে এবং এটি মুছে ফেলার জন্য এটি সম্ভব? এছাড়াও যদি "ফর্মগুলির সাথে খুব বেশি কিছু বোঝা যায় না" তবে লোকেরা কেন এটি জিজ্ঞাসা করছে এবং সফ্টওয়্যার যদি সে তৈরি করে থাকে তবে কেন অনেক কিছু ঘটে Od কীভাবে এক ব্যক্তি কীভাবে ঠিক করতে পারেন যে বাকী বিশ্বের কী প্রয়োজন বা চায় ...
জোনাথান।

4
@ মেহাজে এছাড়াও, সম্ভবত এটি কেবল আমিই, তবে আমি মনে করি কোনও প্রস্তাবের সাধারণ সমর্থন প্রকাশের চেয়ে মেলিং তালিকাগুলি আলোচনার জন্য আরও ভাল জায়গা। আমি পাবলিক-এইচটিএমএল-মন্তব্য মেলিং তালিকায় একটি নতুন থ্রেড শুরু করতে আগ্রহী নই যাতে আমি "এই প্রস্তাবটি পছন্দ করি; ফর্মগুলি অন্যান্য এইচটিটিপি পদ্ধতি ব্যবহার করতে সক্ষম হবে" বলতে পারি। আধুনিক ওয়েবে বড় হওয়া এমন একজন হিসাবে আমি যা জানতে চাই তা হল: "আপভোট বোতামটি কোথায়?" ;-)
আজেদি 32

6
@ আজেদী 32 এই পোস্টটি এখানে রয়েছে: list.w3.org/ আর্কাইভস / প্রজাতন্ত্র / প্রজাতন্ত্র- html / 2015Feb / 0000.html আমি যারা পোস্টটি পাবলিক-এইচটিএমএল মেইলিং লিস্টে জবাব দিতে আগ্রহী তাদের সবাইকে উত্সাহিত করি।
মার্ক ই। হাজেস

12

GET এবং POST এর একটি পরিষ্কার বিষয়বস্তু-নিরপেক্ষ যুক্তি রয়েছে। জিইটি হ'ল কোনও URL এর সামগ্রীটি এমনভাবে পুনরুদ্ধার করা যা পুনরাবৃত্তি এবং সম্ভবত ক্যাশে নিরাপদ। পোষ্ট হ'ল এমন কিছু করা যা পুনরাবৃত্তি করা, জল্পনা-কল্পনা চালানো বা ক্যাশে নিরাপদ নয়।

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

সুতরাং মূলত কোনও লাভ নেই।


22
যদিও পোষ্ট পুট এবং মুছে ফেলা কভার করে, তবুও আমি আলাদা পদ্ধতি থাকার সুবিধা দেখতে পাচ্ছি। এগুলির সমস্তগুলি HTTP স্পেসিফিকেশনে আচ্ছাদিত এবং তাদের ব্যবহারকে REST এ উত্সাহ দেওয়া হয়।
ফিলিপকে

10
@ ডেভিড: এটি একটি বৈশিষ্ট্য হবে
ডোনাল ফেলো

15
যুক্তিটি হ'ল পোষ্ট এবং ডিলিটের আলাদা - প্রায় বিপরীত - অর্থ। আপনি দাবী করেন যে পোস্ট সম্পূর্ণরূপে মোছার জন্য কভার করে, তবুও পোষ্ট আদর্শবান নয় এবং মোছা হয়। আপনি সেটা কিভাবে ব্যাখ্যা করবেন? w3.org/Protocols/rfc2616/rfc2616-sec9.html
মার্ক ই।

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

13
আমি এই উত্তরের সাথে একমত নই। POSTহয় idempotent না যার কারণে যখন আপনি "পেছন" আপনার ব্রাউজারে ক্লিক করুন, এটি একটি কুশ্রী যে পৃষ্ঠাটি বলেছেন ফর্ম তীব্র বিরক্তি করা প্রয়োজন প্রদর্শন করা হবে। তবে এটি যদি একটি হয়ে থাকে তবে আপনার যে পৃষ্ঠাটি পাওয়া উচিত তা প্রদর্শন PUTকরার PUTঅনুরোধটি নিরাপদে পুনরায় পাঠাতে পারে । প্রদত্ত অবশ্যই এক ধরণের তৈরি করে এপিআই গোলযোগ না DELETE /resource/latest
arg20

12

এটি 2010 সালে উত্থাপিত হয়েছিল কারণ বাগ 10671 ফর্ম পদ্ধতি হিসাবে পুট এবং ডিলিটের সমর্থন যোগ করার বিষয়ে বিবেচনা করে

এই "বৈশিষ্ট্য" এবং কিছুটা ভারী-হস্তের জন্য একটি মাঝারি পরিমাণে পুশব্যাক ছিল কিন্তু অবশেষে এটি ওয়ার্কিং গ্রুপগুলি বাগ ট্র্যাকারের দুটি বিষয় হিসাবে বৃদ্ধি পেয়েছিল:

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

ইস্যু -৫৫৫ সংখ্যাটি চেয়ারদের সামনে উপস্থাপন করা হয়েছিল। ক্যামেরন জোনস জানুয়ারী 2012 এর 18 ই যা সে পরিণত পেশ উপর একটি পরিবর্তন প্রস্তাব লিখিতভাবে স্বেচ্ছাসৈনিক আপ ধাপ ধাপ প্রথম কাজ খসড়া 29th মে 2014. খসড়া মধ্য দিয়ে যেতে হবে W3C এর সুপারিশ প্রক্রিয়া

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


5

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

আমি এখনই এটিকে আটকাতে পারছি না, তবে এইচটিএমএল 5 মেলিং তালিকাগুলির একটি যখন তারা এই নিয়ে আলোচনা করছিল আমি তাদের মনে পড়ছি।


4
পিট এবং মুছে ফেলতে বা পোষ্টের মতো একইভাবে পুনঃনির্দেশ করতে পারে না এমন কোনও কারণ আছে কি?
রায়ান এইচ

3
@ ম্যাকাপলুন সম্ভবত এটি আপনাকে মেলিংয়ের তালিকাটি
প্রজাতন্ত্র-

2
পছন্দ করেছেন মুছে ফেলার অনুরোধ প্রেরণকারী প্রত্যেকটি অ্যাপ্লিকেশন সূচকে পুনঃনির্দেশ দিয়ে জবাব দেবে।
কিওয়ারটি

5

ইতিহাস

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

METHOD
        selects a method of accessing the action URI. The set of
        applicable methods is a function of the scheme of the
        action URI of the form. See 8.2.2, "Query Forms:
        METHOD=GET" and 8.2.3, "Forms with Side-Effects:
        METHOD=POST".

আরও ব্যাখ্যাগুলি বিভাগ 8.2.2 - জিইটি এবং বিভাগ 8.2.3 - পোস্টে অবস্থিত

মনে রাখবেন, এইচটিএমএল 2.0 (নভেম্বর 1995) HTTP 1.0 (মে 1996) এর আগে নির্দিষ্ট করা হয়েছিল । সুতরাং প্রত্যেকে কেবল জিইটি (HTTP 0.9 হিসাবে) বা এক্সটেনশন পোস্টের সাথে এইচটিটিপি ব্যবহার করেছিল। তবে কেবলমাত্র কয়েকটি ওয়েব সার্ভারগুলি পুট এবং ডিলেটকে সমর্থন করেছে (যেমন HTTP 1.0 অ্যাপেন্ডিক্সে বর্ণিত )।

থটস

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


-2

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

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


12
এ নিয়ে সুরক্ষার কোনও ফল নেই। আপনি এখনও HTTP- র মাধ্যমে PUT / মুছতে অনুরোধ করতে পারেন। curl --request PUT http://A.B.c/indexআপনি HTML এর মাধ্যমে এই আদেশগুলি কেন অ্যাক্সেস করতে পারবেন তা প্রশ্ন why
মার্টিন ইয়র্ক

5
-1 বন্য অনুমানগুলি সাধারণত এসও তেমন সহায়ক নয়।
মার্ক ই। হাজেস

-4

অনুরোধের ডেটা প্রেরণের ফর্ম্যাট হ'ল গেট এবং পোস্ট।

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

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


5
-1 "অনুরোধের ডেটা প্রেরণের ফর্ম্যাট হ'ল গেট এবং পোস্ট" " না, এগুলি HTTP পদ্ধতি, "ফর্ম্যাট" নয় "
মার্ক ই। হাজেস
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.