HTTP আপলোড বিৰতি আৰু Expect: 100-continue

Expect: 100-continue বিনিময় চিনি লওক আৰু ইয়াৰ চুটি সিদ্ধান্ত-বিন্দুটো ডেটা স্থানান্তৰ হৈ থকাৰ সময়ত ৰৈ যোৱা আপলোডৰ পৰা পৃথক কৰক।

সংযোগ খোল খায়। অনুৰোধৰ হেডাৰ ওলাই যায়। ফাইলটো নোচৰা যেন লাগে। এটা ব্যাখ্যা হʼল ক্লায়েন্টে নিজৰ বডি প্ৰেৰণ কৰাৰ আগতে Expect: 100-continue ৰ উত্তৰৰ বাবে অপেক্ষা কৰি আছে।

এই কৌশলে গ্ৰহণকাৰীক সম্ভাব্য ডাঙৰ আপলোড প্ৰেৰণ কৰাৰ আগতে হেডাৰৰ পৰা অনুৰোধ নাকচ কৰিবলৈ দিয়ে। সাধাৰণ সফল ক্ৰমটো হʼল:

request headers → 100 Continue → request body → final response

100 তথ্যমূলক: ই ক্লায়েণ্টক আগবাঢ়িবলৈ দিয়ে, কিন্তু ফাইলটো সংৰক্ষিত হৈছে বা এপ্লিকেশ্যন কাৰ্য সফল হৈছে বুলি নুবুজায়। Git push এ HTTP 417 ঘূৰাই দিয়া এটা নিৰ্দিষ্ট প্ৰত্যাশা-বিফলতাৰ উদাহৰণ।

ক্লায়েণ্টে কোনটো উত্তৰ পাইছে তাক নিৰ্ণয় কৰক

পৰ্যবেক্ষণঅনুসন্ধান কৰিবলগীয়া অৰ্থ
100 Continueক্লায়েণ্টে বডিৰ সৈতে আগবাঢ়িব পাৰে
বডিৰ আগতে চূড়ান্ত নাকচকাৰ্যটো হেডাৰ পৰ্যায়ত নাকচ কৰা হৈছিল
প্ৰত্যাশিত অন্তৱৰ্তী উত্তৰ নাইক্লায়েণ্টৰ অপেক্ষা নীতি আৰু সেই পথত হোৱা ব্যৱহাৰ

curl এ expect-continue ৰ বাবে সুকীয়া অপেক্ষা সংহতি প্ৰদান কৰে। যদি সেই libcurl অপেক্ষা প্ৰত্যাশিত উত্তৰ নোপোৱাকৈ শেষ হয়, ই বডি তেনেকৈয়ে পঠিয়ায়; সমাপ্তি নিজে আপোনাকৈ গোটেই স্থানান্তৰ বিফল নুবুজায়। সংহতিটো সম্পূৰ্ণ স্থানান্তৰৰ বাবে দিয়া সময়ৰ পৰা পৃথক। শেষৰটো বৃদ্ধি কৰিলে একেটা প্ৰাৰম্ভিক বিৰতি ব্যাখ্যা নোহোৱাকৈ থাকিব পাৰে।

Expect কেৰিয়াৰ কৰা HTTP সংলাপটোও চিনি লওক। HTTPS গন্তবলৈ সাধাৰণ CONNECT ৰ সৈতে ৱেবছাইটৰ আপলোড বিনিময় TLS ৰ ভিতৰত থাকে; ফৰৱাৰ্ড প্ৰক্সীয়ে তাৰ ভিতৰৰ প্ৰত্যাশা হেডাৰ মাত্ৰ পৰীক্ষা নকৰে। ইণ্টাৰচেপশ্যন বা স্পষ্ট-পাঠ প্ৰেৰণ পথ বেলেগ।

প্ৰত্যাশা আঁতৰোৱা ইচ্ছাকৃত সংগতি-বিকল্প হʼব পাৰে, কিন্তু ইয়াৰ অৰ্থ হʼল ক্লায়েণ্টে সোনকাল নাকচৰ কথা জানিবলৈ আগতেই ডাঙৰ বডি পঠিয়াবলৈ আৰম্ভ কৰিব পাৰে। সেই আচৰণ প্ৰকৃত প্ৰয়োজনৰ সৈতে তুলনা কৰক। পুৰণি প্ৰক্সীৰ বাবে হোৱা ঐতিহাসিক পৰিহাৰক প্ৰতিটো আপলোডৰ পৰা হেডাৰ আঁতৰোৱাৰ সৰ্বজনীন নিৰ্দেশ হিচাপে নকʼব।

সম্পৰ্কিত প্ৰবন্ধ