Temu Duga Umum: Bagaimanakah anda membaca badan satu kali guna dengan selamat menggunakan Request.bytes()?

Gesaan dan skop

Anda mesti memproses badan permintaan binari dalam penyemak imbas atau runtime pinggir (edge). Platform ini menambah Request.bytes(), tetapi badan permintaan hanya boleh digunakan sekali sahaja. Terangkan bila menggunakannya, cara mengelakkan bacaan berganda, cara mengehadkan memori, dan cara mereka bentuk sandaran (fallback).

MDN menerangkan Request.bytes() mengembalikan Promise yang nilai terlaksananya ialah Uint8Array bagi badan permintaan; membaca badan akan menggunakannya. Temu duga ini menguji jangka hayat badan Fetch, had sumber, dan ralat dan bukannya menganggap kaedah baharu ini sebagai lalai universal.

Perkara yang dinilai oleh penemu duga

• Menjelaskan keadaan badan yang telah digunakan (used-body) dan sifat saling eksklusif antara bytes(), arrayBuffer(), json(), dan text().
• Memilih bacaan lengkap berbanding penstriman berdasarkan saiz permintaan dan matlamat pemprosesan.
• Meletakkan satu sempadan bacaan antara percubaan semula (retry), pengelogan, pengesahan tandatangan, dan penghuraian perniagaan.
• Mereka bentuk pengesanan keupayaan, had, pembatalan, tamat masa (timeout), dan pemetaan ralat.
• Mencegah badan mentah daripada memasuki log, cache, atau objek rentas penyewa (tenant).

Soalan penjelasan

• Apakah saiz badan, sumber, Content-Type, keperluan tandatangan, dan runtime sasaran?
• Adakah perniagaan memerlukan tatasusunan bait lengkap, pencincangan berperingkat (incremental hashing), muat naik ketulan (chunk), atau data yang dinyahkod?
• Lapisan manakah yang mencuba semula, dan adakah main semula (replay) selamat?
• Bolehkah badan mengandungi data peribadi, kelayakan, atau data pengasingan penyewa?

Jangka hayat badan dan pilihan API

Selepas Request.bytes() berjaya menggunakan badan, panggilan json() atau text() seterusnya akan gagal, dan begitu juga sebaliknya. Jika beberapa pengguna memerlukan data tersebut, baca sekali pada satu sempadan tunggal dan hantar hasil yang terkawal kepada kod penghuraian, pengesahan, dan perniagaan. Jangan hantar objek Request melalui banyak modul yang bersaing untuk membacanya.

Bacaan lengkap sesuai untuk permintaan kecil yang terikat atau protokol yang memerlukan pengesahan sekali gus. Permintaan besar harus mengutamakan penstriman request.body, melaksanakan pencincangan berperingkat dan semakan saiz. Hasil Uint8Array adalah mudah untuk pemprosesan bait tetapi tidak menghapuskan lonjakan memori daripada bacaan lengkap.

Memori, had, dan tekanan balik (backpressure)

Periksa Content-Length di pinggir, tetapi jangan mempercayainya semata-mata; dengan pemindahan berketul (chunked transfer), kira bait sebenar dan batalkan (abort) apabila had melebihi. Tetapkan had penyewa, laluan, dan global untuk bacaan lengkap supaya permintaan serentak tidak memperuntukkan tatasusunan tanpa had. Laluan penstriman menggunakan tekanan balik apabila pengguna ketinggalan.

Untuk pemajuan, jangan salin beberapa tatasusunan penuh untuk pengelogan atau percubaan semula. Jika main semula diperlukan, tulis bait dengan had saiz ke storan sementara yang terkawal dengan pengikatan penyewa, tarikh luput, dan cernaan (digest); badan mentah tidak sepatutnya berada dalam log biasa.

Pengesahan tandatangan, penghuraian, dan ralat

