ফরোয়ার্ড প্রক্সি একটি কাস্টম API হেডার কীভাবে সামলায়

একটি API তার সংস্করণ API-Version-এর মতো কাস্টম অনুরোধ ফিল্ডে বহন করতে পারে। সাধারণ ফরোয়ার্ডিং প্রক্সির উচিত নয় শুধু নামটি অপরিচিত বলে সেই ফিল্ডটি বাদ দেওয়া। HTTP অচেনা ফিল্ড ফরোয়ার্ড করা বাধ্যতামূলক করে, যদি না কোনো নির্দিষ্ট ব্যতিক্রম বা কনফিগার করা নীতি প্রযোজ্য হয়।

Connection ফিল্ড এমনই একটি ব্যতিক্রম। এই উদাহরণ অনুরোধগুলি তুলনা করুন:

API-Version: 2026-10
Connection: keep-alive

এখানে API ফিল্ডটি এই সংযোগের জন্য স্থানীয় হিসেবে নির্ধারিত হয়নি। পরের উদাহরণে প্রেরক স্পষ্টভাবে তার পরিধি বদলাচ্ছে:

API-Version: 2026-10
Connection: API-Version

একটি ফরোয়ার্ডিং প্রক্সি ফরোয়ার্ড করার আগে Connection-এ নাম দেওয়া ফিল্ডগুলি সরিয়ে দেয় এবং সংযোগ-নির্দিষ্ট নির্দেশগুলি নিজেই সরায় বা প্রতিস্থাপন করে। তাই মূল উৎসের জন্য ইচ্ছিত অ্যাপ্লিকেশন হেডারটি ওই টোকেন তালিকায় থাকা উচিত নয়।

ফিল্ডটি যেখানে বদলায় সেই বিন্দু খুঁজুন

ক্লায়েন্টের তৈরি অনুরোধ, প্রক্সির পাওয়া ও ফরোয়ার্ড করা ফিল্ড, এবং মূল উৎস কী পেয়েছে তা তুলনা করুন। ক্লায়েন্ট প্রক্সি দেখার আগেই একটি হেডার বাদ দিতে পারে; কনফিগার করা ফিল্টার সেটি সচেতনভাবে সরাতে পারে; সার্ভার হেডারের সীমা ছাড়ানোর জন্য অনুরোধ প্রত্যাখ্যান করতে পারে।

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

সাধারণ CONNECT টানেলের ভিতরে এন্ড-টু-এন্ড HTTPS-এ প্রক্সি ভিতরের API ফিল্ড পড়তে ও বেছে বেছে সরাতে পারে না। তখন হেডার পরিদর্শন TLS প্রান্তে বা স্পষ্টভাবে বিশ্বস্ত পরিদর্শন মধ্যস্থতাকারীর কাছে থাকে।