413 เอนทิตีที่ขอใหญ่เกินไป - TooBigBody

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

ลักษณะปัญหา

แอปพลิเคชันไคลเอ็นต์จะได้รับรหัสสถานะ HTTP 413 Request Entity Too Large พร้อมรหัสข้อผิดพลาด protocol.http.TooBigBody เป็นการตอบกลับสำหรับการเรียก API

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

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

HTTP/1.1 413 Request Entity Too Large

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

{
   "fault":{
      "faultstring":"Body buffer overflow",
      "detail":{
         "errorcode":"protocol.http.TooBigBody"
      }
   }
}

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

ข้อผิดพลาดนี้เกิดขึ้นหากขนาดเพย์โหลดที่แอปพลิเคชันไคลเอ็นต์ส่งไปยัง Apigee Edge เป็นส่วนหนึ่งของ คำขอ HTTP มีค่ามากกว่าขีดจำกัดที่อนุญาตใน Apigee Edge

สาเหตุที่เป็นไปได้สำหรับข้อผิดพลาดนี้มีดังนี้

สาเหตุ คำอธิบาย วิธีการแก้ปัญหาที่ใช้ได้กับ
ขนาดเพย์โหลดของคำขอมากกว่าขีดจำกัดที่อนุญาต เพย์โหลดที่แอปพลิเคชันไคลเอ็นต์ส่งเป็นส่วนหนึ่งของคำขอ HTTP ไปยัง Apigee Edge มีขนาด มากกว่าขีดจำกัดที่อนุญาตใน Apigee Edge ผู้ใช้ Edge Public และ Private Cloud
ขนาดเพย์โหลดของคำขอเกินขีดจำกัดที่อนุญาตหลังจาก คลายการบีบอัด ขนาดเพย์โหลดที่แอปพลิเคชันไคลเอ็นต์ส่งในรูปแบบที่บีบอัดเป็นส่วนหนึ่งของคำขอ HTTP ไปยัง Apigee Edge มีขนาดมากกว่าขีดจำกัดที่อนุญาตเมื่อ Apigee Edge คลายการบีบอัด ผู้ใช้ Edge Public และ Private Cloud

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

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

การตรวจสอบ API

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

  1. ลงชื่อเข้าใช้ UI ของ Apigee Edge ในฐานะผู้ใช้ที่มี บทบาทที่เหมาะสม

  2. เปลี่ยนไปใช้องค์กรที่คุณต้องการตรวจสอบปัญหา

  3. ไปที่หน้าวิเคราะห์ > การตรวจสอบ API > ตรวจสอบ
  4. เลือกกรอบเวลาที่เฉพาะเจาะจงซึ่งคุณพบข้อผิดพลาด
  5. คุณอาจเลือกตัวกรองพร็อกซีเพื่อจำกัดรหัสข้อผิดพลาดให้แคบลง
  6. พล็อตรหัสข้อบกพร่องเทียบกับเวลา

  7. เลือกเซลล์ที่มีรหัสข้อผิดพลาด protocol.http.TooBigBody และ รหัสสถานะ 413ตามที่แสดงด้านล่าง

  8. ข้อมูลเกี่ยวกับรหัสข้อผิดพลาด protocol.http.TooBigBody จะแสดงดังที่ แสดงด้านล่าง

  9. คลิกดูบันทึก แล้วขยายแถวสำหรับคำขอที่ไม่สำเร็จ จากนั้นในหน้าต่างบันทึก ให้จดรายละเอียดตามที่แสดงด้านล่าง

    ไม่มีการบีบอัด

    สถานการณ์ #1: ส่งเพย์โหลดคำขอในรูปแบบที่ไม่ได้บีบอัด

    จากหน้าต่างบันทึก ให้จดรายละเอียดต่อไปนี้

    • รหัสสถานะ: 413
    • แหล่งที่มาของข้อผิดพลาด: proxy
    • รหัสข้อบกพร่อง: protocol.http.TooBigBody
    • ความยาวของคำขอ(ไบต์): 15360440 (~15 MB)

    หากแหล่งที่มาของข้อผิดพลาดมีค่า proxy, รหัสข้อผิดพลาด มีค่า protocol.http.TooBigBody และความยาวของคำขอ มากกว่า 10 MB แสดงว่าคำขอ HTTP จากไคลเอ็นต์มี เพย์โหลดของคำขอขนาดใหญ่กว่าขีดจำกัดที่อนุญาตใน Apigee

    ขนาดไฟล์ที่บีบอัด

    สถานการณ์ #2: ส่งเพย์โหลดคำขอในรูปแบบที่บีบอัด

    จากหน้าต่างบันทึก ให้จดรายละเอียดต่อไปนี้

    • รหัสสถานะ: 413
    • แหล่งที่มาของข้อผิดพลาด: proxy
    • รหัสข้อบกพร่อง: protocol.http.TooBigBody
    • ความยาวของคำขอ(ไบต์): 15264 (~15kB)

    หากแหล่งที่มาของข้อผิดพลาดมีค่า proxy , รหัสข้อผิดพลาด มีค่า protocol.http.TooBigBody และความยาวของคำขอน้อยกว่า 10 MB แสดงว่าคำขอ HTTP จากไคลเอ็นต์มี ขนาดเพย์โหลดของคำขอน้อยกว่าขีดจำกัดที่อนุญาตในรูปแบบที่บีบอัด แต่ ขนาดเพย์โหลดมากกว่าขีดจำกัดที่อนุญาตเมื่อ Apigee ยกเลิกการบีบอัด

