फर्वार्ड प्रोक्सीले अनुकूलित API हेडरलाई कसरी व्यवहार गर्छ
API संस्करण फिल्डलाई सामान्य फर्वार्डिङ, प्रत्येक हपको Connection नियम र स्पष्ट रूपमा कन्फिगर गरिएको हेडर नीतिबाट पछ्याउनुहोस्।
एउटा 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 छेउहरूमा वा स्पष्ट रूपमा विश्वसनीय निरीक्षण मध्यस्थमा पर्छ।