500 ข้อผิดพลาดภายในเซิร์ฟเวอร์ - BadPath

คุณกำลังดูเอกสารประกอบของ Apigee Edge
ไปที่เอกสารประกอบของ Apigee X info

ลักษณะปัญหา

แอปพลิเคชันไคลเอ็นต์จะได้รับรหัสสถานะ HTTP 500 Internal Server Error พร้อม รหัสข้อผิดพลาด protocol.http.BadPath เป็นการตอบกลับสำหรับการเรียก API

ข้อความแสดงข้อผิดพลาด

แอปพลิเคชันไคลเอ็นต์จะได้รับโค้ดตอบกลับต่อไปนี้

HTTP/1.1 500 Internal Server Error

นอกจากนี้ คุณอาจเห็นข้อความแสดงข้อผิดพลาดต่อไปนี้

{
   "fault":{
      "faultstring":"Invalid request path",
      "detail":{
         "errorcode":"protocol.http.BadPath"
      }
   }
}

สาเหตุที่เป็นไปได้

ข้อผิดพลาดนี้เกิดขึ้นหาก URL ของคำขอของเซิร์ฟเวอร์แบ็กเอนด์ ซึ่งแสดงโดยตัวแปรโฟลว์ target.url มี path ที่ขึ้นต้นด้วยเครื่องหมายคำถาม (?) แทน เครื่องหมายทับ (/) ซึ่งไม่ถูกต้อง

ตามข้อกำหนด RFC 3986 ส่วนที่ 3: องค์ประกอบไวยากรณ์ และ RFC 3986 ส่วนที่ 3.3: เส้นทาง:

1. ไวยากรณ์ URI มีคอมโพเนนต์ต่อไปนี้

           foo://example.com:8042/over/there?name=ferret#nose
           \_/   \______________/\_________/ \_________/ \__/
            |            |            |            |       |
         scheme      authority       path        query   fragment
   

2. คอมโพเนนต์ path เป็นข้อกำหนดและต้องขึ้นต้นด้วยเครื่องหมายทับ (/) เสมอ

ดังนั้น หาก URL ของคำขอของเซิร์ฟเวอร์แบ็กเอนด์มีคอมโพเนนต์ path ที่ขึ้นต้นด้วยเครื่องหมายคำถาม (?) แทนเครื่องหมายทับ (/) Apigee Edge จะตอบกลับด้วย 500 Internal Server Error และรหัสข้อผิดพลาด protocol.http.BadPath

เช่น หาก target.url มีค่า https://www.mocktarget.apigee.net?json ข้อผิดพลาดนี้จะเกิดขึ้นเนื่องจาก path พบว่าไม่ถูกต้อง เนื่องจากเริ่มต้นด้วยเครื่องหมายคำถาม (?) แทนเครื่องหมายทับ (/)

ขั้นตอนการวินิจฉัยที่พบบ่อย

ใช้เครื่องมือ/เทคนิคอย่างใดอย่างหนึ่งต่อไปนี้เพื่อวินิจฉัยข้อผิดพลาดนี้

สาเหตุ: URL ของเซิร์ฟเวอร์แบ็กเอนด์ (target.url) มีเส้นทางที่ไม่ถูกต้อง

การวินิจฉัย

1. กำหนดรหัสข้อผิดพลาดและแหล่งที่มาของข้อผิดพลาดสำหรับ 500 Internal Server Error โดยใช้การตรวจสอบ API, เครื่องมือติดตาม หรือบันทึกการเข้าถึง NGINX ตามที่อธิบายไว้ใน ขั้นตอนการวินิจฉัยทั่วไป
2. หากรหัสข้อผิดพลาดคือ protocol.http.BadPath และแหล่งที่มาของข้อผิดพลาดมีค่า เป็น target แสดงว่า URL ของเซิร์ฟเวอร์แบ็กเอนด์มีเส้นทางที่ไม่ถูกต้อง

3. URL ของเซิร์ฟเวอร์แบ็กเอนด์แสดงด้วยตัวแปรโฟลว์ target.url ใน Apigee Edge ข้อผิดพลาดนี้มักเกิดขึ้นหากคุณพยายามอัปเดต URL ของเซิร์ฟเวอร์แบ็กเอนด์ (target.url) แบบไดนามิกโดยใช้นโยบายใดนโยบายหนึ่ง (ภายใน พร็อกซี/โฟลว์ที่แชร์) ในโฟลว์คำขอเป้าหมาย เพื่อให้มีเส้นทางที่ไม่ถูกต้อง