Trace

วิธีวิเคราะห์ข้อผิดพลาดโดยใช้เครื่องมือติดตาม

  1. เปิดใช้เซสชันการติดตามและอย่างใดอย่างหนึ่งต่อไปนี้
    • รอให้เกิดข้อผิดพลาด 413 Request Entity Too Large หรือ
    • หากทำให้เกิดปัญหาได้อีกครั้ง ให้เรียก API และทำให้เกิด 413 Request Entity Too Large ข้อผิดพลาด

  2. ตรวจสอบว่าได้เปิดใช้แสดงข้อมูลโฟลว์ทั้งหมดแล้ว

  3. เลือกคำขอที่ล้มเหลวรายการใดรายการหนึ่ง แล้วตรวจสอบการติดตาม
  4. ไปที่ระยะได้รับคำขอจากลูกค้า

    ไม่มีการบีบอัด

    สถานการณ์ #1: ส่งเพย์โหลดคำขอในรูปแบบที่ไม่ได้บีบอัด

    โปรดทราบข้อมูลต่อไปนี้

    • Content-Encoding: ไม่มี
    • Content-Length: 15360204

    ขนาดไฟล์ที่บีบอัด

    สถานการณ์ #2: ส่งเพย์โหลดคำขอในรูปแบบที่บีบอัด

    โปรดทราบข้อมูลต่อไปนี้

    • Content-Encoding: gzip
    • Content-Length: 14969
    • Content-Type: application/x-gzip
  5. ไปยังส่วนต่างๆ ของการติดตาม และค้นหาจุดที่เกิดข้อผิดพลาด

  6. โดยปกติคุณจะพบข้อผิดพลาดในโฟลว์หลังจากระยะได้รับคำขอจาก ไคลเอ็นต์ ดังที่แสดงด้านล่าง

  7. จดค่าของข้อผิดพลาดจากร่องรอย การติดตามตัวอย่างข้างต้นแสดงข้อมูลต่อไปนี้
    • ข้อผิดพลาด: Body buffer overflow
    • error.class: com.apigee.errors.http.user.RequestTooLarge

  8. ไปที่การตอบกลับที่ส่งไปยังไคลเอ็นต์และจดค่าของข้อผิดพลาดจาก การติดตาม การติดตามตัวอย่างด้านล่างแสดงสิ่งต่อไปนี้

    • ข้อผิดพลาด: 413 Request Entity Too Large
    • เนื้อหาข้อผิดพลาด: {"fault":{"faultstring":"Body buffer overflow","detail":{"errorcode":"protocol.http.TooBigBody"}}}
  9. ไปที่เฟส AX (บันทึกข้อมูลวิเคราะห์) ในการติดตาม แล้วคลิก

  10. ในส่วนรายละเอียดระยะ ให้เลื่อนลงไปที่ตัวแปรที่อ่าน

  11. กำหนดค่าของตัวแปร client.received.content.length ซึ่งระบุสิ่งต่อไปนี้
    • ขนาดจริงของเพย์โหลดคำขอเมื่อส่งในรูปแบบที่ไม่ได้บีบอัด และ
    • ขนาดของเพย์โหลดคำขอเมื่อ Apigee คลายการบีบอัด เมื่อส่งเพย์โหลดในรูปแบบที่บีบอัด ซึ่งจะมีค่าเท่ากับค่าของขีดจำกัดที่อนุญาต (10 MB) ในสถานการณ์นี้เสมอ

    ไม่มีการบีบอัด

    สถานการณ์ที่ 1: เพย์โหลดคำขอในรูปแบบที่ไม่ได้บีบอัด

    ตัวแปร client.received.content.length: 15360204

    ขนาดไฟล์ที่บีบอัด

    สถานการณ์ #2: ขอเพย์โหลดคำขอในรูปแบบที่บีบอัด

    ตัวแปร client.received.content.length: 10489856

  12. ตารางต่อไปนี้อธิบายสาเหตุที่ Apigee แสดงข้อผิดพลาด 413 ใน 2 สถานการณ์ตามค่าของตัวแปร client.received.content.length
    สถานการณ์ ค่าของ client.received.content.length สาเหตุที่ทำให้ย้ายข้อมูลไม่สำเร็จ
    เพย์โหลดคำขอในรูปแบบที่ไม่ได้บีบอัด ~15 MB ขนาด > ขีดจำกัดที่อนุญาต 10 MB
    เพย์โหลดคำขอในรูปแบบที่บีบอัด ~10 MB

    ขนาดเกินขีดจำกัดเมื่อคลายการบีบอัด

