หน้านี้ได้รับการแปลโดย 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 สาธารณะและ Private Cloud

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

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

การตรวจสอบ API

ขั้นตอนที่ 1: การใช้การตรวจสอบ API

วิธีวินิจฉัยข้อผิดพลาดโดยใช้การตรวจสอบ API

ลงชื่อเข้าใช้ Apigee Edge UI ในฐานะผู้ใช้ที่มี บทบาทที่เหมาะสม
เปลี่ยนเป็นองค์กรที่ต้องการตรวจสอบปัญหา
ไปที่ วิเคราะห์ > การตรวจสอบ 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
ตรวจสอบว่าเปิดใช้แสดง FlowInfo ทั้งหมด แล้ว
เลือกคำขอที่ไม่สำเร็จรายการหนึ่งและตรวจสอบการติดตาม
ดำเนินการตามขั้นตอนต่างๆ ของการติดตามและค้นหาตำแหน่งที่เกิดข้อผิดพลาด
โดยปกติแล้วคุณจะพบข้อผิดพลาดในขั้นตอนหลังจากที่เริ่มต้นขั้นตอนคำขอเป้าหมาย แล้ว ตามที่แสดงด้านล่าง
บันทึกค่าของข้อผิดพลาดจากการติดตามดังนี้

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

เนื่องจากข้อผิดพลาดเกิดขึ้นโดย 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
เนื่องจากคอมโพเนนต์ path เริ่มต้นด้วยเครื่องหมายคำถาม (?) แทนที่จะเป็นเครื่องหมายทับ (/) คุณจะได้รับข้อผิดพลาด Invalid request path
ไปที่ระยะ AX (Analytics Data Recorded) ในการติดตามและคลิก
เลื่อนลงไปที่ส่วน 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) มีเส้นทางที่ไม่ถูกต้อง

การวินิจฉัย

ระบุรหัสข้อผิดพลาดและแหล่งที่มาของข้อผิดพลาดสำหรับ 500 Internal Server Error โดยใช้การตรวจสอบ API, เครื่องมือการติดตาม หรือบันทึกการเข้าถึง NGINX ตามที่อธิบายไว้ใน ขั้นตอนการวิเคราะห์ทั่วไป
หาก Fault Code คือ protocol.http.BadPath และ Fault Source มี ค่า 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 โดยใช้นโยบายต่างๆ เช่น MessageLcking หรือ นโยบาย Serviceข้อความไฮไลต์ ไปยังเซิร์ฟเวอร์บันทึก
2. หากคุณมีบันทึก ให้ตรวจสอบบันทึกเหล่านั้นและ
  1. ตรวจสอบว่า target.url มีเส้นทางที่ไม่ถูกต้องหรือไม่ และ
  2. ดูว่าคุณระบุข้อมูลเกี่ยวกับนโยบายที่มีการแก้ไขได้หรือไม่ target.url เพื่อให้มีเส้นทางที่ไม่ถูกต้อง
พร็อกซี API

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

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

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

ตัวอย่างที่ 1: การอัปเดตตัวแปร target.url เกี่ยวกับนโยบาย JavaScript
```
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: การอัปเดตตัวแปร target.url เกี่ยวกับนโยบาย JavaScript ตามค่าในส่วนหัวของคำขอ
```
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: การอัปเดตตัวแปร target.url ของนโยบาย AssignMessage
```
<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: การอัปเดตตัวแปร target.url เกี่ยวกับนโยบาย JavaScript

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

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

ตัวอย่าง #2

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

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: การอัปเดตตัวแปร target.url ของนโยบาย AssignMessage

เพิ่มเส้นทางที่ถูกต้องในองค์ประกอบ <Value> ของนโยบาย AssignMessage นั่นคือ แทนที่เครื่องหมายคำถาม (?) ด้วย a เครื่องหมายทับ (/) ในองค์ประกอบ <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

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

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

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