Temu duga Backend: Bagaimanakah anda akan mereka bentuk kontrak HTTP 413 Content Too Large?

Gesaan dan skop

Muat naik video melalui CDN, get laluan API, perkhidmatan aplikasi dan stor objek, masing-masing dengan saiz yang diterima berbeza. Reka bentuk respons 413 Content Too Large, penemuan had, muat naik boleh sambung semula, Retry-After, jasad ralat dan pemantauan.

Ini ialah soalan kebolehpercayaan API backend. Bilangan lapisan dan saiz video adalah andaian, bukan tuntutan kekerapan.

Perkara yang diuji oleh penemu duga

• Sama ada anda memisahkan had kekal, kapasiti sementara, dan kegagalan pengesahan jasad.
• Sama ada anda menerangkan hubungan antara 413 dan Retry-After dengan tepat.
• Sama ada anda mereka bentuk kebolehsambungan semula dan bukannya mencuba semula keseluruhan jasad.
• Sama ada anda mengendalikan had proksi, keidempotenan, dan kebocoran maklumat.

Soalan penjelasan untuk ditanya

1. Lapisan manakah yang mengeluarkan 413, dan adakah skop serta request ID miliknya dipelihara?
2. Adakah had tersebut bagi setiap permintaan, penyewa (tenant), objek, tetingkap masa, atau baki kuota?
3. Bolehkah klien menggunakan ketulan (chunks), menyambung semula, dan menyoal sesi muat naik?
4. Adakah had tersebut merupakan konfigurasi tetap atau kapasiti atau kuota sementara?
5. Bolehkah bait yang diterima mencipta kesan sampingan pengebilan, kunci (locks), atau metadata objek?

Jawapan 30 saat

"413 bermaksud pelayan enggan memproses kandungan yang terlalu besar. Had tetap tidak sepatutnya membuatkan klien menunggu; keadaan sementara boleh menyertakan Retry-After. Pinggir (edge) harus menolak lebih awal dengan kod yang stabil, request ID, dan kekangan awam, manakala aplikasi masih mengesahkan bait sebenar. Fail besar menggunakan sesi muat naik, ketulan dan penyiapan idempoten. Selepas terputus, soal keadaan sebelum menghantar semula; jangan sekali-kali menghantar semula ketulan yang telah disahkan. Saya mengukur 413 mengikut lapisan, penyewa, dan saiz."

Reka bentuk langkah demi langkah

1. Tentukan had berlapis

Had maksimum tetap, kuota penyewa, dasar objek dan kapasiti masa jalan memerlukan pemilik yang jelas. Pinggir boleh menolak daripada Content-Length, tetapi aplikasi juga mesti menyemak bait yang diterima, saiz yang dinyahpemampat, dan dasar kandungan. Sertakan request ID dalam ralat; jangan dedahkan nod dalaman, kapasiti cakera, atau data penyewa lain.

2. Gunakan Retry-After dengan betul

RFC 9110 membenarkan pelayan menjana Retry-After apabila keadaan 413 adalah sementara. Nilai tersebut boleh berupa tarikh HTTP atau kelewatan dalam saat. Had maksimum tetap memerlukan permintaan yang diubah atau ketulan, bukan menunggu. Gunakan pengepala untuk kuota yang diketahui atau tetingkap pemulihan penyelenggaraan, dan pastikan klien mengehadkan (cap) serta mengesahkan kelewatan tersebut.

HTTP/1.1 413 Content Too Large
Retry-After: 120
Content-Type: application/problem+json
X-Request-Id: req-81a

3. Jadikan ralat boleh diambil tindakan (actionable)

Kembalikan kod yang stabil, skop, mod muat naik yang dibenarkan, saiz ketulan maksimum, dan titik masuk sesi muat naik. Jangan sekali-kali mendedahkan nama pelaksanaan get laluan, surihan timbunan (stack traces), atau ralat pangkalan data. Klien boleh memampatkan, mengubah saiz, memecahkan kepada ketulan, atau meminta kuota berdasarkan kod tersebut dan bukannya mencuba semula jasad yang sama selama-lamanya.

4. Sediakan muat naik boleh sambung semula

