หน้านี้ได้รับการแปลโดย Cloud Translation API

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

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

ลักษณะปัญหา

แอปพลิเคชันไคลเอ็นต์จะได้รับรหัสสถานะ 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: เส้นทาง

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

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

คุณต้องระบุคอมโพเนนต์ path โดยต้องเริ่มต้นด้วยเครื่องหมายทับ (/) เสมอ

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

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

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

ขั้นตอนการวินิจฉัยทั่วไป

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

การตรวจสอบ API

ขั้นตอนที่ 1: การใช้ API Monitoring

วิธีวินิจฉัยข้อผิดพลาดโดยใช้ API Monitoring

ลงชื่อเข้าใช้ UI ของ Apigee Edge ในฐานะผู้ใช้ที่มี บทบาทที่เหมาะสม
เปลี่ยนเป็นองค์กรที่คุณต้องการตรวจสอบปัญหา
ไปที่หน้าวิเคราะห์ > การตรวจสอบ API > ตรวจสอบ
เลือกกรอบเวลาเฉพาะที่คุณพบข้อผิดพลาด
พล็อตโค้ดข้อผิดพลาดเทียบกับเวลา

หมายเหตุ: คุณยังพล็อตรหัสสถานะกับเวลาได้ด้วย
เลือกเซลล์ที่มีรหัสข้อผิดพลาด protocol.http.BadPath ดังที่แสดงด้านล่าง
ข้อมูลเกี่ยวกับรหัสข้อผิดพลาด protocol.http.BadPath จะแสดงอยู่ดังที่แสดงด้านล่าง
คลิกดูบันทึก แล้วขยายแถวสำหรับคำขอที่ไม่สำเร็จ
ดูรายละเอียดต่อไปนี้จากหน้าต่าง Logs
- รหัสสถานะ: 500
- แหล่งที่มาของข้อผิดพลาด: target
- รหัสข้อผิดพลาด: protocol.http.BadPath
หากแหล่งที่มาของข้อผิดพลาดคือ target และรหัสข้อผิดพลาดคือ protocol.http.BadPath แสดงว่า URL ของเซิร์ฟเวอร์แบ็กเอนด์มีเส้นทางที่ไม่ถูกต้อง

Trace

ขั้นตอนที่ 2: การใช้เครื่องมือติดตาม

วิธีวินิจฉัยข้อผิดพลาดโดยใช้เครื่องมือติดตาม

เปิดใช้เซสชันการติดตามและ
- รอจนกว่าจะเกิดข้อผิดพลาด 500 Internal Server Error หรือ
- หากทำให้ปัญหาเกิดซ้ำได้ ให้เรียก API เพื่อจำลองปัญหา 500 Internal Server Error
ตรวจสอบว่าเปิดใช้ Show FlowInfos ทั้งหมดแล้ว โดยทำดังนี้
เลือกคำขอที่ล้มเหลว 1 รายการและตรวจสอบการติดตาม
เลื่อนดูการติดตามระยะต่างๆ และค้นหาตำแหน่งที่เกิดข้อผิดพลาด
คุณจะเห็นข้อผิดพลาดโดยทั่วไปในขั้นตอนหลังช่วงเริ่มต้นโฟลว์คำขอเป้าหมาย ดังที่แสดงด้านล่าง
สังเกตค่าของข้อผิดพลาดจากการติดตาม ดังนี้

ข้อผิดพลาด: เส้นทางคำขอไม่ถูกต้อง

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

ในการติดตามตัวอย่างที่แสดงข้างต้น โปรดทราบว่าระบบจะอัปเดตค่าของตัวแปรโฟลว์ target.url ในนโยบาย JavaScript ที่ชื่อ JS- SetTargetURL ดังนี้ target.url : https://mocktarget.apigee.net?json
โปรดทราบว่าค่าใน target.url มีคอมโพเนนต์ต่อไปนี้
- แบบแผน: https
- หน่วยงาน: mocktarget.apigee.net
- เส้นทาง: ?json
เนื่องจากคอมโพเนนต์เส้นทางขึ้นต้นด้วยเครื่องหมายคำถาม (?) แทนเครื่องหมายทับ (/) คุณจึงได้รับข้อผิดพลาดInvalid request path
ไปที่เฟส AX (บันทึกข้อมูล Analytics) ในการติดตามแล้วคลิกเลือกดังกล่าว
เลื่อนลงไปที่ส่วน Phase Details - Error Headers และระบุค่าของ X-Apigee-fault-code และ X-Apigee-fault-source ดังที่แสดงด้านล่าง

คุณจะเห็นค่าของ X-Apigee-fault-code และ X-Apigee-fault-source เป็น protocol.http.BadPath และtarget ตามลำดับ ซึ่งหมายความว่าข้อผิดพลาดนี้เกิดจาก URL ของเซิร์ฟเวอร์แบ็กเอนด์มีเส้นทางที่ไม่ถูกต้อง

ส่วนหัวการตอบกลับ	ค่า
X-Apigee-fault-code	`protocol.http.BadPath`
X-Apigee-fault-source	`target`

NGINX

ขั้นตอนที่ 3: การใช้บันทึกการเข้าถึง NGINX

วิธีวินิจฉัยข้อผิดพลาดโดยใช้บันทึกการเข้าถึง NGINX

หากเป็นผู้ใช้ Private Cloud คุณจะใช้บันทึกการเข้าถึง NGINX เพื่อระบุข้อมูลคีย์เกี่ยวกับ HTTP 500 Internal Server Error ได้
ตรวจสอบบันทึกการเข้าถึง NGINX ดังนี้

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