NGINX

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

  1. หากเป็นผู้ใช้ Private Cloud คุณจะใช้บันทึกการเข้าถึง NGINX เพื่อระบุข้อมูลสำคัญเกี่ยวกับข้อผิดพลาด HTTP 413 ได้

  2. ตรวจสอบบันทึกการเข้าถึง NGINX

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

  3. ค้นหาเพื่อดูว่ามี413ข้อผิดพลาดในช่วงระยะเวลาที่เฉพาะเจาะจงหรือไม่ (หากปัญหาเกิดขึ้นในอดีต) หรือมีคำขอที่ยังคงล้มเหลวด้วย413หรือไม่
  4. หากพบ413ข้อผิดพลาดที่ตรงกับX-Apigee-fault-code ค่าของ protocol.http.TooBigBody ให้พิจารณาค่าของ X-Apigee-fault-source

    ไม่มีการบีบอัด

    สถานการณ์ที่ 1 : ขนาดเพย์โหลดคำขอในรูปแบบที่ไม่ได้บีบอัด

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

    ส่วนหัวการตอบกลับ ค่า
    X-Apigee-fault-code protocol.http.TooBigBody
    X-Apigee-fault-sourc policy

    โปรดทราบว่าความยาวของคำขอ: 15360440 (14.6 MB > ขีดจำกัดที่อนุญาต)

    ขนาดไฟล์ที่บีบอัด

    สถานการณ์ #2 : ขนาดเพย์โหลดของคำขอในรูปแบบที่บีบอัด

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

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

    โปรดทราบว่าความยาวของคำขอ: 15264 (14.9 K < ขีดจำกัดที่อนุญาต)

    ในสถานการณ์นี้ Apigee Edge จะแสดง 413 แม้ว่าความยาวของคำขอจะต่ำกว่าขีดจำกัดที่อนุญาต เนื่องจากคำขออาจถูกส่งในรูปแบบที่บีบอัด และขนาดของเพย์โหลดเกินขีดจำกัดเมื่อ Apigee Edge ทำการคลายการบีบอัด

