413 Entitas Permintaan Terlalu Besar - TooBigBody

Anda sedang melihat dokumentasi Apigee Edge.
Buka Dokumentasi Apigee X.
info

Gejala

Aplikasi klien mendapatkan kode status HTTP 413 Request Entity Too Large dengan kode error protocol.http.TooBigBody sebagai respons untuk panggilan API.

Pesan Error

Aplikasi klien mendapatkan kode respons berikut:

HTTP/1.1 413 Request Entity Too Large

Selain itu, Anda mungkin melihat pesan error berikut:

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

Kemungkinan penyebab

Error ini terjadi jika ukuran payload yang dikirim aplikasi klien ke Apigee Edge sebagai bagian dari Permintaan HTTP lebih besar dari batas yang diizinkan di Apigee Edge .

Berikut adalah kemungkinan penyebab error ini :

Penyebab Deskripsi Petunjuk pemecahan masalah berlaku untuk
Ukuran payload permintaan melebihi batas yang diizinkan Ukuran payload yang dikirim aplikasi klien sebagai bagian dari permintaan HTTP ke Apigee Edge adalah melebihi batas yang diizinkan di Apigee Edge. Pengguna Edge Public dan Private Cloud
Ukuran payload permintaan melebihi batas yang diizinkan setelah dekompresi Ukuran payload yang dikirim dalam format terkompresi oleh aplikasi klien sebagai bagian dari HTTP ke Apigee Edge lebih dari batas yang diizinkan saat didekompresi oleh Apigee Edge. Pengguna Edge Public dan Private Cloud

Langkah-langkah diagnosis umum

Gunakan salah satu alat/teknik berikut untuk mendiagnosis error ini:

Pemantauan API

Untuk mendiagnosis error menggunakan Pemantauan API:

  1. Login ke UI Apigee Edge sebagai pengguna dengan peran yang sesuai.
  2. Beralihlah ke organisasi tempat Anda ingin menyelidiki masalah ini

  3. Buka Analyze > Pemantauan API > Investigasi.
  4. Pilih jangka waktu tertentu saat Anda melihat error.
  5. Anda dapat memilih filter Proxy untuk mempersempit kode kesalahan.
  6. Gambarkan Kode Kesalahan terhadap Waktu.
  7. Pilih sel yang berisi Kode Kesalahan protocol.http.TooBigBody dan Kode Status 413seperti yang ditunjukkan di bawah ini:

  8. Informasi tentang kode kesalahan protocol.http.TooBigBody ditampilkan sebagai yang ditampilkan di bawah ini:

  9. Klik View logs, lalu luaskan baris untuk permintaan yang gagal. Kemudian dari Logs, perhatikan detailnya seperti yang ditunjukkan di bawah ini :

    Tidak terkompresi

    Skenario #1: Payload Permintaan yang dikirim dalam bentuk tidak terkompresi

    Dari jendela Logs, perhatikan detail berikut:

    • Kode Status: 413
    • Sumber Kesalahan: proxy
    • Kode Kesalahan: protocol.http.TooBigBody.
    • Panjang Permintaan(byte): 15360440 (~15 MB)

    Jika Sumber Kesalahan memiliki nilai proxy , Kode Kesalahan memiliki nilai protocol.http.TooBigBody, dan Panjang Permintaan lebih dari 10 MB, hal ini mengindikasikan bahwa permintaan HTTP dari klien memiliki ukuran payload permintaan lebih besar dari batas yang diizinkan di Apigee.

    Terkompresi

    Skenario #2: Meminta Payload yang dikirim dalam bentuk terkompresi

    Dari jendela Logs, perhatikan detail berikut:

    • Kode Status: 413
    • Sumber Kesalahan: proxy
    • Kode Kesalahan: protocol.http.TooBigBody.
    • Panjang Permintaan(byte): 15264 (~15 kB)

    Jika Sumber Kesalahan memiliki nilai proxy , Kode Kesalahan memiliki nilai protocol.http.TooBigBody, dan Panjang Permintaan adalah kurang dari 10 MB, hal ini menunjukkan bahwa permintaan HTTP dari klien memiliki ukuran payload permintaan lebih rendah dari batas yang diizinkan dalam format terkompresi, tetapi ukuran payload lebih besar dari batas yang diizinkan saat tidak dikompresi oleh Apigee.