หมายเหตุ: แทนที่ ORG, ENV และ PORT# ด้วยค่าจริง
ค้นหาเพื่อดูว่ามีข้อผิดพลาด 500 ที่มีรหัสข้อผิดพลาด protocol.http.BadPath ในช่วงเวลาที่ระบุหรือไม่ (หากเกิดปัญหาในอดีต) หรือมีคำขอใดที่ยังคงดำเนินการไม่สำเร็จเมื่อใช้ 500

หากพบข้อผิดพลาด 500 ที่ X-Apigee-fault-code ตรงกับค่าของ protocol.http.BadPath ให้ระบุค่าของ X- Apigee-fault-source

ตัวอย่างข้อผิดพลาด 500 จากบันทึกการเข้าถึง NGINX

ตัวอย่างรายการด้านบนจากบันทึกการเข้าถึง NGINX มีค่าต่อไปนี้สำหรับ X-Apigee- fault-code และ X-Apigee-fault-source

ส่วนหัว	ค่า
X-Apigee-fault-code	`protocol.http.BadPath`
X-Apigee-fault-source	`target`

โปรดสังเกตว่าค่าของ X-Apigee-fault-code และ X-Apigee-fault-source คือ protocol.http.BadPath และtarget ตามลำดับซึ่งบ่งชี้ว่าข้อผิดพลาดนี้เกิดขึ้นเนื่องจาก URL เซิร์ฟเวอร์แบ็กเอนด์มีเส้นทางที่ไม่ถูกต้อง

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

การวินิจฉัย

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

หมายเหตุ: Apigee Edge จะถือว่า path ใน URL ของเซิร์ฟเวอร์แบ็กเอนด์เป็นไม่ถูกต้องหากเส้นทางขึ้นต้นด้วย เครื่องหมายคำถาม (?) แทนเครื่องหมายทับ (/) ตามข้อกำหนดของ URL RFC 3986 ส่วนที่ 3.3: เส้นทาง
พิจารณาว่าตัวแปรโฟลว์ target.url มีเส้นทาง ที่ไม่ถูกต้องจริงหรือไม่ และแหล่งที่มาของค่าโดยใช้วิธีใดวิธีหนึ่งต่อไปนี้
Trace

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

หากคุณบันทึกการติดตามสำหรับข้อผิดพลาดนี้แล้ว ให้ใช้ขั้นตอนตามที่อธิบายไว้ในการใช้เครื่องมือติดตาม และ
1. ตรวจสอบว่า target.url มีเส้นทางที่ไม่ถูกต้องหรือไม่ นั่นคือขึ้นต้นด้วยเครื่องหมายคำถาม (?) แทนเครื่องหมายทับ (/)
2. หากใช่ ให้ดูนโยบายที่แก้ไขหรืออัปเดตค่าของ target.url ให้มีเส้นทางที่ไม่ถูกต้อง
  
  การติดตามตัวอย่างที่แสดงนโยบาย JavaScript ได้อัปเดตตัวแปรโฟลว์ target.url
3. ในการติดตามตัวอย่างด้านบน สังเกตว่านโยบาย JavaScript ได้แก้ไขหรืออัปเดตค่าของ target.url ให้มีเส้นทางที่ไม่ถูกต้อง
4. โปรดทราบว่า target.url มีคอมโพเนนต์ต่อไปนี้
  - แบบแผน: https
  - หน่วยงาน: mocktarget.apigee.net
  - เส้นทาง: ?json
  เส้นทางจะขึ้นต้นด้วยเครื่องหมายคำถาม (?) แทนเครื่องหมายทับ (/) จึงไม่ถูกต้อง
บันทึก

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

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

หากไม่มีการติดตามหรือบันทึกสำหรับข้อผิดพลาดนี้ ให้ตรวจสอบพร็อกซี API ที่ล้มเหลวเพื่อหาสิ่งที่แก้ไขหรืออัปเดตตัวแปรโฟลว์ target.url ให้มีเส้นทางที่ไม่ถูกต้อง โปรดตรวจสอบสิ่งต่อไปนี้
- นโยบายภายในพร็อกซี API
- โฟลว์ที่แชร์ซึ่งเรียกใช้จากพร็อกซี
โปรดตรวจสอบนโยบายที่เฉพาะเจาะจง (เช่น 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
- หน่วยงาน: 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
- หน่วยงาน: 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
- หน่วยงาน: mocktarget.apigee.net
- เส้นทาง: ?echo
ในตัวอย่างนี้ เส้นทางจะขึ้นต้นด้วยเครื่องหมายคำถาม (?) แทนเครื่องหมายทับ (/) ซึ่งไม่ถูกต้อง ดังนั้น Apigee Edge จะส่งคืน 500 Internal Server Error ที่มีรหัสข้อผิดพลาด protocol.http.BadPath

ความละเอียด

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

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

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

ตัวอย่าง #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# ด้วยค่าจริง
บันทึกระบบของผู้ประมวลผลข้อความ /opt/apigee/var/log/edge-message- processor/logs/system.log

รายการอ้างอิง

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

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

ลักษณะปัญหา

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

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

ขั้นตอนการวินิจฉัยทั่วไป

การตรวจสอบ API

Trace

NGINX

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

การวินิจฉัย

Trace

บันทึก

พร็อกซี API

ตัวอย่าง #1

ตัวอย่าง #2

ตัวอย่าง #3

ความละเอียด

ตัวอย่าง #1

ตัวอย่าง #2

ตัวอย่าง #3

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

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

รายการอ้างอิง