สาเหตุ: ขนาดเพย์โหลดของคำขอใหญ่กว่าขีดจำกัดที่อนุญาต

การวินิจฉัย

  1. กำหนดรหัสข้อผิดพลาด แหล่งที่มาของข้อผิดพลาด และขนาดเพย์โหลดของคำขอสำหรับ ข้อผิดพลาดที่สังเกตได้โดยใช้การตรวจสอบ API, เครื่องมือติดตาม หรือบันทึกการเข้าถึง NGINX ตามที่อธิบายไว้ใน ขั้นตอนการวินิจฉัยที่พบบ่อยในสถานการณ์ #1 (ไม่ได้บีบอัด)
  2. หาก Fault Source มีค่าเป็น policy หรือ proxy แสดงว่าขนาดเพย์โหลดของคำขอที่แอปพลิเคชันไคลเอ็นต์ส่งไปยัง Apigee มากกว่าขีดจำกัดที่อนุญาตใน Apigee Edge
  3. ตรวจสอบขนาดเพย์โหลดของคำขอตามที่กำหนดจากขั้นตอนที่ 1
  4. นอกจากนี้ คุณยังตรวจสอบได้ว่าขนาดเพย์โหลดของคำขอมีขนาดเกินกว่าขีดจำกัดที่อนุญาต 10 MB จริงหรือไม่ โดย ตรวจสอบคำขอจริงโดยทำตามขั้นตอนต่อไปนี้
    1. หากคุณไม่มีสิทธิ์เข้าถึงคำขอจริงที่แอปพลิเคชันไคลเอ็นต์ส่งมา ให้ไปที่ การแก้ปัญหา
    2. หากคุณมีสิทธิ์เข้าถึงคำขอจริงที่แอปพลิเคชันไคลเอ็นต์ส่งมา ให้ทำตามขั้นตอนต่อไปนี้
      1. ยืนยันขนาดของเพย์โหลดที่ส่งในคำขอ
      2. หากพบว่าเพย์โหลดมีขนาดเกิน ขีดจำกัดที่อนุญาตใน Apigee Edge แสดงว่านั่นคือสาเหตุของปัญหา

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

        curl http://<hostalias>/testtoobigbody -k -X POST -F file=@test15mbfile -v

        ในกรณีข้างต้น ไฟล์ test15mbfile มีขนาดประมาณ 15 MB หากคุณ ใช้ไคลเอ็นต์อื่น ให้รับบันทึกไคลเอ็นต์เพื่อดูขนาดเพย์โหลดที่ส่ง

ความละเอียด

ไปที่ความละเอียด

สาเหตุ: ขนาดเพย์โหลดของคำขอเกินขีดจำกัดที่อนุญาตหลังจากคลายการบีบอัด

หากส่งเพย์โหลดของคำขอในรูปแบบที่บีบอัดและตั้งค่าส่วนหัวของคำขอ Content-Encodingเป็น gzip, Apigee จะคลายการบีบอัดเพย์โหลด ของคำขอ ในระหว่างกระบวนการคลายการบีบอัด หาก Apigee พบว่าขนาดของเพย์โหลดมีขนาดใหญ่กว่า 10 MB ขีดจำกัดที่อนุญาต ระบบจะหยุดการคลายการบีบอัดเพิ่มเติมและตอบกลับ ทันทีด้วย 413 Request Entity Too Large พร้อมรหัสข้อผิดพลาด protocol.http.TooBigBody