Trace

Untuk mendiagnosis error menggunakan alat Trace:

  1. Aktifkan sesi rekaman aktivitas dan
    • Tunggu hingga error 413 Request Entity Too Large terjadi atau
    • Jika Anda dapat mereproduksi masalah, lakukan panggilan API dan rekonstruksi 413 Request Entity Too Large error
  2. Pastikan Tampilkan semua Info Alur diaktifkan.

  3. Pilih salah satu permintaan yang gagal dan periksa rekaman aktivitasnya.
  4. Buka fase Permintaan Diterima dari Klien.

    Tidak terkompresi

    Skenario #1: Payload Permintaan yang dikirim dalam bentuk tidak terkompresi

    Perhatikan informasi berikut:

    • Content-Encoding: tidak ada
    • Durasi Konten: 15360204

    Terkompresi

    Skenario #2: Meminta Payload yang dikirim dalam bentuk terkompresi

    Perhatikan informasi berikut:

    • Encoding Konten: gzip
    • Durasi Konten: 14969
    • Jenis Konten: application/x-gzip
  5. Menavigasi melalui berbagai fase pelacakan dan menemukan tempat terjadinya kegagalan.
  6. Anda akan menemukan error ini biasanya dalam alur setelah Permintaan Diterima dari Klien seperti yang ditunjukkan di bawah ini:

  7. Perhatikan nilai error dari trace. Contoh rekaman aktivitas di atas menunjukkan:
    • error: Body buffer overflow
    • error.class: com.apigee.errors.http.user.RequestTooLarge
  8. Buka Response Sent to Client dan catat nilai error dari rekaman aktivitas. Contoh rekaman aktivitas di bawah ini menunjukkan:

    • error: 413 Request Entity Too Large
    • Konten Error: {"fault":{"faultstring":"Body buffer overflow","detail":{"errorcode":"protocol.http.TooBigBody"}}}
  9. Buka Fase AX (Data Analytics Dicatat) di rekaman aktivitas, lalu klik Fase tersebut.
  10. Di bagian Detail Fase, scroll ke bawah ke bagian Pembacaan Variabel.

  11. Tentukan nilai variabel client.received.content.length, yang menunjukkan:
    • Ukuran sebenarnya dari payload permintaan saat dikirim dalam format yang tidak terkompresi dan
    • Ukuran payload permintaan setelah dekompresi oleh Apigee, saat payload dikirim dalam format terkompresi. Ini akan selalu sama dengan nilai parameter yang diizinkan maksimum (10 MB) dalam skenario ini.

    Tidak terkompresi

    Skenario #1: Meminta payload dalam format yang tidak dikompresi

    variabel client.received.content.length: 15360204

    Terkompresi

    Skenario #2: Meminta payload dalam format terkompresi

    variabel client.received.content.length: 10489856

  12. Tabel berikut menjelaskan mengapa error 413 ditampilkan oleh Apigee dalam dua skenario berdasarkan nilai variabel client.received.content.length:
    Skenario Nilai client.received.content.length Alasan kegagalan
    Meminta Payload dalam format tidak terkompresi ~15 MB Ukuran > batas yang diizinkan sebesar 10 MB.
    Meminta Payload dalam format terkompresi ~10 MB

    Batas ukuran terlampaui setelah dekompresi

NGINX