4. ตรวจสอบว่าตัวแปรโฟลว์ target.url มีเส้นทางที่ไม่ถูกต้องจริงหรือไม่ และแหล่งที่มาของค่าโดยใช้วิธีใดวิธีหนึ่งต่อไปนี้

   Trace

   การใช้เครื่องมือติดตาม

   หากคุณบันทึกการติดตามข้อผิดพลาดนี้ไว้ ให้ทำตามขั้นตอนที่อธิบายไว้ใน การใช้เครื่องมือติดตาม และ

   1. ตรวจสอบว่า target.url มีเส้นทางที่ไม่ถูกต้องหรือไม่ นั่นคือขึ้นต้น ด้วยเครื่องหมายคำถาม (?) แทนเครื่องหมายทับ (/)

   2. หากใช่ ให้ค้นหานโยบายที่แก้ไขหรืออัปเดตค่าของ target.url ให้มีเส้นทางที่ไม่ถูกต้อง

      ตัวอย่างการติดตามที่แสดงนโยบาย JavaScript ที่อัปเดตตัวแปรโฟลว์ target.url

      
   3. ในตัวอย่างการติดตามด้านบน โปรดสังเกตว่านโยบาย JavaScript ได้แก้ไขหรืออัปเดตค่าของ target.url ให้มีเส้นทางที่ไม่ถูกต้อง
   4. โปรดทราบว่า target.url มีองค์ประกอบต่อไปนี้
      • รูปแบบ: https
      • authority: mocktarget.apigee.net
      • เส้นทาง: ?json

      เส้นทางเริ่มต้นด้วยเครื่องหมายคำถาม (?) แทนเครื่องหมายทับ (/) จึงไม่ถูกต้อง

   บันทึก

   การใช้บันทึกในเซิร์ฟเวอร์บันทึก

   1. หากไม่มีการติดตามข้อผิดพลาดนี้ (ปัญหาเป็นครั้งคราว) ให้ตรวจสอบว่าคุณได้บันทึกข้อมูลเกี่ยวกับค่าของตัวแปรโฟลว์ target.url โดยใช้นโยบายต่างๆ เช่น MessageLogging หรือ ServiceCallout ไปยังเซิร์ฟเวอร์บันทึกแล้วหรือไม่
   2. หากมีบันทึก ให้ตรวจสอบและ
      1. ตรวจสอบว่า target.url มีเส้นทางที่ไม่ถูกต้องหรือไม่ และ
      2. ดูว่าคุณระบุข้อมูลเกี่ยวกับนโยบายที่แก้ไข target.url เพื่อให้มีเส้นทางที่ไม่ถูกต้องได้หรือไม่

   พร็อกซี API

   ตรวจสอบพร็อกซี API ที่ล้มเหลว

   หากไม่มีการติดตามหรือบันทึกสำหรับข้อผิดพลาดนี้ ให้ตรวจสอบพร็อกซี API ที่ล้มเหลว เพื่อพิจารณาว่าอะไรที่แก้ไขหรืออัปเดตตัวแปรโฟลว์ target.url ให้มีเส้นทางที่ไม่ถูกต้อง โปรดตรวจสอบสิ่งต่อไปนี้

   • นโยบายภายในพร็อกซี API
   • โฟลว์ที่แชร์ซึ่งเรียกใช้จากพร็อกซี

