502 गलत गेटवे - TOBigLine

आपको Apigee Edge का दस्तावेज़ दिख रहा है.
Apigee X के दस्तावेज़ पर जाएं. जानकारी

समस्या का ब्यौरा

क्लाइंट ऐप्लिकेशन को एपीआई कॉल के जवाब के तौर पर, गड़बड़ी कोड protocol.http.TooBigLine के साथ 502 Bad Gateway एचटीटीपी स्टेटस कोड मिलता है.

गड़बड़ी का मैसेज

क्लाइंट ऐप्लिकेशन को यह रिस्पॉन्स कोड मिलता है:

HTTP/1.1 502 Bad Gateway

इसके अलावा, आपको गड़बड़ी का यह मैसेज भी दिख सकता है:

{
   "fault":{
      "faultstring":"response line size exceeding 2,048",
      "detail":{
         "errorcode":"protocol.http.TooBigLine"
      }
   }
}

संभावित कारण

यह गड़बड़ी तब होती है, जब टारगेट/बैकएंड सर्वर से Apigee Edge को भेजे गए Response-Line का साइज़, एचटीटीपी रिस्पॉन्स के तौर पर Apigee Edge में तय की गई ज़्यादा से ज़्यादा सीमा से ज़्यादा हो.

इस गड़बड़ी की संभावित वजहों के बारे में जानने से पहले, आइए समझते हैं कि रिस्पॉन्स-लाइन का क्या मतलब है और इसके साइज़ की जांच कैसे की जाती है.

जवाब की लाइन को समझना

आम तौर पर, एचटीटीपी रिस्पॉन्स में तीन हिस्से होते हैं:

1. Status-Line (Apigee में इसे Response-Line कहा जाता है)
2. ( एचटीटीपी हेडर का सेट )
3. [ Body ]

जवाब वाली लाइन में तीन हिस्से होते हैं: प्रोटोकॉल वर्शन, इसके बाद संख्यात्मक स्टेटस कोड और उससे जुड़ा टेक्स्ट फ़्रेज़. इसे यहां दिखाया गया है:

Response-Line   = <HTTP-Version> <Status-Code> <Reason-Phrase>

जब टारगेट/बैकएंड सर्वर ऐप्लिकेशन से कोई एचटीटीपी रिस्पॉन्स भेजा जाता है, तो भेजी गई पहली लाइन, ऊपर बताई गई Response-Line को दिखाती है. इसके बाद, हेडर और जवाब का मुख्य हिस्सा/पेलोड होता है.यहां दिए गए सैंपल स्क्रीनशॉट में, एक सामान्य curl अनुरोध, अनुरोध वाला हिस्सा, और जवाब वाला हिस्सा (जवाब की लाइन के साथ) दिखाया गया है.

जवाब देने वाली लाइन के साइज़ के बारे में जानकारी

1. ऊपर दिए गए उदाहरण में, जवाब की start लाइन (पहली लाइन) को Response-Line भी कहा जाता है. यह इस तरह से दिखती है:

   HTTP/1.1 200 OK

   इस रिस्पॉन्स-लाइन का साइज़ ~15 bytes है, क्योंकि इसमें 15 ASCII characters शामिल है. यह Apigee Edge में तय की गई सीमा के अंदर है. इसलिए, Apigee Edge क्लाइंट को बिना किसी गड़बड़ी के जवाब भेजता है.

2. इसी तरह, अगर ऊपर दिखाए गए गड़बड़ी के मैसेज में मौजूद faultstring को देखा जाए, तो इसमें "response line size exceeding 2,048" शामिल है. इससे पता चलता है कि टारगेट/बैकएंड सर्वर से भेजे गए एचटीटीपी रिस्पॉन्स में Response-Line 2,048 बाइट से ज़्यादा है.

बड़ी रिस्पॉन्स-लाइन को समझना

Status-Line (इसे यहां Response-Line कहा गया है) और सामान्य एचटीटीपी अनुरोधों और जवाबों की परिभाषा के मुताबिक, इसका साइज़ Apigee Edge में तय की गई डिफ़ॉल्ट सीमा 2 के से काफ़ी कम होगा. इसलिए, हम इस सीमा तक नहीं पहुंच पाएंगे. हालांकि, यहां कुछ ऐसे संभावित उदाहरण दिए गए हैं जिनमें यह सीमा पार हो सकती है:

1. टारगेट/बैकएंड सर्वर, एचटीटीपी सिस्टम नहीं है. ऐसा हो सकता है कि वह एचटीटीपी रिस्पॉन्स के अलावा किसी और तरह का रिस्पॉन्स दे रहा हो.
2. टारगेट/बैकएंड सर्वर में समस्याएं हैं और वह एचटीटीपी रिस्पॉन्स के हिस्से के तौर पर लंबी रिस्पॉन्स-लाइन भेजता है.

इसके बारे में ज़्यादा जानने के लिए, Getting error protocol.http.TooBigLine, "response line size exceeding 2,048 पढ़ें.

इस गड़बड़ी की ये वजहें हो सकती हैं:

गड़बड़ी का पता लगाने के सामान्य चरण