การวินิจฉัย

  1. ระบุรหัสข้อผิดพลาด แหล่งที่มาของข้อผิดพลาด และขนาดเพย์โหลดของคำขอ สำหรับข้อผิดพลาดที่สังเกตได้โดยใช้การตรวจสอบ API, เครื่องมือติดตาม หรือบันทึกการเข้าถึง NGINX ตามที่อธิบายไว้ใน ขั้นตอนการวินิจฉัยทั่วไปที่มีสถานการณ์ #2 (บีบอัด)
  2. หาก Fault Source มีค่าเป็น policy หรือ proxy แสดงว่า ขนาดเพย์โหลดของคำขอที่แอปพลิเคชันไคลเอ็นต์ส่งไปยัง Apigee มีขนาดใหญ่กว่า ขีดจำกัดที่อนุญาตใน Apigee Edge
  3. ตรวจสอบขนาดเพย์โหลดของคำขอตามที่กำหนดจากขั้นตอนที่ 1
    • หากขนาดเพย์โหลด > ขีดจำกัดที่อนุญาต 10 MB แสดงว่านั่นคือสาเหตุของข้อผิดพลาด
    • หากขนาดเพย์โหลดน้อยกว่าขีดจำกัดที่อนุญาต 10 MB แสดงว่าอาจมีการส่งเพย์โหลดคำขอในรูปแบบที่บีบอัด ในกรณีนี้ ให้ตรวจสอบขนาดที่ไม่ได้บีบอัดของ เพย์โหลดคำขอที่บีบอัด
  4. คุณตรวจสอบได้ว่าคำขอจากไคลเอ็นต์ถูกส่งในรูปแบบที่บีบอัดหรือไม่ และขนาดที่ ไม่ได้บีบอัดมีขนาดใหญ่กว่าขีดจำกัดที่อนุญาตหรือไม่ โดยใช้วิธีการใดวิธีการหนึ่งต่อไปนี้

    Trace

    วิธีตรวจสอบความถูกต้องโดยใช้เครื่องมือติดตาม

    1. หากคุณบันทึกการติดตามสำหรับคำขอที่ไม่สำเร็จ โปรดดูขั้นตอนโดยละเอียดใน Trace และ
      1. กำหนดค่าของตัวแปร client.received.content.length
      2. ตรวจสอบว่าคำขอจากไคลเอ็นต์มีส่วนหัว Content-Encoding: gzip หรือไม่
    2. หากค่าของตัวแปร client.received.content.length มากกว่า 10 MB ขีดจำกัดที่อนุญาต และส่วนหัวของคำขอ Content-Encoding: gzip นั่นคือสาเหตุของข้อผิดพลาดนี้

    คำขอจริง

    วิธีตรวจสอบโดยใช้คำขอจริง

    1. หากคุณไม่มีสิทธิ์เข้าถึงคำขอจริงที่แอปพลิเคชันไคลเอ็นต์ส่งมา ให้ไปที่การแก้ปัญหา
    2. หากคุณมีสิทธิ์เข้าถึงคำขอจริงที่แอปพลิเคชันไคลเอ็นต์ส่งมา ให้ทำตามขั้นตอนต่อไปนี้
      1. ยืนยันขนาดของเพย์โหลดที่ส่งในคำขอพร้อมกับส่วนหัว Content-Encoding ที่ส่งในคำขอ

      2. ตรวจสอบว่าขนาดเพย์โหลดที่ไม่ได้บีบอัดมีขนาดมากกว่า ขีดจำกัดที่อนุญาตใน Apigee Edge หรือไม่

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

        curl https://<hostalias>/testtoobigbody -k -X POST -F file=@test15mbfile.gz -H "Content-Encoding: gzip" -v

        ในกรณีข้างต้น ไฟล์ test15mbfile.gz มีขนาดไม่เกินขีดจำกัด แต่ไฟล์ test15mbfile ที่ไม่ได้บีบอัดมีขนาดประมาณ 15 MB และ ส่วนหัว Content-Encoding มีขนาด gzip

        หากคุณใช้ไคลเอ็นต์อื่น ให้รับบันทึกไคลเอ็นต์เพื่อดูขนาดเพย์โหลด ที่ส่งและดูว่ามีการตั้งค่าส่วนหัว Content-Encoding เป็น gzip หรือไม่

    บันทึกของ Message Processor

    วิธีตรวจสอบความถูกต้องโดยใช้บันทึกของ Message Processor

    1. หากเป็นผู้ใช้ Private Cloud คุณจะใช้บันทึกของ Message Processor เพื่อระบุ ข้อมูลสำคัญเกี่ยวกับข้อผิดพลาดของ HTTP 413 ได้

    2. ตรวจสอบบันทึกของ Message Processor

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

    3. ค้นหาเพื่อดูว่ามี413ข้อผิดพลาดในช่วงระยะเวลาที่เฉพาะเจาะจงหรือไม่ (หากปัญหาเกิดขึ้นในอดีต) หรือมีคำขอใดที่ยังคงล้มเหลวด้วย 413

      คุณอาจใช้สตริงการค้นหาต่อไปนี้

      grep -ri "chunkCount"

      grep -ri "RequestTooLarge"
    4. คุณจะเห็นบรรทัดจาก system.log คล้ายกับตัวอย่างต่อไปนี้ (TotalRead และ chunkCount อาจแตกต่างกันในกรณีของคุณ) 
      2021-07-06 13:29:57,544  NIOThread@1 ERROR HTTP.SERVICE -
  TrackingInputChannel.checkMessageBodyTooLarge()
  : Message is too large.  TotalRead 10489856 chunkCount 2570

