Gesaan dan skop
Klien memuat naik fail bersaiz beberapa ratus megabait ke storan objek. Pelayan boleh menolak token yang tidak sah, kuota atau jenis media hanya dengan menggunakan pengepala permintaan. Reka bentuk jabat tangan muat naik HTTP/1.1 dan terangkan Expect: 100-continue, sandaran 417, lompatan proksi, tamat masa (timeout), percubaan semula (retry) dan metrik.
Ini ialah soalan protokol dan kebolehpercayaan backend. Saiz fail dan status adalah andaian untuk latihan ini, bukan dakwaan kekerapan.
Perkara yang diuji oleh penemu duga
- Sama ada anda memisahkan kemasukan (admission) berasaskan pengepala sahaja daripada pemprosesan badan (body).
- Sama ada anda menerangkan 100, respons akhir dan 417 dengan tepat.
- Sama ada anda mengendalikan jangkaan yang diabaikan, tamat masa menunggu dan penggunaan semula sambungan.
- Sama ada percubaan semula, keidempotensian, checksum dan kebolehcerapan mempunyai pemilik yang jelas.
Soalan penjelasan untuk ditanya
- Adakah muat naik ini idempoten, dan adakah terdapat sesi muat naik atau kunci keidempotensian?
- Bolehkah klien memutar balik (rewind) sumber badan dan membuka semula fail?
- Gateway dan perkhidmatan storan manakah yang mengekalkan respons bermaklumat (informational responses)?
- Bolehkah percubaan yang gagal dicuba semula tanpa Expect, dan bolehkah ia menghasilkan pendua?
- Peraturan manakah yang merupakan semakan pengepala sahaja, dan yang manakah memerlukan pembacaan keseluruhan badan?
Jawapan 30 saat
“Klien menghantar pengepala dengan Expect: 100-continue. Pelayan menyemak pengesahan, panjang, jenis, kuota dan penghalaan; ia menghantar 4xx akhir untuk penolakan serta-merta atau 100 Continue apabila ia bersedia untuk menerima badan. Klien menghantar badan hanya selepas respons interim tersebut, dengan tempoh menunggu yang dihadkan. Respons 417 boleh mencetuskan percubaan semula tanpa Expect hanya apabila badan boleh diputar balik dan operasi selamat untuk dimainkan semula. Saya mengekalkan kunci keidempotensian yang sama dan mengukur tingkah laku proksi, bait yang dijimatkan, kadar 417 dan badan yang digugurkan.”
Reka bentuk langkah demi langkah
1. Hantar pengepala terlebih dahulu
Permintaan membawa pengesahan, Content-Length, Content-Type, penghadaman (digest), maklumat penyewa (tenant), kunci keidempotensian dan Expect: 100-continue. Sebelum membaca badan, pelayan boleh menyemak token, laluan, kuota dan had saiz statik. Spesifikasi memerlukan respons selepas keputusan dibuat; klien tidak boleh menunggu selama-lamanya.
PUT /objects/o-123 HTTP/1.1
Host: upload.example
Authorization: Bearer ...
Content-Length: 524288000
Content-Type: application/octet-stream
Idempotency-Key: up-7f2
Expect: 100-continue2. Kendalikan kemasukan dan penolakan
Untuk kemasukan, kembalikan 100 Continue, kemudian terima badan. Untuk pengesahan yang tidak sah, panjang yang berlebihan atau kuota yang tidak mencukupi, kembalikan status akhir seperti 401, 403, 413 atau 415; klien tidak sepatutnya menghantar bait badan yang belum dihantarnya. Pra-penerbangan hanya merangkumi peraturan yang dapat dilihat pada pengepala, jadi keputusan akhir masih bergantung pada pengesahan badan.
3. Gunakan 417 secara terhad
417 Expectation Failed bermakna pelayan atau perantara tidak dapat memenuhi jangkaan tersebut. Jika operasi membenarkannya, klien boleh mengalih keluar Expect dan menghantar semula, tetapi ia mesti berupaya memutar balik badan, mengekalkan kunci keidempotensian dan memastikan sambungan lama tidak mempunyai badan yang belum dibaca. Jangan anggap setiap 4xx sebagai 417 atau memainkan semula tugasan bukan idempoten yang tidak boleh diubah kembali.
4. Ambil kira waktu menunggu, proksi dan sambungan
Klien menetapkan tarikh akhir yang terhad untuk menunggu 100 dan merekodkan laluan tamat masa. Perantara HTTP/1.0 mungkin mengabaikan Expect, dan proksi boleh menjana 100 sendiri. Uji setiap lompatan untuk pemajuan pengepala, pengendalian respons bermaklumat dan sama ada penolakan akhir menutup atau mengalirkan (drain) sambungan; jika tidak, baki bait boleh merosakkan penggunaan semula sambungan.
5. Jadikan percubaan semula idempoten
Cuba semula hanya apabila sumber badan boleh diputar balik dan operasi perniagaan membenarkan pengulangan. Penciptaan objek atau penolakan kuota harus menggunakan kunci keidempotensian yang stabil supaya percubaan dipetakan kepada satu hasil. Selepas terputus sambungan, hasilnya mungkin tidak diketahui; tanya sesi muat naik atau status objek sebelum mencipta objek lain.
6. Sahkan dalam kedua-dua fasa
Semakan pra-penerbangan merangkumi pengesahan, penyewa, panjang, jenis dan kuota. Selepas menerima badan, sahkan kiraan bait sebenar, digest, kandungan berniat jahat dan dasar storan. Jangan mempercayai Content-Length atau jenis MIME yang diisytiharkan oleh klien semata-mata. Log ID permintaan, hasil kemasukan dan bait yang diterima, jangan sekali-kali melog token atau kandungan fail.
Contoh jawapan berkualiti tinggi
“Saya membahagikan muat naik kepada keputusan pengepala dan pengambilan badan. Klien menghantar pengesahan, panjang, jenis, digest, kunci keidempotensian dan Expect: 100-continue. Pelayan menolak kegagalan yang murah dan deterministik sebelum badan; selepas kemasukan, ia menghantar 100 dan klien memuat naik. 417 menyebabkan percubaan semula tanpa Expect hanya apabila main semula selamat, dengan kunci keidempotensian yang sama. Tamat masa menunggu, pemutusan sambungan dan tingkah laku proksi dipulihkan melalui pertanyaan status. Saiz badan, digest dan keselamatan kandungan masih disahkan. Saya menguji kependaman 100, 417, 4xx awal, penggunaan semula sambungan dan bait yang dijimatkan merentasi proksi sebenar.”
Kesilapan lazim
- Menganggap 100 sebagai kejayaan → ia hanya membenarkan badan → tunggu 2xx akhir atau kegagalan.
- Mencuba semula tanpa Expect selepas sebarang 4xx → kesan sampingan boleh berganda → sandaran hanya untuk 417 dan main semula yang selamat.
- Menunggu 100 selama-lamanya → permintaan tergantung → hadkan dan pantau waktu menunggu.
- Hanya menyemak pengepala → badan yang rosak atau berniat jahat memasuki storan → sahkan selepas pengambilan juga.
- Mengabaikan perbezaan proksi → badan awal atau baki bait memecahkan penggunaan semula → uji setiap lompatan dan kawal penggunaan semula sambungan.
Soalan susulan dan respons
Bagaimana jika klien menghantar bait badan sebelum menerima 401?
Pelayan mengikut dasar sambungannya untuk menutup atau terus membaca dan membuang badan. Klien berhenti menghantar dan menandakan percubaan itu gagal. Penggunaan semula memerlukan pembuktian bahawa keadaan protokol telah sejajar semula.
Mengapa tidak sentiasa menghantar badan dengan serta-merta?
Permintaan kecil mungkin tidak mewajarkan jabat tangan ini. Permintaan besar mendapat manfaat apabila kegagalan pengesahan, panjang atau kuota dapat dikesan lebih awal. Laksanakan mengikut saiz permintaan, keserasian proksi dan kos pelaksanaan.
Adakah idea ini masih penting untuk HTTP/2 atau HTTP/3?
Jangan menganggap tingkah laku peringkat bait yang serupa. Sahkan cara klien, gateway dan pelayan yang dipilih mengendalikan respons bermaklumat, kawalan aliran dan pembatalan strim. Matlamat utama kekal: penolakan awal, keadaan muat naik yang boleh dipulihkan dan keidempotensian.