फ़ॉरवर्ड प्रॉक्सी कस्टम 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 सिरों पर या स्पष्ट रूप से विश्वसनीय निरीक्षण मध्यस्थ पर होता है।