5. ตรวจสอบนโยบายที่เฉพาะเจาะจงอย่างละเอียด (เช่น AssignMessage หรือ JavaScript) ที่แก้ไขหรือ อัปเดตตัวแปรโฟลว์ target.url และพิจารณาสาเหตุของการ อัปเดต target.url ให้มีเส้นทางที่ไม่ถูกต้อง

   ตัวอย่างนโยบายบางส่วนที่อัปเดตตัวแปรโฟลว์ target.url อย่างไม่ถูกต้องให้มีเส้นทางที่ไม่ถูกต้องซึ่งทำให้เกิดข้อผิดพลาดนี้

   ตัวอย่างที่ 1

   ตัวอย่างที่ 1: การอัปเดตนโยบาย JavaScript target.url ตัวแปร

   var url = "https://mocktarget.apigee.net?json"
   context.setVariable("target.url", url);

   ในตัวอย่างข้างต้น โปรดสังเกตว่าตัวแปรโฟลว์ target.url ได้รับการอัปเดต ด้วยค่า https://mocktarget.apigee.net?json ที่อยู่ในตัวแปรอื่น url.

   โปรดทราบว่าค่าของ url มีองค์ประกอบต่อไปนี้

   • รูปแบบ: https
   • authority: mocktarget.apigee.net
   • เส้นทาง: ?json

   เส้นทางเริ่มต้นด้วยเครื่องหมายคำถาม (?) แทนเครื่องหมายทับ (/) ซึ่งไม่ถูกต้อง ดังนั้น Apigee Edge จึงแสดงผล 500 Internal Server Error พร้อมรหัสข้อผิดพลาด protocol.http.BadPath

   ตัวอย่าง #2

   ตัวอย่างที่ 2: การอัปเดตนโยบาย JavaScript target.url ตัวแปร ตามค่าในส่วนหัวของคำขอ

   var path = context.getVariable("request.header.Path");
   var url = "https://mocktarget.apigee.net" + path
   context.setVariable("target.url", url);

   ในตัวอย่างข้างต้น โปรดสังเกตว่าตัวแปรโฟลว์ target.url ได้รับการอัปเดต โดยการต่อค่า https://mocktarget.apigee.net ที่อยู่ใน ตัวแปร url และ ค่าของตัวแปรอื่น path ซึ่งดึงค่ามาจาก request.header.Path.

   หากคุณมีสิทธิ์เข้าถึงคำขอหรือการติดตามจริง คุณจะยืนยันค่าจริงที่ส่งไปยัง request.header.Path ได้

   คำขอตัวอย่างที่ผู้ใช้ส่ง

   curl -v https://HOST_ALIAS/v1/myproxy -H "Authorization: Bearer <token> -H "Path: ?user"
   

   ในตัวอย่างนี้ ระบบจะไม่ส่งเส้นทางส่วนหัวเป็นส่วนหนึ่งของคำขอ ดังนั้น ค่า ของตัวแปร path ในนโยบาย JavaScript คือ null

   ดังนั้น

   • url = https://mocktarget.apigee.net + path
   • url = https://mocktarget.apigee.net + "?user"
   • target.url = https://mocktarget.apigee.net?user

   โปรดทราบว่าค่าของ target.url มีองค์ประกอบต่อไปนี้

   • รูปแบบ: https
   • authority: mocktarget.apigee.net
   • เส้นทาง: ?user

   เส้นทางเริ่มต้นด้วยเครื่องหมายคำถาม (?) แทนเครื่องหมายทับ (/) ซึ่งไม่ถูกต้อง ดังนั้น Apigee Edge จึงแสดงผล 500 Internal Server Error พร้อมรหัสข้อผิดพลาด protocol.http.BadPath

   ตัวอย่างที่ 3

   ตัวอย่าง #3: การอัปเดตนโยบาย AssignMessage target.url ตัวแปร

   <AssignMessage async="false" continueOnError="false" enabled="true" name="AM-SetTargetURL">
       <DisplayName>AM-SetTargetURL</DisplayName>
       <AssignVariable>
            <Name>target.url</Name>
            <Value>https://mocktarget.apigee.net?echo</Value>
       </AssignVariable>
       <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
       <AssignTo createNew="false" transport="http" type="request"/>
   </AssignMessage>

   โปรดทราบว่าค่าของ url มีองค์ประกอบต่อไปนี้

   • รูปแบบ: https
   • authority: mocktarget.apigee.net
   • เส้นทาง: ?echo

   ในตัวอย่างนี้ เส้นทางจะเริ่มต้นด้วยเครื่องหมายคำถาม (?) แทนเครื่องหมายทับ (/) ซึ่งไม่ถูกต้อง ดังนั้น Apigee Edge จะแสดง 500 Internal Server Error พร้อมรหัสข้อผิดพลาด protocol.http.BadPath

ความละเอียด

ตามข้อกำหนด URL RFC 3986 ส่วนที่ 3: คอมโพเนนต์ไวยากรณ์ คอมโพเนนต์ path ต้องระบุ และต้องขึ้นต้นด้วย "/" เสมอ ดังนั้นให้ทำตามขั้นตอนด้านล่างเพื่อแก้ไขปัญหานี้

1. ตรวจสอบว่า URL ของเซิร์ฟเวอร์แบ็กเอนด์ซึ่งแสดงด้วยตัวแปรโฟลว์ target.url มีเส้นทางที่ถูกต้องเสมอ และขึ้นต้นด้วย เครื่องหมายทับ (/) เสมอ
   1. ในบางกรณี คุณอาจไม่มีชื่อทรัพยากรในเส้นทาง จากนั้นตรวจสอบว่าเส้นทางมีเครื่องหมายทับอย่างน้อย 1 ตัว (/)
   2. หากคุณใช้ตัวแปรอื่นๆ เพื่อกำหนดค่าของตัวแปรโฟลว์ target.url โปรดตรวจสอบว่าตัวแปรอื่นๆ ไม่มีเส้นทางที่ไม่ถูกต้อง
   3. หากคุณดำเนินการกับสตริงเพื่อกำหนดค่าของตัวแปรโฟลว์ target.url ให้ตรวจสอบว่าผลลัพธ์หรือผลของการดำเนินการกับสตริง ไม่มีเส้นทางที่ไม่ถูกต้อง