Cipta sesi muat naik terlebih dahulu dan kembalikan ID, tempoh luput, julat saiz ketulan, dan pertanyaan untuk ketulan yang telah selesai. Setiap ketulan membawa peleburan (digest) dan kunci keidempotenan; penyiapan hanya merujuk kepada ketulan yang disahkan. Pada 413, klien boleh mengurangkan saiz ketulan baharu atau mencipta sesi baharu tanpa menghantar semula data yang disahkan.

5. Kendalikan lapisan yang tidak konsisten

Get laluan mungkin mengembalikan 413 sebelum aplikasi, manakala aplikasi mungkin menolak selepas penyahpemampatan, kuota, atau pemeriksaan dasar. Model ralat yang dikongsi tidak boleh menganggap setiap lapisan mengetahui had akhir. Kembalikan kekangan semasa semasa penciptaan sesi, pantau sumber 413, dan jangan simpan nilai sementara satu lapisan dalam cache sebagai had global kekal.

6. Hubungkan percubaan semula, pengebilan dan metrik bersama-sama

Kelaskan 413 pada klien: ubah permintaan untuk had tetap, ikuti Retry-After untuk had sementara, dan soal keadaan sesi selepas kegagalan sesi. Gunakan keidempotenan untuk penyiapan supaya pengebilan tidak diduplikasi, dan luputkan sesi yang terbiar. Jejaki lapisan sumber, penyewa, saiz permintaan, bait yang dimuat naik, pematuhan Retry-After, penghantaran semula ketulan, dan pemulihan akhir untuk mengesan hanyutan had.

Model jawapan berkualiti tinggi

"Saya mula-mula mengenal pasti lapisan yang mengeluarkan ralat dan jenis had. Had maksimum tetap mengembalikan 413 dengan kekangan awam atau titik masuk ketulan; hanya kuota atau kapasiti sementara mengembalikan Retry-After. Fail besar menggunakan sesi dan ketulan dengan peleburan serta keidempotenan, dan klien yang terputus menyoal ketulan yang disahkan. Pinggir menolak lebih awal, manakala aplikasi menyemak bait sebenar dan yang dinyahpemampat. Jasad ralat hanya mendedahkan kod yang stabil, request ID, dan langkah seterusnya. Saya mengukur sumber, taburan saiz, pematuhan menunggu, penyiapan pendua, dan kadar pemulihan."

Kesilapan biasa

• Menambah Retry-After pada setiap 413 → had tetap menyebabkan penantian yang sia-sia → gunakan masa hanya untuk keadaan sementara.
• Mengekod keras satu had klien → lapisan mengalami hanyutan → kembalikan kekangan sesi dan pantau sumber.
• Menghantar semula keseluruhan jasad → lebar jalur dan kesan sampingan berganda → gunakan ketulan, pertanyaan dan penyiapan idempoten.
• Hanya menyemak Content-Length → bait yang dinyahpemampat atau sebenar boleh melebihi had → sahkan semasa dan selepas pengingesan (ingestion).
• Mendedahkan had dalaman → topologi dan kapasiti bocor → kembalikan kod yang stabil dan request ID.

Soalan susulan dan respons

Apakah yang perlu dilakukan oleh klien apabila 413 tidak mempunyai Retry-After?

Jangan meneka kelewatan. Anggap ia sebagai had tetap atau tidak diketahui, gunakan kod ralat dan keadaan sesi, dan beralih kepada permintaan yang lebih kecil, ketulan, atau aliran kuota yang jelas. Automatikkan penantian hanya apabila pelayan memberikan masa pemulihan.

Bagaimana jika ketulan juga melebihi had satu lapisan?

Kembalikan julat yang dibenarkan pada masa ini semasa penciptaan sesi dan pilih ketulan yang tidak lebih besar daripada had berkesan yang terkecil. Jika dasar berubah, kekalkan ketulan yang disahkan dan teruskan dengan parameter sesi baharu dan bukannya menyerahkan semula ketulan lama.

Get laluan mengembalikan 413 tetapi aplikasi tidak mempunyai rekod. Bagaimanakah anda menyahpepijatnya?

Bandingkan request ID, bait yang diterima, dan sumber respons merentasi pinggir, get laluan dan aplikasi. Jika aplikasi tidak mempunyai rekod, periksa had get laluan, penghalaan, dan pemajuan jasad terlebih dahulu; log aplikasi yang hilang tidak membuktikan penolakan aplikasi.