Sebelum pengesahan, tentukan sama ada tandatangan merangkumi bait mentah atau struktur kanonikal. Masukkan bait mentah daripada satu bacaan itu ke kedua-dua pengesah dan penghurai; penyirikan semula JSON boleh mengubah ruang putih, susunan, atau pengekodan. Petakan kegagalan huraian, kegagalan tandatangan, pelanggaran saiz, pembatalan, dan tamat masa kepada ralat perniagaan yang berbeza dan bukannya satu respons "cacat" (malformed).

Fungsi pinggir mungkin mendedahkan API badan yang berbeza. Kesan keupayaan dan pilih bytes(), arrayBuffer(), atau penstriman, sambil merekodkan versi keupayaan runtime semasa permulaan. Sandaran mesti mengekalkan had, cernaan input, dan semantik ralat; runtime lama tidak boleh melemahkan keselamatan secara senyap.

Pembatalan, tamat masa, dan main semula

Hantar AbortSignal kepada bacaan dan operasi hiliran. Berhenti membaca dan lepaskan rujukan apabila klien terputus sambungan atau tempoh masa tamat. Jangan sekali-kali memainkan semula permintaan yang mempunyai kesan sampingan secara automatik selepas tamat masa tanpa kunci idempoten, penyahduplikasian pelayan, dan tetingkap percubaan semula yang jelas. Pertanyaan yang kelihatan selamat pun memerlukan semakan kebocoran main semula.

Percubaan semula get laluan boleh mencipta salinan permintaan, jadi pengesahan tandatangan, kunci idempoten, dan peristiwa audit harus berkongsi satu ID permintaan. Respons ralat harus menyatakan sama ada percubaan semula selamat tanpa mendedahkan keadaan bacaan dalaman atau bahan kunci.

Keselamatan dan kebolehcerapan

Hadkan Content-Type, saiz badan, tempoh bacaan, dan keserentakan. Ambil kira saiz selepas penyahmampatan untuk menentang bom penyahmampatan (decompression bomb). Asingkan cache dan objek sementara mengikut penyewa; simpan bait sensitif hanya selama yang diperlukan. Rekodkan bilangan bait, tempoh, sebab pembatalan, kelas ralat, dan cernaan permintaan, bukan kandungannya.

Pantau kegagalan penggunaan badan, pelanggaran had, masa membaca p95, memori puncak, tekanan balik hiliran, dan percubaan semula. Jika kegagalan bytes() meningkat dalam satu runtime, beralih kepada sandaran yang diuji dan berikan amaran; menangkap pengecualian dan membaca badan yang sama sekali lagi bukanlah pemulihan.

Senarai semak pengesahan dan tindakan susulan

Uji kes kosong, satu bait, hampir had, melebihi had, berketul, klien perlahan, terputus sambungan, bacaan berganda, ketakpadanan tandatangan, bom penyahmampatan, serentak, sandaran runtime lama, dan tamat masa hiliran. Sahkan bahawa setiap laluan menggunakan badan tepat sekali dan pembatalan menghentikan bacaan lanjut.

Mengapa tidak memanggil json() dan kemudian menggunakan bytes() untuk pengesahan?

Bacaan pertama telah menggunakan badan tersebut, dan penghuraian ditambah penyirikan semula boleh mengubah ruang putih, susunan, atau pengekodan. Baca bait mentah sekali dan berikan bait yang sama untuk pengesahan dan penghuraian.

Bilakah bytes() lebih baik daripada penstriman?

Gunakan kaedah ini untuk permintaan kecil yang terikat apabila protokol memerlukan pengesahan bait lengkap. Fail besar, muat naik berterusan, dan keserentakan tinggi memerlukan penstriman dan pemprosesan berperingkat.

Bagaimanakah anda membuktikan sandaran adalah sama selamat?

Paksa setiap laluan keupayaan dalam setiap runtime dan bandingkan had, cernaan, tandatangan, ralat, pembatalan, dan peristiwa audit. Sandaran tidak boleh mengubah dasar keselamatan atau sempadan percubaan semula.