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-এর ভিতরে থাকে; ফরওয়ার্ড প্রক্সি সহজভাবে তার ভিতরের প্রত্যাশা হেডার পরীক্ষা করে না। ইন্টারসেপশন বা স্পষ্ট-পাঠ প্রেরণের পথ আলাদা।

প্রত্যাশা সরানো ইচ্ছাকৃত সামঞ্জস্যের পছন্দ হতে পারে, কিন্তু এর অর্থ ক্লায়েন্ট প্রাথমিক প্রত্যাখ্যান জানার আগেই বড় বডি পাঠানো শুরু করতে পারে। সেই আচরণ আসল প্রয়োজনীয়তার সঙ্গে তুলনা করুন। পুরোনো প্রক্সির জন্য ঐতিহাসিক সমাধানকে প্রতিটি আপলোড থেকে হেডার সরানোর সর্বজনীন নির্দেশ হিসেবে বর্ণনা করবেন না।

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