आपको Apigee Edge का दस्तावेज़ दिख रहा है.
Apigee X के दस्तावेज़ पर जाएं. जानकारी
समस्या का ब्यौरा
क्लाइंट ऐप्लिकेशन को एपीआई कॉल के जवाब के तौर पर, गड़बड़ी कोड protocol.http.DuplicateHeader के साथ 400 Bad Request एचटीटीपी स्टेटस कोड मिलता है.
गड़बड़ी का मैसेज
क्लाइंट ऐप्लिकेशन को यह रिस्पॉन्स कोड मिलता है:
HTTP/1.1 400 Bad Request
इसके अलावा, आपको यहां दिखाए गए मैसेज जैसा गड़बड़ी का कोई मैसेज भी दिख सकता है:
{
"fault":{
"faultstring":"Duplicate Header \"Expires\"",
"detail":{
"errorcode":"protocol.http.DuplicateHeader"
}
}
}संभावित कारण
यह गड़बड़ी तब होती है, जब Apigee Edge में डुप्लीकेट होने की अनुमति नहीं रखने वाला कोई खास एचटीटीपी हेडर, क्लाइंट से Apigee Edge को भेजे गए एचटीटीपी अनुरोध के हिस्से के तौर पर एक से ज़्यादा बार दिखता है. ऐसा तब होता है, जब उसकी वैल्यू एक जैसी या अलग-अलग होती हैं.
आरएफ़सी 7230, सेक्शन 3.2.2: फ़ील्ड का क्रम के मुताबिक, ईमेल भेजने वाले को एक ईमेल में, एक ही नाम वाले कई हेडर फ़ील्ड जनरेट नहीं करने चाहिए.हालांकि, ऐसा तब किया जा सकता है, जब उस हेडर फ़ील्ड की पूरी वैल्यू को कॉमा लगाकर अलग की गई सूची के तौर पर तय किया गया हो. [जैसे, #(values)] या हेडर फ़ील्ड एक
जाने-माने अपवाद के तौर पर शामिल है. अगर Apigee Edge को क्लाइंट के भेजे गए एचटीटीपी अनुरोध में, एक ऐसा हेडर मिलता है जिसकी डुप्लीकेट कॉपी नहीं होनी चाहिए, तो वह 400 Bad Request और गड़बड़ी कोड protocol.http.DuplicateHeader के साथ जवाब देता है.
इस गड़बड़ी की ये वजहें हो सकती हैं:
| वजह | ब्यौरा | इनके लिए समस्या हल करने के निर्देश |
|---|---|---|
| अनुरोध में डुप्लीकेट हेडर मौजूद है | क्लाइंट ऐप्लिकेशन से Apigee को भेजे गए एचटीटीपी अनुरोध में डुप्लीकेट हेडर मौजूद हैं. | Edge Public और Private Cloud के उपयोगकर्ताओं के लिए |
गड़बड़ी का पता लगाने के सामान्य चरण
इस गड़बड़ी का पता लगाने के लिए, इनमें से किसी टूल/तकनीक का इस्तेमाल करें:
एपीआई मॉनिटरिंग
एपीआई मॉनिटरिंग का इस्तेमाल करके गड़बड़ी का पता लगाने के लिए:
- Apigee Edge के यूज़र इंटरफ़ेस (यूआई) में साइन इन करें. इसके लिए, आपके पास सही भूमिका होनी चाहिए.
उस संगठन पर स्विच करें जिसमें आपको समस्या की जांच करनी है.

- विश्लेषण करें > एपीआई मॉनिटरिंग > जांच करें पेज पर जाएं.
- वह समयावधि चुनें जिसमें आपको गड़बड़ियां दिखीं.
- पक्का करें कि प्रॉक्सी फ़िल्टर, सभी पर सेट हो.
- समय के हिसाब से गड़बड़ी का कोड प्लॉट करें.
उस सेल को चुनें जिसमें गड़बड़ी का कोड
protocol.http.DuplicateHeaderमौजूद है. यह कोड नीचे दिखाया गया है:
गड़बड़ी कोड
protocol.http.DuplicateHeaderके बारे में जानकारी, यहां दिए गए तरीके से दिखती है:
- लॉग देखें पर क्लिक करें और पूरे न हो पाने वाले अनुरोध की लाइन को बड़ा करें.
- लॉग विंडो में, यह जानकारी नोट करें:
- स्टेटस कोड:
400 - गड़बड़ी का सोर्स:
apigee - गड़बड़ी का कोड:
protocol.http.DuplicateHeader.
- स्टेटस कोड:
- अगर गड़बड़ी का सोर्स की वैल्यू
apigeeयाMPहै और गड़बड़ी का कोड की वैल्यूprotocol.http.DuplicateHeaderहै, तो इसका मतलब है कि क्लाइंट के एचटीटीपी अनुरोध में डुप्लीकेट हेडर शामिल हैं.
ट्रेस टूल
NGINX
NGINX ऐक्सेस लॉग का इस्तेमाल करके गड़बड़ी का पता लगाने के लिए:
- अगर आप Private Cloud के उपयोगकर्ता हैं, तो NGINX के ऐक्सेस लॉग का इस्तेमाल करके, एचटीटीपी
400गड़बड़ियों के बारे में अहम जानकारी का पता लगाया जा सकता है. NGINX के ऐक्सेस लॉग देखें:
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_logयहां: ORG, ENV, और PORT# को असल वैल्यू से बदल दिया जाता है.
- खोजें कि क्या किसी खास अवधि के दौरान कोई
400गड़बड़ी हुई है (अगर समस्या पहले हुई थी) या क्या अब भी400गड़बड़ी की वजह से कोई अनुरोध पूरा नहीं हो पा रहा है. अगर आपको X-Apigee-fault-code में
protocol.http.DuplicateHeaderकी वैल्यू से मेल खाने वाली400गड़बड़ियां मिलती हैं, तो X-Apigee-fault-source की वैल्यू का पता लगाएं.NGINX के ऐक्सेस लॉग में मौजूद, 400 गड़बड़ी का उदाहरण:
NGINX ऐक्सेस लॉग की ऊपर दी गई सैंपल एंट्री में, X-Apigee- fault-code और X-Apigee-fault-source: के लिए ये वैल्यू दी गई हैं:
रिस्पॉन्स हेडर वैल्यू X-Apigee-fault-code protocol.http.DuplicateHeaderX-Apigee-fault-source MP
वजह: अनुरोध में डुप्लीकेट हेडर मौजूद है
संक्रमण की जांच
- एपीआई मॉनिटरिंग या NGINX ऐक्सेस लॉग का इस्तेमाल करके, देखी गई गड़बड़ी के लिए गड़बड़ी का कोड और गड़बड़ी का सोर्स पता करें. इसके लिए, गड़बड़ी का पता लगाने के सामान्य तरीके में बताया गया तरीका अपनाएं.
- अगर Fault Source की वैल्यू
apigeeयाMPहै, तो इसका मतलब है कि क्लाइंट ऐप्लिकेशन ने Apigee को भेजे गए अनुरोध में डुप्लीकेट हेडर शामिल किए हैं. इनमें से किसी एक तरीके का इस्तेमाल करके, यह पता लगाया जा सकता है कि अनुरोध के हिस्से के तौर पर, कौनसे हेडर को एक से ज़्यादा बार भेजा गया है:
गड़बड़ी का मैसेज
गड़बड़ी के मैसेज का इस्तेमाल करना
अगर आपके पास Apigee Edge से मिला पूरा गड़बड़ी का मैसेज है, तो
faultstringदेखें.faultstringमें हेडर का ऐसा नाम मौजूद है जिसे एक से ज़्यादा बार भेजा गया है.गड़बड़ी के मैसेज का उदाहरण:
"faultstring":"Duplicate Header \"Expires\""
- ऊपर दिए गए गड़बड़ी के मैसेज में, आपको दिखेगा कि हेडर
Expiresको एक से ज़्यादा बार भेजा गया है. जैसा किfaultstringमें दिखाया गया है.
असल अनुरोध
असल अनुरोध का इस्तेमाल करना
अगर आपके पास क्लाइंट ऐप्लिकेशन से किए गए असली अनुरोध का ऐक्सेस है, तो यह तरीका अपनाएं:
- अनुरोध में पास किए गए हेडर की सूची की पुष्टि करें.
- अगर आपको लगता है कि किसी अनुरोध में कोई हेडर एक से ज़्यादा बार दिखता है और उसकी वैल्यू एक जैसी या अलग-अलग होती है , तो इस गड़बड़ी की वजह यही है.
अनुरोध का उदाहरण:
curl https://HOST_ALIAS/duplicateheadertest -v -H "Expires: Mon, 21 June 2021 07:28:00 GMT" -H "Expires: Mon, 21 June 2021 07:28:00 GMT"
ऊपर दिए गए उदाहरण में, हेडर
Expiresको एक से ज़्यादा बार भेजा गया है. इसलिए, यह अनुरोध400 Bad Requestगड़बड़ी के साथ पूरा नहीं हो सका. गड़बड़ी का कोड:protocol.http.DuplicateHeader.- इसके अलावा, अगर आपके पास क्लाइंट लॉग का ऐक्सेस है, तो यह देखा जा सकता है कि आपके पास Apigee Edge को किए गए असली अनुरोध के बारे में जानकारी है या नहीं. साथ ही, यह पता लगाया जा सकता है कि कौनसे हेडर को एक से ज़्यादा बार भेजा गया है.
रिज़ॉल्यूशन
डुप्लीकेट कॉन्टेंट की समस्या ठीक करना
पहला विकल्प [सुझाया गया विकल्प]: क्लाइंट ऐप्लिकेशन में डुप्लीकेट हेडर शामिल न करने की सुविधा चालू करें
- यह कुकी, किसी क्लाइंट के डुप्लीकेट हेडर भेजने की वजह का विश्लेषण करती है. उदाहरण के लिए, ऊपर दिए गए मामले में
Expires. पुष्टि करें कि एपीआई प्रॉक्सी के लिए, डुप्लीकेट हेडर स्वीकार करना ठीक है. आम तौर पर, एचटीटीपी स्पेसिफ़िकेशन RFC7230 के मुताबिक, ऐसा नहीं किया जाना चाहिए. - अगर आपको ऐसा नहीं करना है, तो अपने क्लाइंट ऐप्लिकेशन में बदलाव करें, ताकि वह डुप्लीकेट हेडर न भेजे.
ऊपर दिए गए उदाहरण में, यह देखा गया है कि हेडर
Expiresको एक ही वैल्यू के साथ दो बार भेजा गया है. ऐसा नहीं होना चाहिए. इस समस्या को ठीक करने के लिए,Expiresहेडर को सिर्फ़ एक बार पास करें. ऐसा यहां दिखाए गए तरीके से करें:curl https://HOST_ALIAS/duplicateheadertest -v -H "Expires: Mon, 21 June 2021 07:28:00 GMT"
- अगर आपको डुप्लीकेट हेडर की अनुमति देनी है, तो विकल्प #2 CwC प्रॉपर्टी का इस्तेमाल करना पर जाएं.
CwC
दूसरा विकल्प: CwC प्रॉपर्टी का इस्तेमाल करना
Apigee,
CwC प्रॉपर्टी HTTPHeader.<HeaderName> उपलब्ध कराता है. इसकी मदद से क्लाइंट ऐप्लिकेशन और टारगेट सर्वर, Apigee Edge में एपीआई प्रॉक्सी को डुप्लीकेट हेडर भेज सकते हैं.
| CwC प्रॉपर्टी | वैल्यू |
|---|---|
HTTPHeader.<HeaderName> |
allowDuplicates,multivalued |
उदाहरण के लिए, डुप्लीकेट और हेडर Expires के लिए एक से ज़्यादा वैल्यू की अनुमति देने के लिए, मैसेज प्रोसेसर पर यह प्रॉपर्टी सेट की जा सकती है.
HTTPHeader.Expires=allowDuplicates, multiValued
- अगर आप Private Cloud के उपयोगकर्ता हैं, तो प्रॉपर्टी को कॉन्फ़िगर किया जा सकता है. इससे Apigee Edge को
400 Bad Requestगड़बड़ी नहीं मिलेगी. भले ही, अनुरोध में डुप्लीकेट हेडर इस्तेमाल करने के लिए मैसेज प्रोसेसर कॉन्फ़िगर करना लेख में दिए गए तरीके का इस्तेमाल करके डुप्लीकेट हेडर शामिल किए गए हों. - अगर आप Public Cloud के उपयोगकर्ता हैं, तो अपने संगठन के लिए इस प्रॉपर्टी को कॉन्फ़िगर करने के लिए, Apigee Edge की सहायता टीम से संपर्क करें.
खास जानकारी
Apigee को उम्मीद है कि क्लाइंट ऐप्लिकेशन, अनुरोध के हिस्से के तौर पर डुप्लीकेट हेडर नहीं भेजेगा. इसके लिए, आरएफ़सी की इन खास बातों का पालन करना होगा:
| खास जानकारी |
|---|
| आरएफ़सी 7230, सेक्शन 3.2.2: फ़ील्ड का क्रम |
| आरएफ़सी 7230, सेक्शन 3.2 हेडर फ़ील्ड |
अगर आपको अब भी Apigee की सहायता टीम से मदद चाहिए, तो गड़बड़ी की जानकारी इकट्ठा करना ज़रूरी है पर जाएं.
डाइग्नोस्टिक जानकारी इकट्ठा करना ज़रूरी है
गड़बड़ी की जानकारी इकट्ठा करें. इसके बाद, Apigee Edge की सहायता टीम से संपर्क करें.
अगर आप पब्लिक क्लाउड के उपयोगकर्ता हैं, तो यह जानकारी दें:
- संगठन का नाम
- परिवेश का नाम
- एपीआई प्रॉक्सी का नाम
400गड़बड़ी को फिर से बनाने के लिए इस्तेमाल की गईcurlकमांड- एपीआई अनुरोधों के लिए ट्रेस फ़ाइल
अगर आप Private Cloud के उपयोगकर्ता हैं, तो यह जानकारी दें:
- अनुरोध पूरे न होने पर, गड़बड़ी का पूरा मैसेज दिखता है
- परिवेश का नाम
- एपीआई प्रॉक्सी बंडल
400गड़बड़ी को फिर से बनाने के लिए इस्तेमाल की गईcurlकमांड- एपीआई अनुरोधों के लिए ट्रेस फ़ाइल
NGINX ऐक्सेस लॉग:
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_logयहां: ORG, ENV, और PORT# को असल वैल्यू से बदल दिया जाता है.
- मैसेज प्रोसेसर के सिस्टम लॉग
/opt/apigee/var/log/edge-message-processor/logs/system.log