2. ในตัวอย่างที่กล่าวถึงข้างต้น คุณสามารถแก้ไขปัญหานี้ได้ตามที่อธิบายไว้ด้านล่าง

   ตัวอย่างที่ 1

   ตัวอย่างที่ 1: การอัปเดตนโยบาย JavaScript target.url ตัวแปร

   ใช้เครื่องหมายทับ (/) แทนเครื่องหมายคำถาม (?) ใน ตัวแปร url เพื่อแก้ไขปัญหานี้ตามที่แสดงด้านล่าง

   var url = "https://mocktarget.apigee.net/json"
   context.setVariable("target.url", url);

   ตัวอย่าง #2

   ตัวอย่างที่ 2: การอัปเดตนโยบาย JavaScript target.url ตัวแปร ตามค่าในส่วนหัวของคำขอ

   var path = context.getVariable("request.header.Path");
   var url = "https://mocktarget.apigee.net" + path
   context.setVariable("target.url", url);

   ตรวจสอบว่าคุณได้ส่งเส้นทางที่ถูกต้อง เช่น /user เป็นส่วนหนึ่งของคำขอ ส่วนหัว Path เพื่อแก้ไขปัญหานี้ตามที่แสดงด้านล่าง

   ตัวอย่างคำขอ:

   curl -v https://HOST_ALIAS/v1/myproxy -H "Authorization: Bearer <token> -H "Path: /user"
   

   ตัวอย่างที่ 3

   ตัวอย่าง #3: การอัปเดตนโยบาย AssignMessage target.url ตัวแปร

   เพิ่มเส้นทางที่ถูกต้องในองค์ประกอบ <Value> ของนโยบาย AssignMessage กล่าวคือ ให้แทนที่เครื่องหมายคำถาม (?) ด้วย เครื่องหมาย ทับ (/) ในองค์ประกอบ <Value> และ ตั้งค่าเป็น https://mocktarget.apigee.net/echo เพื่อแก้ไขปัญหานี้ตามที่แสดงด้านล่าง

   <AssignMessage async="false" continueOnError="false" enabled="true" name="AM-SetTargetURL">
       <DisplayName>AM-SetTargetURL</DisplayName>
       <AssignVariable>
            <Name>target.url</Name>
            <Value>https://mocktarget.apigee.net/echo</Value>
       </AssignVariable>
       <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
       <AssignTo createNew="false" transport="http" type="request"/>
   </AssignMessage>

   ข้อมูลจำเพาะ

   Apigee Edge คาดหวังว่าpath คอมโพเนนต์ ใน URL ของเซิร์ฟเวอร์แบ็กเอนด์ ต้องเริ่มต้นด้วย เครื่องหมายทับ (/) เสมอตามข้อกำหนดต่อไปนี้

   ข้อมูลจำเพาะ
   RFC 3986 ส่วนที่ 3: องค์ประกอบไวยากรณ์
   RFC 3986 ส่วนที่ 3.3: เส้นทาง

   หากยังต้องการความช่วยเหลือจากทีมสนับสนุนของ Apigee โปรดไปที่ต้องรวบรวม ข้อมูลการวินิจฉัย

   ต้องรวบรวมข้อมูลการวินิจฉัย

   หากยังพบปัญหาอยู่แม้จะทำตามวิธีการข้างต้นแล้ว ให้รวบรวมข้อมูลการวินิจฉัยต่อไปนี้ แล้วติดต่อทีมสนับสนุนของ Apigee Edge

   หากคุณเป็นผู้ใช้ระบบคลาวด์สาธารณะ โปรดระบุข้อมูลต่อไปนี้

   • ชื่อองค์กร
   • ชื่อสภาพแวดล้อม
   • ชื่อพร็อกซี API
   • คำสั่ง curl ที่สมบูรณ์ซึ่งใช้ในการสร้าง 500 Internal Server Error ซ้ำโดยมีรหัสข้อผิดพลาด protocol.http.BadPath
   • ไฟล์การติดตามสำหรับคำขอ API

   หากคุณเป็นผู้ใช้ Private Cloud โปรดระบุข้อมูลต่อไปนี้

   • ข้อความแสดงข้อผิดพลาดทั้งหมดที่พบสำหรับคำขอที่ไม่สำเร็จ
   • ชื่อสภาพแวดล้อม
   • แพ็กเกจพร็อกซี API
   • ไฟล์การติดตามสำหรับคำขอ API

   • บันทึกการเข้าถึง NGINX

     /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

     โดยที่ ORG, ENV และ PORT# จะถูกแทนที่ด้วย ค่าจริง

   • บันทึกของระบบ Message Processor /opt/apigee/var/log/edge-message- processor/logs/system.log

   ข้อมูลอ้างอิง

   ตัวแปรโฟลว์ - เป้าหมาย