Untuk mendiagnosis error menggunakan log akses NGINX:

  1. Jika Anda adalah pengguna Private Cloud, Anda dapat menggunakan log akses NGINX untuk menentukan informasi penting tentang error 413 HTTP.
  2. Periksa log akses NGINX:

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

  3. Telusuri apakah terdapat error 413 selama durasi tertentu (jika masalah terjadi di masa lalu) atau jika ada permintaan yang masih gagal dengan 413.
  4. Jika Anda menemukan error 413 dengan pencocokan X-Apigee-fault-code nilai protocol.http.TooBigBody, lalu tentukan nilai atribut X-Apigee-fault-source.

    Tidak terkompresi

    Skenario #1 : Meminta ukuran payload dalam format tidak terkompresi

    Contoh entri dari log akses NGINX di atas memiliki nilai berikut untuk X-Apigee-fault-code dan X-Apigee-fault-source:

    Header respons Nilai
    X-Apigee-fault-code protocol.http.TooBigBody
    X-Apigee-fault-sourc policy

    Perhatikan Panjang Permintaan: 15360440 (14,6 MB > batas yang diizinkan)

    Terkompresi

    Skenario #2 : Meminta ukuran payload dalam format terkompresi

    Contoh entri di atas dari log akses NGINX memiliki nilai berikut untuk X-Apigee-fault-code dan X-Apigee-fault-source:

    Header Respons Nilai
    X-Apigee-fault-code protocol.http.TooBigBody
    X-Apigee-fault-source policy

    Perhatikan Panjang Permintaan: 15264 (14,9 K < batas yang diizinkan)

    Dalam skenario ini, Apigee Edge menampilkan 413 meskipun Panjang Permintaan lebih rendah dari batas yang diizinkan karena permintaan mungkin telah dikirim dalam format terkompresi dan ukuran payload melebihi batas dekompresi oleh Apigee Edge.

Penyebab: Ukuran Payload Permintaan melebihi batas yang diizinkan

Diagnosis

  1. Tentukan Fault Code, Fault Source, dan Request Payload Size untuk error yang diamati menggunakan log akses Pemantauan API, Alat Pelacak, atau NGINX seperti yang dijelaskan dalam Langkah-langkah diagnosis umum dengan Skenario #1 (tidak dikompresi).
  2. Jika Sumber Kesalahan memiliki nilai policy atau proxy, menunjukkan bahwa ukuran payload permintaan yang dikirim aplikasi klien ke Apigee lebih besar dari batas yang diizinkan di Apigee Edge.
  3. Periksa Request Payload Size seperti yang ditentukan di langkah #1.
  4. Anda juga dapat memvalidasi jika ukuran payload permintaan memang > Batas 10 MB yang diizinkan oleh memeriksa permintaan yang sebenarnya menggunakan langkah-langkah berikut:
    1. Jika Anda tidak memiliki akses ke permintaan sebenarnya yang dibuat oleh aplikasi klien, buka Resolusi.
    2. Jika Anda memiliki akses ke permintaan sebenarnya yang dibuat oleh aplikasi klien, lakukan langkah-langkah berikut:
      1. Verifikasi ukuran payload yang diteruskan dalam permintaan.
      2. Jika Anda menemukan bahwa ukuran muatan lebih dari batas yang diizinkan di Apigee Edge, maka itulah yang menjadi penyebab masalah.
      3. Contoh Permintaan:

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

        Dalam kasus di atas, ukuran file test15mbfile ~15 MB. Jika Anda menggunakan beberapa klien lain, minta log klien untuk mengetahui ukuran {i>payload<i} yang dikirim.

Resolusi

Buka Resolusi.

Penyebab: Ukuran Payload Permintaan melebihi batas yang diizinkan setelah dekompresi

Jika payload permintaan dikirim dalam format terkompresi dan header permintaan Content-Encoding disetel ke gzip, Apigee mendekompresi permintaan payload. Selama proses dekompresi, jika Apigee mendapati ukuran payload lebih besar dari 10 MB, batas yang diizinkan, aplikasi akan menghentikan dekompresi lebih lanjut, dan merespons kembali langsung dengan 413 Request Entity Too Large disertai kode error protocol.http.TooBigBody.