इस गड़बड़ी का पता लगाने के लिए, इनमें से किसी टूल/तकनीक का इस्तेमाल करें:

वजह: रिस्पॉन्स-लाइन का साइज़, तय सीमा से ज़्यादा है

संक्रमण की जांच

1. एपीआई मॉनिटरिंग, ट्रेस टूल या NGINX ऐक्सेस लॉग का इस्तेमाल करके, देखी गई गड़बड़ी के लिए गड़बड़ी कोड और गड़बड़ी का सोर्स पता करें. इसके बारे में गड़बड़ी का पता लगाने के सामान्य तरीके में बताया गया है.
2. अगर गड़बड़ी का सोर्स फ़ील्ड में target वैल्यू मौजूद है, तो इसका मतलब है कि टारगेट/बैकएंड सर्वर ऐप्लिकेशन ने Apigee को जो रिस्पॉन्स-लाइन भेजी है उसका साइज़, Apigee Edge में तय की गई सीमा से ज़्यादा है.

3. इनमें से किसी एक तरीके का इस्तेमाल करके, यह पुष्टि की जा सकती है कि रिस्पॉन्स-लाइन का साइज़, अनुमति वाली 2 केबी की सीमा से ज़्यादा है:

   गड़बड़ी का मैसेज

   गड़बड़ी के मैसेज का इस्तेमाल करके पुष्टि करने के लिए:

   अगर आपके पास Apigee Edge से मिले गड़बड़ी के पूरे मैसेज का ऐक्सेस है, तो faultstring देखें.

   गड़बड़ी के मैसेज का उदाहरण:

   "faultstring":"response line size exceeding 2,048"

   ऊपर दिए गए faultstring से पता चलता है कि रिस्पॉन्स-लाइन का साइज़, 2 केबी की तय सीमा से ज़्यादा है.

   असल अनुरोध

   असली अनुरोध का इस्तेमाल करके पुष्टि करने के लिए:

   अगर आपके पास टारगेट/बैकएंड सर्वर ऐप्लिकेशन को किए गए असली अनुरोध का ऐक्सेस है, तो यह तरीका अपनाएं:

   1. Response-Line के साइज़ की पुष्टि करना
   2. अगर आपको लगता है कि यूआरआई का साइज़, Apigee Edge में तय की गई सीमा से ज़्यादा है, तो इसकी वजह से समस्या आ सकती है.

      टारगेट/बैकएंड सर्वर से मिले रिस्पॉन्स का उदाहरण:

      curl -v http://HOSTALIAS/test
      

      *   Trying 3.2.1.4...
      * TCP_NODELAY set
      * Connected to <hostalias> (3.2.1.4) port 80 (#0)
      > GET /test HTTP/1.1
      > Host: HOSTALIAS
      > User-Agent: curl/7.64.1
      > Accept: */*
      >
      < HTTP/1.1 200 1111…<trimmed>...11111111
      < Date: Mon, 26 Jul 2021 07:07:18 GMT
      < Content-Type: application/json
      < Content-Length: 269
      < Connection: keep-alive
      < Server: gunicorn/19.9.0
      < Access-Control-Allow-Origin: *
      < Access-Control-Allow-Credentials: true
      <
      {
      <Response Body>
      }
      * Connection #0 to host <hostalias> left intact
      * Closing connection 0

      ऊपर दिए गए उदाहरण में, Response-Line HTTP/1.1 200 1111…<trimmed>...11111111 का साइज़ 2 केबी से ज़्यादा है. इसका मतलब है कि इसमें 2 के से ज़्यादा ASCII वर्ण शामिल हैं.

      अगर किसी अन्य क्लाइंट का इस्तेमाल किया जा रहा है, तो क्लाइंट लॉग की समीक्षा करें. साथ ही, Apigee Edge को भेजी जा रही Response-Line का साइज़ पता लगाने की कोशिश करें.

   मैसेज प्रोसेसर के लॉग

   मैसेज प्रोसेसर के लॉग का इस्तेमाल करके पुष्टि करने के लिए:

   अगर आप Private Cloud के उपयोगकर्ता हैं, तो मैसेज प्रोसेसर के लॉग का इस्तेमाल करके यह पुष्टि की जा सकती है कि रिस्पॉन्स-लाइन का साइज़, Apigee Edge में तय की गई सीमा से ज़्यादा तो नहीं है.

   1. एपीआई मॉनिटरिंग, ट्रेस टूल या NGINX ऐक्सेस लॉग का इस्तेमाल करके, अनुरोध के पूरे न होने की वजह बताने वाले मैसेज आईडी का पता लगाएं. इसके बारे में गड़बड़ी का पता लगाने के सामान्य तरीके में बताया गया है.

   2. मैसेज प्रोसेसर के लॉग में मैसेज आईडी खोजें:

      /opt/apigee/var/log/edge-message-processor/logs/system.log

   3. आपको system.log से मिलती-जुलती लाइनें दिखेंगी, जैसे कि यहां दी गई हैं:

      2021-07-26 06:45:41,451 org:myorg env:prod api:testtoobigline rev:1 messageid:r-5110240-1
      NIOThread@1 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() :
      ClientChannel[Connected: Remote:3.2.1.2:80 Local:192.168.205.251:44398]@20592
      useCount=1 bytesRead=0 bytesWritten=201 age=144ms  lastIO=0ms  isOpen=true.onExceptionRead
      exception: {}
      com.apigee.errors.http.server.BadGateway: response line size exceeding 2,048
      at <snipped>
      
      2021-07-26 06:45:41,451 org:myorg env:prod api:testtoobigline rev:1
      messageid:r-5110240-1  NIOThread@1 ERROR ADAPTORS.HTTP.FLOW -
      AbstractResponseListener.onException() : AbstractResponseListener.onError
      (HTTPResponse@6a5d6c33, response line size exceeding 2,048)

      ऊपर दिए गए गड़बड़ी के मैसेज में मौजूद टेक्स्ट message = response line size exceeding 2,048 से पता चलता है कि रिस्पॉन्स-लाइन का साइज़ 2 केबी से ज़्यादा है. इसलिए, Apigee Edge एक अपवाद दिखाता है. साथ ही, क्लाइंट ऐप्लिकेशन को 502 स्टेटस कोड और गड़बड़ी का कोड protocol.http.TooBigline दिखाता है.

रिज़ॉल्यूशन

सीमाएं

Apigee को उम्मीद है कि क्लाइंट ऐप्लिकेशन और बैकएंड सर्वर, ऐसी Request/Response-Lines नहीं भेजेंगे जिनका साइज़, Apigee Edge की सीमाएं में Request/Response Line की सीमा के लिए तय की गई सीमा से ज़्यादा हो.

1. अगर आप Public Cloud के उपयोगकर्ता हैं, तो अनुरोध और जवाब की लाइन के साइज़ की ज़्यादा से ज़्यादा सीमा वही होगी जो अनुरोध/जवाब की लाइन के साइज़ के लिए Apigee Edge की सीमाओं में बताई गई है.
2. अगर आप Private Cloud का इस्तेमाल करने वाले व्यक्ति हैं, तो हो सकता है कि आपने अनुरोध और जवाब की लाइन के साइज़ की डिफ़ॉल्ट ज़्यादा से ज़्यादा सीमा में बदलाव किया हो. हालांकि, ऐसा करने का सुझाव नहीं दिया जाता. मौजूदा सीमा की जांच कैसे करें में दिए गए निर्देशों का पालन करके, रिस्पॉन्स-लाइन के साइज़ की ज़्यादा से ज़्यादा सीमा तय की जा सकती है.

मौजूदा सीमा कैसे देखें?

इस सेक्शन में बताया गया है कि मैसेज प्रोसेसर पर प्रॉपर्टी HTTPResponse.line.limit को नई वैल्यू के साथ अपडेट किया गया है या नहीं, इसकी पुष्टि कैसे करें.

1. मैसेज प्रोसेसर मशीन पर, HTTPResponse.line.limit प्रॉपर्टी को /opt/apigee/edge-message-processor/conf डायरेक्ट्री में खोजें. इसके बाद, देखें कि नीचे दी गई इमेज में दिखाई गई वैल्यू सेट की गई है या नहीं:

   grep -ri "HTTPResponse.line.limit" /opt/apigee/edge-message-processor/conf
   

2. ऊपर दिए गए कमांड का सैंपल नतीजा यहां दिया गया है:

   /opt/apigee/edge-message-processor/conf/http.properties:HTTPResponse.line.limit=2k

3. ऊपर दिए गए उदाहरण में, ध्यान दें कि HTTPResponse.line.limit प्रॉपर्टी को http.properties में 2k वैल्यू के साथ सेट किया गया है.

   इससे पता चलता है कि Private Cloud के लिए Apigee में कॉन्फ़िगर किए गए Response-Line के साइज़ की सीमा 2 केबी है.

अगर आपको अब भी Apigee की सहायता टीम से मदद चाहिए, तो गड़बड़ी की जानकारी इकट्ठा करना ज़रूरी है पर जाएं.

डाइग्नोस्टिक जानकारी इकट्ठा करना ज़रूरी है

गड़बड़ी की यह जानकारी इकट्ठा करें. इसके बाद, Apigee Edge की सहायता टीम से संपर्क करें:

अगर आप पब्लिक क्लाउड के उपयोगकर्ता हैं, तो यह जानकारी दें:

• संगठन का नाम
• परिवेश का नाम
• एपीआई प्रॉक्सी का नाम
• 502 गड़बड़ी को फिर से बनाने के लिए इस्तेमाल किया गया पूरा curl निर्देश
• एपीआई अनुरोधों के लिए ट्रेस फ़ाइल

अगर आप Private Cloud के उपयोगकर्ता हैं, तो यह जानकारी दें:

• अनुरोध पूरे न होने पर, गड़बड़ी का पूरा मैसेज दिखता है
• संगठन का नाम
• परिवेश का नाम
• एपीआई प्रॉक्सी बंडल
• एपीआई के अनुरोध पूरे न होने की समस्या के लिए ट्रेस फ़ाइल
• 502 गड़बड़ी को फिर से बनाने के लिए इस्तेमाल की गई 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