2021-07-06 13:29:57,545  NIOThread@1 INFO  HTTP.SERVICE -
  ExceptionHandler.handleException()
  : Exception trace: com.apigee.errors.http.user.RequestTooLarge
  : Body buffer overflow
    5. ในระหว่างกระบวนการคลายการบีบอัด ทันทีที่ Message Processor ระบุว่าจำนวนไบต์ที่อ่านทั้งหมดมีค่ามากกว่า 10 MB ระบบจะหยุดและพิมพ์บรรทัดต่อไปนี้ 
      Message is too large.  TotalRead 10489856 chunkCount 2570

      ซึ่งหมายความว่า ขนาดเพย์โหลดคำขอมีขนาดมากกว่า 10 MB และ Apigee จะแสดงข้อผิดพลาด RequestTooLarge เมื่อขนาดเริ่มเกินขีดจำกัด 10 MB โดยมีรหัสข้อผิดพลาดเป็น protocol.http.TooBigBody

ความละเอียด

แก้ไขขนาด

ตัวเลือกที่ 1 [แนะนำ]: แก้ไขแอปพลิเคชันไคลเอ็นต์ไม่ให้ส่งเพย์โหลดที่มีขนาดใหญ่กว่า ขีดจำกัดที่อนุญาต

  1. วิเคราะห์เหตุผลที่ไคลเอ็นต์รายนั้นส่งคำขอ / เพย์โหลดที่มีขนาดเกินกว่าที่อนุญาต ตามที่กำหนดไว้ในขีดจำกัด

  2. หากไม่ต้องการ ให้แก้ไขแอปพลิเคชันไคลเอ็นต์เพื่อให้ส่งคำขอ / เพย์โหลด ที่มีขนาดน้อยกว่าขีดจำกัดที่อนุญาต

    ในตัวอย่างที่กล่าวถึงข้างต้น คุณสามารถแก้ไขปัญหาได้โดยส่งไฟล์ที่มีขนาดเล็กลง สมมติว่าเพย์โหลด test5mbfile (มีขนาด 5 MB) ดังที่แสดงด้านล่าง 

    curl https://<host>/testtoobigbody -k -X POST -F file=@test5mbfile -v
  3. หากต้องการส่งคำขอ/เพย์โหลดเกินขีดจำกัดที่อนุญาต ให้ไปที่ตัวเลือกถัดไป

รูปแบบ URL ที่ลงนาม

ตัวเลือกที่ 2 [แนะนำ]: ใช้รูปแบบ URL ที่ลงนามแล้วภายใน Apigee JavaCallout

สำหรับเพย์โหลดที่มีขนาดใหญ่กว่า 10 MB Apigee ขอแนะนำให้ใช้รูปแบบ URL ที่ลงนามแล้วภายใน Apigee JavaCallout ซึ่งแสดงให้เห็นในตัวอย่าง Edge Callout: Signed URL Generator ใน GitHub