Diagnosis

  1. Tentukan Kode Kesalahan, Sumber Kesalahan, dan Ukuran Payload Permintaan untuk error yang diamati menggunakan log Pemantauan API, Alat Pelacak, atau Akses NGINX seperti yang dijelaskan dalam Langkah-langkah diagnosis umum dengan Skenario #2 (dikompresi).
  2. Jika Fault Source memiliki nilai policy atau proxy, hal ini menunjukkan bahwa ukuran payload permintaan yang dikirim aplikasi klien ke Apigee lebih besar daripada batas yang diizinkan di Apigee Edge.
  3. Verifikasi Request Payload Size seperti yang ditentukan di langkah 1.
    • Jika ukuran payload > Batas maksimum 10 MB, maka itulah penyebab error ini.
    • Jika ukuran payload < batas 10 MB yang diizinkan, maka permintaan mungkin saja payload diteruskan dalam format terkompresi. Dalam hal ini, periksa ukuran file yang tidak dikompresi payload permintaan terkompresi.
  4. Anda dapat memvalidasi apakah permintaan dari klien dikirim dalam format terkompresi dan ukuran yang tidak dikompresi lebih besar dari batas yang diizinkan menggunakan salah satu metode:

    Trace

    Untuk memvalidasi menggunakan alat Trace:

    1. Jika Anda telah merekam pelacakan permintaan yang gagal, lihat langkah-langkah yang dijelaskan di Trace dan
      1. Tentukan nilai variabel client.received.content.length
      2. Verifikasi apakah permintaan dari klien berisi Content-Encoding: Header gzip
    2. Jika nilai variabel client.received.content.length lebih besar dari 10 MB, batas yang diizinkan, dan header permintaan Content-Encoding: gzip, itulah penyebab error ini.

    Permintaan sebenarnya

    Untuk memvalidasi menggunakan permintaan yang sebenarnya:

    1. Jika Anda tidak memiliki akses ke permintaan sebenarnya yang dibuat oleh aplikasi klien, buka Resolusi.
    2. Jika Anda memiliki akses ke permintaan sebenarnya yang dibuat oleh aplikasi klien, lakukan langkah-langkah berikut:
      1. Verifikasi ukuran payload yang diteruskan dalam permintaan beserta Header Content-Encoding dikirim dalam permintaan.
      2. Periksa untuk melihat apakah ukuran payload yang tidak dikompresi lebih besar dari batas yang diizinkan di Apigee Edge

        Contoh permintaan:

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

        Dalam kasus di atas, file test15mbfile.gz lebih kecil dari batas ukuran; namun, ukuran file test15mbfile yang tidak dikompresi adalah ~15 MB dan header Content-Encoding adalah gzip.

        Jika Anda menggunakan beberapa klien lain, dapatkan log klien untuk mengetahui ukuran payload dikirim dan jika header Content-Encoding disetel ke gzip.

    Log Pemroses Pesan

    Untuk memvalidasi menggunakan log Pemroses Pesan:

    1. Jika Anda pengguna Private Cloud, Anda dapat menggunakan log Pemroses Pesan untuk menentukan informasi penting tentang error 413 HTTP.
    2. Periksa log Pemroses Pesan:

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

    3. Telusuri untuk mengetahui apakah terdapat error 413 selama durasi tertentu (jika masalah terjadi sebelumnya) atau jika ada permintaan yang masih gagal dengan 413.

      Anda dapat menggunakan string penelusuran berikut:

      grep -ri "chunkCount"
      
      grep -ri "RequestTooLarge"
      
    4. Anda akan menemukan baris dari system.log yang mirip dengan berikut ini (TotalRead dan chunkCount dapat berbeda dalam kasus Anda):
      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. Selama proses dekompresi, segera setelah Pemroses Pesan menentukan total byte yang dibaca adalah > 10 MB, akan menghentikan dan mencetak baris berikut:
      Message is too large.  TotalRead 10489856 chunkCount 2570
      

      Hal ini menyiratkan bahwa Request Payload Size berukuran lebih dari 10 MB dan Apigee menampilkan error RequestTooLarge saat ukuran mulai melebihi batas 10 MB dengan kode kesalahan protocol.http.TooBigBody

Resolusi

Perbaiki ukuran

Opsi #1 [Direkomendasikan]: Perbaiki aplikasi klien agar tidak mengirim ukuran payload lebih besar dari batas yang diizinkan

  1. Menganalisis alasan klien tertentu mengirim ukuran permintaan / payload lebih dari yang diizinkan seperti yang ditetapkan dalam Batas.
  2. Jika tidak diinginkan, ubah aplikasi klien Anda agar mengirimkan permintaan / payload kurang dari batas yang diizinkan.

    Dalam contoh yang dibahas di atas, Anda dapat memperbaiki masalah dengan meneruskan file berukuran lebih kecil, misalkan payload test5mbfile (dengan ukuran 5 MB) seperti yang ditunjukkan di bawah ini:

    curl https://<host>/testtoobigbody -k -X POST -F file=@test5mbfile -v
    

  3. Jika Anda menginginkannya dan Anda ingin mengirimkan permintaan/payload melebihi batas yang diperbolehkan, buka opsi berikutnya.

