ডিবাগিং প্রক্সি দিয়ে ব্যর্থতার কেস ডিজাইন করা

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

“অনুরোধটি ব্যর্থ হয়েছে” খুবই বিস্তৃত একটি পরীক্ষার কেস। একটি বৈধ HTTP ত্রুটি প্রতিক্রিয়া, যে প্রতিক্রিয়া কখনও আসে না এবং ডাউনলোডের মাঝপথে বিচ্ছিন্ন একটি সংযোগ—এগুলো অ্যাপ্লিকেশনটির কাছে ভিন্ন ভিন্ন কিছু দাবি করে।

সঠিক স্তরে হস্তক্ষেপ ব্যবহার করুন

Charles এমন ব্রেকপয়েন্ট দেয় যা অনুরোধ বা প্রতিক্রিয়া পাঠানোর আগে থামিয়ে দেয়। বাধাপ্রাপ্ত বার্তাটি পরীক্ষা ও সম্পাদনা করা যায়, যেতে দেওয়া যায় বা বাতিল করা যায়। এর Rewrite টুল মিলে যাওয়া হেডার, URL বা বডিতে পুনরাবৃত্তিযোগ্য পরিবর্তন প্রয়োগ করে। থ্রটলিং ব্যান্ডউইথ ও অতিরিক্ত লেটেন্সি নিয়ন্ত্রণ করে।

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

প্রতিটি কেস যেন ব্যাখ্যাযোগ্য থাকে

উদ্দিষ্ট হোস্ট ও পাথ সংকীর্ণভাবে মেলান। স্বাভাবিক বিনিময় দিয়ে শুরু করুন, একটি পরিবর্তন চালু করুন এবং কী পরিবর্তন হয়েছে তা লিখে রাখুন। কোনো পুনঃপ্রচেষ্টা দ্বিতীয় এন্ডপয়েন্টে পৌঁছালে সিদ্ধান্ত নিন একই নিয়ম সেই প্রচেষ্টাতেও প্রযোজ্য হবে কি না। নাহলে একটি শর্তহীন পুনর্লিখন প্রতিটি পুনরুদ্ধার পথকে মূল ব্যর্থতায় পরিণত করতে পারে।

আপলোড বা পেমেন্ট-সদৃশ কাজে হারানো প্রতিক্রিয়া প্রমাণ করে না যে সার্ভার অনুরোধ প্রত্যাখ্যান করেছে। প্রতিটি পরিবহন ব্যর্থতা পুনরাবৃত্তি করা নিরাপদ—এমন দাবি না করে সেই অস্পষ্টতা পুনঃপ্রচেষ্টার কেসে অন্তর্ভুক্ত করুন।

HTTPS কনটেন্ট পরীক্ষা বা সম্পাদনার জন্য ক্লায়েন্টকে ডিবাগিং প্রক্সির TLS পরিদর্শন সেটআপে অংশ নিতে হয়। যে প্রক্সি কেবল CONNECT বহন করে সে এনক্রিপ্টেড অ্যাপ্লিকেশন বাইট দেখে। একটি বিচ্ছিন্ন পরীক্ষা কনফিগারেশন ব্যবহার করুন এবং পরে তার রাউটিং ও ট্রাস্ট সেটআপ পুনরুদ্ধার করুন, যাতে পরবর্তী পর্যবেক্ষণ সাধারণ ক্লায়েন্টকে বর্ণনা করে।