สตรีมมิง

ตัวเลือกที่ 3 : ใช้การสตรีม

หากพร็อกซี API ต้องจัดการคำขอและ/หรือการตอบกลับที่มีขนาดใหญ่มาก คุณสามารถเปิดใช้การสตรีมใน Apigee ได้

CwC

ตัวเลือกที่ 4 : ใช้พร็อพเพอร์ตี้ CwC เพื่อเพิ่มขีดจํากัดบัฟเฟอร์

คุณควรใช้ตัวเลือกนี้เฉพาะในกรณีที่ไม่สามารถใช้ตัวเลือกที่แนะนำได้ เนื่องจากอาจเกิดปัญหาด้านประสิทธิภาพหากเพิ่มขนาดเริ่มต้น

Apigee มีพร็อพเพอร์ตี้ CwC ซึ่งช่วยให้เพิ่ม ขีดจำกัดขนาดเพย์โหลดของคำขอและการตอบกลับได้ โปรดดูรายละเอียดที่ ตั้งค่าขีดจำกัดขนาดข้อความในเราเตอร์หรือตัวประมวลผลข้อความ

จำกัดสูงสุด

Apigee คาดหวังว่าแอปพลิเคชันไคลเอ็นต์และเซิร์ฟเวอร์แบ็กเอนด์จะไม่ส่งเพย์โหลดที่มีขนาดใหญ่กว่า ขีดจำกัดที่อนุญาตตามที่ระบุไว้สำหรับ Request/response size ใน ขีดจำกัดของ Apigee Edge

  1. หากคุณเป็นผู้ใช้ระบบคลาวด์สาธารณะ ขีดจำกัดสูงสุดสำหรับขนาดเพย์โหลดของคำขอและการตอบกลับจะเป็นไปตามที่ระบุไว้สำหรับ Request/response size ในขีดจำกัดของ Apigee Edge
  2. หากคุณเป็นผู้ใช้ Private Cloud คุณอาจได้แก้ไขค่าเริ่มต้น สำหรับขนาดเพย์โหลดของคำขอและการตอบกลับ (แม้ว่าจะไม่ใช่แนวทางที่แนะนำก็ตาม) คุณกำหนดขีดจำกัดขนาดเพย์โหลดคำขอสูงสุดได้โดยทำตามวิธีการใน วิธีตรวจสอบขีดจำกัดปัจจุบัน

วิธีตรวจสอบโควต้าปัจจุบัน

ส่วนนี้อธิบายวิธียืนยันว่าพร็อพเพอร์ตี้ HTTPRequest.body.buffer.limit ได้รับการอัปเดตด้วยค่าใหม่ในเครื่องมือประมวลผลข้อความแล้ว

  1. ในเครื่อง Message Processor ให้ค้นหาพร็อพเพอร์ตี้ HTTPRequest.body.buffer.limit ในไดเรกทอรี /opt/apigee/edge-message- processor/conf และตรวจสอบว่ามีการตั้งค่าใดไว้โดยใช้คำสั่งต่อไปนี้ command: 
    grep -ri "HTTPRequest.body.buffer.limit" /opt/apigee/edge-message-processor/conf
  2. ผลลัพธ์ตัวอย่างจากคำสั่งข้างต้นมีดังนี้ 
    /opt/apigee/edge-message-processor/conf/http.properties:HTTPRequest.body.buffer.limit=10m

  3. ในเอาต์พุตตัวอย่างด้านบน โปรดสังเกตว่าพร็อพเพอร์ตี้ HTTPRequest.body.buffer.limit ได้รับการตั้งค่าด้วยค่า 10m ใน http.properties

    ซึ่งหมายความว่าขนาดเพย์โหลดของคำขอที่กำหนดค่าใน Apigee สำหรับ Private Cloud มีขนาด10 MB

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

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

รวบรวมข้อมูลการวินิจฉัยต่อไปนี้ แล้วติดต่อทีมสนับสนุน Apigee Edge

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

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

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

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

  • บันทึกการเข้าถึง 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