Pola URL Bertanda Tangan

Opsi #2 [Direkomendasikan]: Gunakan pola URL yang ditandatangani dalam JavaInfo Apigee

Untuk payload yang lebih besar dari 10 MB, Apigee merekomendasikan penggunaan pola URL yang ditandatangani dalam Info Java Apigee, yang diilustrasikan oleh Edge Keterangan: Contoh Generator URL Bertanda Tangan di GitHub.

Streaming

Opsi no. 3 : Gunakan streaming

Jika proxy API perlu menangani permintaan dan/atau respons yang sangat besar, Anda dapat mengaktifkan streaming di Apigee.

CwC

Opsi #4 : Gunakan properti CwC untuk meningkatkan batas buffer

Opsi ini harus digunakan hanya ketika Anda tidak dapat menggunakan opsi yang direkomendasikan karena mungkin menjadi masalah kinerja jika ukuran {i>default<i} diperbesar.

Apigee menyediakan CwC yang memungkinkannya meningkatkan batas ukuran payload permintaan dan respons. Untuk mengetahui detailnya, lihat Menetapkan batas ukuran pesan di Router atau Pemroses Pesan

Batas

Apigee mengharapkan aplikasi klien dan server backend tidak mengirim ukuran payload lebih besar dari batas yang diizinkan seperti yang didokumentasikan untuk Request/response size di Batas Apigee Edge.

  1. Jika Anda adalah pengguna Cloud Publik, batas maksimum untuk permintaan dan respons ukuran payload seperti yang didokumentasikan untuk Request/response size di Batas Apigee Edge.
  2. Jika Anda adalah pengguna Private Cloud , Anda mungkin telah mengubah setelan default batas ukuran payload permintaan dan respons (meskipun bukan praktik yang direkomendasikan). Anda dapat menentukan batas ukuran payload permintaan maksimum dengan mengikuti petunjuk di Cara memeriksa batas saat ini.

Bagaimana cara memeriksa batas saat ini?

Bagian ini menjelaskan cara memverifikasi bahwa properti HTTPRequest.body.buffer.limit telah diperbarui dengan nilai baru di Pemroses Pesan.

  1. Di mesin Pemroses Pesan, telusuri properti HTTPRequest.body.buffer.limit di direktori /opt/apigee/edge-message- processor/conf dan periksa untuk melihat nilai yang telah ditetapkan menggunakan berikut:
    grep -ri "HTTPRequest.body.buffer.limit" /opt/apigee/edge-message-processor/conf
    
  2. Contoh hasil dari perintah di atas adalah sebagai berikut:
    /opt/apigee/edge-message-processor/conf/http.properties:HTTPRequest.body.buffer.limit=10m
    
  3. Pada contoh {i>output<i} di atas, perhatikan bahwa properti HTTPRequest.body.buffer.limit telah ditetapkan dengan nilai 10m di http.properties.

    Hal ini menunjukkan bahwa batas ukuran payload permintaan yang dikonfigurasi di Apigee untuk Pribadi Cloud sebesar 10 MB.

Jika Anda masih memerlukan bantuan dari Dukungan Apigee, buka Harus mengumpulkan informasi diagnostik.

Harus mengumpulkan informasi diagnostik

Kumpulkan informasi diagnostik berikut, lalu hubungi Dukungan Apigee Edge:

Jika Anda adalah pengguna Cloud Publik, berikan informasi berikut:

  • Nama organisasi
  • Nama lingkungan
  • Nama Proxy API
  • Menyelesaikan perintah curl yang digunakan untuk mereproduksi error 413
  • File rekaman aktivitas untuk permintaan API

Jika Anda adalah pengguna Private Cloud, berikan informasi berikut:

  • Pesan error lengkap yang diamati untuk permintaan yang gagal
  • Nama organisasi
  • Nama lingkungan
  • Paket Proxy API
  • File pelacakan untuk permintaan API yang gagal
  • Menyelesaikan perintah curl yang digunakan untuk mereproduksi error 413
  • Log akses NGINX /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

    Di mana: ORG, ENV, dan PORT# diganti dengan nilai aktual.

  • Log sistem Pemroses Pesan /opt/apigee/var/log/edge-message-processor/logs/system.log